3

When I open a generated solution+project file, I get the following warning for each platform I have in the project file:

path/to/project.vcxproj : warning : Platform '[some_platform, 0]' referenced in the project file 'project' cannot be found.

some_platform is a valid platform in the project, and building, browsing etc all work normally. There is no line number showing where the problem is.

My question is, what does '[some_platform, 0]' really mean?

Coming from Linux, I initially thought the quotes signify that I have [some_platform, 0] literally specified somewhere, which I don't. I don't see ,\s*0 used anywhere in the project file either. How do I decipher that message to be able to find out what it's complaining about?

This is a C++ project if that matters.

Edit: The only places , is even used are inside two messages and an SDK reference. So the [some_platform, 0] is definitely something constructed for the sake of warning, but what does the second part (0) mean?

Resolved: Why VS generates an output like that, I don't know, and who knows what the 0 means. However, it turned out that the platform name is something an SDK would register with VS (or something along those lines) and VS expects it case-sensitive. I had changed ORBIS and Durango to orbis and durango, causing the warning. Fixing the case makes the warning go away (the project was loading and building fine regardless).

Shahbaz
  • 46,337
  • 19
  • 116
  • 182
  • It means 'some_platform' and '0' are missing platforms. Difficult to help more w/o reproducing bits. – Simon Mourier May 13 '17 at 04:51
  • 1
    @SimonMourier so you are saying there are two separate platforms missing and it decides to output it like that? The first (`some_platform`) is certainly not missing. The second (0) has no reason to show up. It still doesn't make sense for it to say `Platform '[x, y]'` instead of `Platforms x, y` if what you said is true. – Shahbaz May 14 '17 at 01:13
  • If you don't trust answers from people who're trying to help, you shouldn't ask questions. The message is defined in Microsoft.VisualStudio.Project.VisualC.VCProjectEngine.dll, and if you use a tool such as ILSpy, Reflector, DnSpy etc., you'll see the first parameter is a concatenation of a list of platforms. I didn't say it makes sense, like I say, we need more bits to help further – Simon Mourier May 14 '17 at 06:51
  • 1
    @SimonMourier, there is no issue of trust here. I'm just trying to analyze the response to reach a correct answer (as any scientist would do). Ok, here is more info. Say I have three platforms in the project: `durango`, `orbis` and `x64` (the first two or xb1 and ps4 platforms). They actually build fine with the same project file, so there is nothing fundamentally wrong with them. When I open the project file, I get two messages about `'[durango, 0]'` and `'[orbis, 0]'` missing (but not for x64). – Shahbaz May 14 '17 at 20:55
  • 1
    If the warning was showing a list of platforms, it should have given a warning about `'[durango, orbis, 0]'`, wouldn't you agree? Does it make sense that it generates two errors, each being a list, that overlap (0) but have mutually exclusive elements? – Shahbaz May 14 '17 at 20:56
  • Can you search through your solution and see if someone defined a custom build definition. Your message looks eerily familiar to something I've seen before when we had these in play. Check this article to help see if they exist : https://msdn.microsoft.com/en-us/library/hefydhhy.aspx – Travis Acton May 15 '17 at 23:19
  • @TravisActon, the solution contains two projects. One of them indeed has CustomBuild steps. **The warning is generated for both projects, though.** (I'm looking at the xml of the files) Inside the CustomBuild blocks, there are AdditionalInputs, Outputs, Message, Command and LinkObjects entries, all conditioned to `'$(Configuration)|$(Platform)'=='config|platform'` (for each config/platform I have). What in particular was causing these warnings in your case? – Shahbaz May 15 '17 at 23:47
  • It's been a significant time since I last saw this so it isn't particularly fresh on my mind but it revolved around a release portal we built to interact with TFS. We were basically storing configuration elements for pre and post build actions in a seperate database. We would then use the portal to kick off builds to specific environments (QA1, QA4, Stage,Dev2) The portal itself would take the parameters and feed pre-build parameters specific to the environment we were targeting. We would actually store transform variables in a very similiar manner with the $(variable) (1of 2) – Travis Acton May 16 '17 at 00:24
  • Some projects would fail on build with similar errors when a transform variable couldn't be directly matched to a variable in our configuration database...which of course would trigger more errors if there were references stored in other projects. Not sure if it is related to your issue but your error does jump out at me. I will try to jog my memory a bit more. It's been some time but hopefully this might point you in the right direction to start looking. – Travis Acton May 16 '17 at 00:30
  • You've accepted an answer based on an incorrect guess, and even given it a bounty, but did you ever find out the real answer? – ROX May 02 '18 at 14:46
  • @RoX, see my last comment on the answer. Also, see my `Resolved` edit on the question. – Shahbaz May 02 '18 at 16:53
  • Thanks. You mean the point about case in the spelling of the platform? I have seen this error before with exactly that cause, and correcting case fixed the problem. However I saw the warning yesterday for another reason (I know it was a different reason because I have since fixed it). – ROX May 03 '18 at 10:18
  • @ROX, yes, the case was the problem. You can add an answer with the other reason, I'm sure future visitors would want to know about both reasons. – Shahbaz May 03 '18 at 20:40

1 Answers1

2

I think you might have unmatched solution/project platform and build configurations, resulting in the rare case when visual studio defines or creates new ones: https://msdn.microsoft.com/en-us/library/kkz9kefa.aspx ending in the odd platform names '[some_platform, 0]', '[durango, 0]' and '[orbis, 0]' you have.

Now this is entirely my guess (since I could not find any documents to confirm it). But what that 0 actually means, is the reference to the default build configuration that project should use when you target those individual platforms. For instance, you usually have lines similar to this in the solution (.sln) file:
{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.Debug|Mixed Platforms.Build.0 = Debug|Any CPU

In the case above you would use build configuration 0 as the default build configuration when using msbuild solutionname.sln from the console. But since the entire platform was generated for that project, we of-course don't have a default build configuration either, so... lets generate. There is more details and examples of the default build-configuration in this post: Visual Studio solution file - what does the "Build.0" mean?

Now back to what might actually be your real problem. You mentioned SDK references, have you made sure they are pointing to the correct place and any environment variables is properly configured in visual studio? If not, the problem might be related to the warnings mentioned here: Platform 'Android' referenced in the project file 'san-angeles' cannot be found. The warning message on that question sure looks similar to the warning you have, only you have those oddly generated platform names.

Hope this will help you solve the problem.

Community
  • 1
  • 1
Anders Asplund
  • 575
  • 2
  • 7
  • About the SDK reference, yes it's ok. Among the three platforms I have (`orbis`, `x64` and `durango`) only `durango` has an SDKReference but both `durango` and `orbis` generate that warning. Also, the project builds fine. – Shahbaz May 15 '17 at 23:01
  • I'm afraid I don't really get the first paragraph. Are you saying I have a platform referenced in the project file but it's defined in "build configurations"? What exactly is a "build configuration" that is separate from the project file? – Shahbaz May 15 '17 at 23:03
  • The `Build.0` is indeed used in the `.sln` file (not with mixed, but for each platform individually) similar to how you've mentioned. _But since the entire platform was generated for that project, we of-course don't have a default build configuration either, so... lets generate._ Are you implying I should define a default build configuration? – Shahbaz May 15 '17 at 23:09
  • No, I would rather guess you have platforms referenced in the soultion file or some of the projects, but that is not defined in some of your project (.vcxproj files). In the example above, it's probably the c++ project "project". I do know that visual studio has some problems with commas in reference paths btw, and you mentioned something about commas in the reference path, do you have a comma in the path to that SDK's? – Anders Asplund May 15 '17 at 23:27
  • By comma do you perhaps mean semicolon (`;`)? Because windows (and hence vs) use `;` to delimit directories (instead of the standard `:`). The only SDKReference in the project file is this: `` (there is a comma (`,`)). Again, this builds fine. That SDKReference is conditioned to `'$(Platform)=='durango'`, yet the warning is also generated for `orbis`, but not for `x64`. – Shahbaz May 15 '17 at 23:51
  • Ok, since both projects are compiling and working just fine, there probably is no problem with the path. Could you however specify the errors you are getting a bit more? For instance is it the exact same error you are getting for both projects you have? Or is it rather that it's complaining about one platform in one projects, and another platform in the other project? – Anders Asplund May 16 '17 at 00:40
  • It's the exact same pair of warnings I get on both projects. Since it's not complaining about x64, I'm thinking maybe it has something to do with the fact that the other two are not "native" architectures. – Shahbaz May 16 '17 at 13:58
  • I'm giving you the bounty, since that 0 is probably what you mentioned. But nevertheless this is a sh*tty meaningless output and microsoft should be ashamed of itself. – Shahbaz May 19 '17 at 17:21
  • For future visitors, it turned out that the platform names are case-sensitive for the sake of this warning, and case insensitive everywhere else (hence everything building correctly). Correcting the case of the platform name made the warning go away. – Shahbaz Feb 15 '18 at 16:55
  • you reference a link that correctly explains what the build.0 means, but your answer assumes it means something different. It is not the default configuration to build. It is just controls that that project should be build for a given solution configuration. Default can be set in the project file (rather than the sln file), but these don't have 0 in the syntax – ROX May 02 '18 at 14:44