We are building lots of projects using msbuild command line. It returns 0 upon (0)Error(s). But it also returns 0 if there are warnings.
At this time we can't set our projects to treat Warnings as Errors as we have 350+ projects.
Is there a way to detect if there were warnings only? Does msbuild can be made to return something special about this scenario?
Thanks
Related
I have a Visual Studio linker error that popped up recently. I stumbled upon a workaround but it is driving me crazy that I can't figure out why it is happening in the first place. I need to learn how to better diagnose it.
So my question is not about how to fix it, but how to diagnose it better. In short what I'm trying to learn here is how to get the linker (or some other tool) to tell me more info about the problem. So this question is not about this particular enum or how I coded it exactly.
The project is a C++/CLI project I have a managed enum which I wanted to refer to in several other header files. So I tried to put a forward declaration of it in the shared file that I use for all my other forward declarations. That started giving me this error.
1>profileregioncli.obj : error LNK2022: metadata operation failed (801311E4) : Duplicate managed types have different visibilities.
OK, fine. My forward declaration probably looks different to the linker than the definition. But I cannot see how the declarations are different in code. And technically, since the linker doesn't even bother to tell me exactly what type is involved I cannot even be 100% sure it's this enum.
So how do I determine following two things?
Exactly what symbol is mismatching AND
Exactly what is the difference (to the linker) between the two versions.
Obviously the first item I probably know. The second, not at all.
What I have tried so far
I've tried setting linker output to full verbosity but it doesn't tell me anything new. Here is the full linker output
1>------ Build started: Project: Core.Sdk, Configuration: Release x64 ------
1>Generating code
1>0 of 1470 functions ( 0.0%) were compiled, the rest were copied from previous compilation.
1> 0 functions were new in current compilation
1> 0 functions had inline decision re-evaluated but remain unchanged
1>Finished generating code
1>profileregioncli.obj : error LNK2022: metadata operation failed (801311E4) : Duplicate managed types have different visibilities.
1>LINK : fatal error LNK1255: link failed because of metadata errors
1>Done building project "corecli_v16.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 10 up-to-date, 0 skipped ==========
ILDasm Microsoft recommends trying to use ILDasm for this error but that doesn't work. When I tried using it from the command line as they described, it tells me I have to use it interactive mode. When I then try to use it in interactive mode and open up the .OBJ file in question, it wants an .EXE or DLL, not an .OBJ
MAP File I tried changing the linker settings to generate a MAP file but it never does. So I'm guessing thats not generated unless linking is successful.
Change Something, anything Sometimes the best way to figure out an obscure linker error is to make a change -- any change -- to force the linker to give you a different error so I tried changing the managed enum type to derive from System:UInt32 (a valid thing to do which I do with some of my other managed enums) just to see if I would get a different error. And I did get it to tell me that there were two different definitions of the enum in question, but not what they were. But aside from that, no extra information
But this still leads me to want to see the two definitions side-by-side. Not in code but as the linker sees them. How do I do that?
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).
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.
I've some sql projects with the property "Treat Warnings as Errors" enabled for every build configuration set (Debug, Release, etc.).
Building locally this property works without problem (so every warning is managed as error).
Using instead the MSBuild-Definition tool the same warnings are not managed as errors but just as warnings.
I cannot add the MS Build Argument /p:TreatWarningsAsErrors=True to the Build level because in the same build definition there are other projects (not only sql projects) where the property "Treat Warnings as Errors" isn't enabled, so every build is going to fail.
What I want is to have the possibility to set my Build definition so that they can manage some project as "TreatWarningsAsErrors" and some other not.
I read in some documents that the build definition should inherit its property from the project built.
Is this wrong? Should I just add some configuration to my Build Process Template?
I am using the TfvcTemplate.12.xaml
If you need some other details just ask me.
Hope you can help me
Thanks
I have tested in my VS 2015.3 + TFS 2015.3, and used XAML Build with default build process template TfvcTemplate.12.xaml, but couldn't reproduce your issue.
If I enable "Treat Warnings as Errors" for one project in a solution, I would get an error for XAML build. If I disable this option, there is no error but warning in XAML build:
Please compare your environment with mine, and double check whether
you have checked in your solution after you enable the "Treat Warnings
as Errors" option.
We like the Warnings as Errors setting as we have a policy of not checking in code with warnings and this is the only effective way we have found to enforce it.
We also like to use the Obsolete attribute to flag methods that should not be used any more.
Problem is that adding a Obsolete attribute to a method or class immediately causes tons of projects to not build (not to mention problems if a .NET API call is deprecated).
Does anyone have a good solution to this?
We want a visible, hard-to-ignore indicator that you are using a deprecated API but that does not cause the build to fail. We want to see the warnings in the IDE and in CI builds.
A simple solution would be to have a build configuration (e.g. your debug build configuration) without warnings as errors. If, however, the point is to flag to your developers that something is wrong on build, that's no good as they'll forget to do a release build before they check in.
Alternately, rather than using "warnings as errors" you could set up your ruleset to throw errors itself rather than raise warnings. This will mean, of course, that non-CA warnings won't cause errors.
The best solution, I think, would be to handle it on the server side. Ideally you'd have some sort of gated checkin so that your code repository rejects commits that don't build using its build definition (with warnings-as-errors on, and your developers can leave warnings-as-errors off). I suspect that's a TFS-2k10-only feature though.
This other stack overflow post should help:
https://stackoverflow.com/a/468166/9195608
Basically it says:
You can add a WarningsNotAsErrors-tag in the project file.
<PropertyGroup>
...
...
<WarningsNotAsErrors>612,618</WarningsNotAsErrors>
</PropertyGroup>
Note: 612 and 618 are both warnings about Obsolete
The difference between 612 and 618 is the comment of the ObsoleteAttribute. An ObsoleteAttribute without comment generates the error 612, and one with a comment generates 618.
As explained here /sdl (Enable Additional Security Checks), if you switch off SDL the compiler will treat it as a warning.
I made a simple change of a property to an auto property and broke the build because the property was referenced in a conditional compilation section. I was building in debug and the reference was in a section of code that's only compiled in release configuration. Is there any way to catch these errors without manually switching the build configuration in Visual Studio and building in each mode?
I have a CI server so the error was caught right away but I hate breaking the build.
You need to build each configuration to see if something conditional breaks one of them. You can avoid the manual step using the 'batch build' option from the build menu though.
You have to build under each configuration.
Remember that if you were to use all the conditional compiled sections at the same time, its likely that it wouldn't build i.e. if is debug use a, if not use b.
You don't need to do it manually though - that said, double compilation time is an awful thing.