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.
Related
I am hacking around a problem we've created for ourselves. What I would like to do is log a warning in our TFS builds for any code that is instantiating a specific class. I don't want a run time warning (I've got one in place already), I want a build time warning that ProjectX is using BadClass.cs. The idea being it will give us an additional place to see things that need to be fixed once our hack is no longer needed.
So something like this:
public class BadClass
{}
public class OkClass
{}
public class MyBadService
{
var a = new BadClass(); <-- Logs a warning to the build output
}
public class MyOkService
{
var a = new OkClass(); <-- Does not log a warning
}
Edit:
I do not like the idea of using Obsolete; its a misnomer. We've already got code with Obsolete attributes and this would get lost in the noise. I don't want a generic warning that I can't control the message for. I want bright neon signs with klaxons firing and a thousand exclamation points in the message. Basically everything I can do short of failing the build. I'm using the #warning precompiler directive right now and its mostly doing what I want but it requires a human to remember to add the warning. I'm looking for something more automagic. I've seen third party libraries do stuff like this so I know its possible.
Why not just use the Obsolete attribute? It can generate a build warning for you:
https://learn.microsoft.com/en-us/dotnet/api/system.obsoleteattribute?view=netframework-4.8
You can even make it emit an error too if you want.
The answer could be negative I think.
It seems that you use or call msbuild.exe to build your C# projects. But as far as I know, MSBuild in fact calls csc.exe to build C# projects in build time.
So actually what you want is logging a warning when the compiler compile the C# code if it recognize somewhere in your code uses the BadClass in build time.
If you have the source code of BadClass in the same solution, add a project reference format to the xx.csproj which contains BadClass, and set a #warning in the BadClass it may generate the warning in build time.
But I think the scenario you're in is something like: You developed one Assembly and distribute it to your user, so you want it generates a warning when the user calls one BadClass in your assembly and builds his own project to remind him of taking care when using this bad class. If so, this is impossible for msbuild AFAIK. If I misunderstand anything, feel free to know me know :)
Update:
As Daniel and Johnson said, ObsoleteAttribute is enough to do this. Though no valid way to generate warnings from msbuild aspect directly, but msbuild will call C# compiler during build process, so generates a compiler warning can output to build output window.
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.
I am using VS2010.I was changed my project and its dependent projects .Net Framework to 4.0 from 3.5.Now I could not attach the process,due to this I am not able to debug the code.
I have cleaned all the bin folders and rebuild the projects ,but still I am having following error.
Please help me to resolve this..
I'm not sure what the question is here. The error message clearly tells you that you need to
Turn off (disable) optimizations
Turn on (enable) debug info
Rebuild your project so those changes take effect.
Apparently you only did step #3.
Also see vs2010 debugging module was built without debugging information?, which may provide more information.
I also received this error, and did all the right things as described above - those have been my settings all along anyway. I even went so far as deleting the assembly from the long C:\Users... path in the error message - it still didn't cause that message to go away.
Then I tried putting a breakpoint in the source, which should not be allowed if the module really WAS built without debug information. And then ran the program and it stopped at the break point and I could do all the usual debugging.
So right now I'm just ignoring the message. I could do as suggested and disable the 'Warn if no user code on launch' option as suggested in the message, but I'm not doing that until I can spend some time working out why the message comes up at all.
Uncheck this option in Visual Studio 2012.This would solve this issue
I just converted a Framework project from Xcode 3 to Xcode 4. I've been building this project for years under every version of Xcode and Project Builder.
For some reason, Xcode 4 runs Build AST on all of my classes rather than Compile, which doesn't actually build the framework executable. On digging into it I found that this passes the -fsyntax-only flag to clang which tells it to stop after producing an Abstract Syntax Tree for each class. I have another Framework that builds fine in Xcode 4, and I've compared the build settings without uncovering anything that looks like it would cause this.
Does anyone have an idea what would make Xcode want to perform the Build AST action rather than Compile? And more to the point, how to turn that behavior off?
Thanks for any ideas...
Okay, I found that in my case I had a custom Build Rule for '*.i' files in my project. The clang build process apparently produces .i files (along with several others) as an intermediate product, so this rule was interfering and stopping it from completing all stages of the build. Removing the custom Build Rule allowed everything to build normally.
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.