I've created a custom fxCop Rules and integrated them in visual studio 2010 by following
this tutorial
Everything seemed to work just fine except that the fxCop rules are running only on the first build after I make any change in the source code (even just adding a space). Additional builds, (without making any changes in the source code) do not produce any FxCop warrning.
I'm guessing it has something to do with that fact c# MSbuild "Build" target doesn't really re-compile if the source files timestamps are the same as the last compiled assembly timestamp
How can I make the FxCop Code Analysis to run every build?
A couple of things come to mind:
Because as you say, MSBuild may decide the build target is up to date, you could try running FxCop as a post-build step.
Code Analysis creates a .CodeAnalysisLog.xml and .lastcodeanalysiscucceeded file fore each analysed file. Maybe deleting these files before building would also help.
Related
I have a solution called MainWindow.vs2015.sln for my Application. This has nearly 100 Projects and it builds perfectly in Visual Studio 2015. When I build the solution from the command line using devenv, it also works perfectly and there are no errors.
However, when I build from the command line, and then open Visual Studio 2015 and build it again, expecting an almost instantaneous build as I had already built from the command line, it builds the whole thing all over again and I am sat there for up to nearly 30 mins waiting for something to build all over again.
Is there some kind of difference between the devenv command and Visual Studio builds?
P.S I have also MSBuild as well as devenv and have had the same problem.
devenv MainWindow.vs2015.sln /Build "Debug ALL"
What's your project type? VB.net, C# or C++?
For .net projects:
If we create a new VS2015 C# project in command-line, build it in Debug+x64 combination. After that when open the project in IDE and build it, it will display Up-To-Date, and won't compile and build again since nothing changes.
So if you meet the build twice issue in C# projects, set the Build Output verbosity to Detailed or higher in VS to see detailed info about the build process.
After that, when you again meet this issue, trying reading the very first of the log to see the reason why VS builds it again! Check if you have some files missing or set as Copy Always like this.
For C++ projects:
If you're in a solution with many C++ projects in it. I'm afraid the answer could be negative. I test it in VS2015 C++ projects and I can reproduce same issue. I found if we create a C++ project, build it in command-line and then VS. VS will consider it not to be up-to-date and try to build it again...
Something interesting is if we build it not by command-line, instead we build it twice in VS, VS can recognize it's update-to-date and won't waste time to build it the second time.
So I suggest you could avoid building it in command-line before building in VS. Cause there's no advantage that we build the project using two ways while we don't do actual modify to the source files. Also, since there's something that can be improved about the Up-To-Date check in VS for C++ projects, you can post a feature request in DC and you can get help from the Product Team there.
In addition: Please make sure the Configuration+Platform you use to build solution in command-line are the same when you build in VS IDE.
Hope it makes some help :)
I have a question regarding the difference I have noticed when building a solution file using MSBuild from command line and when doing it inside Visual Studio 2013 Update 4. The solution file I am using contains a lot of projects.
Case: Using MSBuild
After successfully building the solution file, if I try to build it again, MSBuild notifies me that the projects are up-to-date and it doesn't try to compile any source files, which is evidently the expected behavior. Nevertheless, it actually tries to execute or goes through the targets in the Build step trying to determine whether the Output files are out-of-date and this occurs for every project that is existent in the solution. Even though it doesn't build the solution again, the process of checking time stamps of files for each project actually takes quite a long time.
Case: Using Visual Studio
When doing it inside Visual Studio, after a successful build, if I try to build the solution again, then it automatically notifies me that the projects are up-to-date. It actually takes few seconds to return this output. Looking at the build output, I noticed Visual Studio doesn't really execute targets in the Build step to conclude that the projects are up-to-date. So I figured it must be using something different to check the statuses of the projects.
I really want to bridge the performance gap between these two "worlds". I would appreciate any help or hints in regards to how Visual Studio is performing this check or ways I could implement something similar in MSBuild.
Cheers!
I have recently converted a mid-sized Visual Studio 2005 solution to Visual Studio 2010.
One of the projects contains files which are not C/C++ files and are compiled using a batch file running a custom build tool. The output of the custom build step is some C++ files, which must be compiled after that.
The output of the custom build step in the properties for the relevant files is correctly set to the generated C++ files.
The problem is that sometimes VS2010 tries to compile the generated C++ files before the files with the custom build step, which means in a clean build it fails to find the C++ files and fails. If I try building several times eventually it would compile the custom files and then the build will succeed, but this is obviously not a good solution for automated build.
In VS2005 there is no problem building this project, but VS2010 fails to determine the correct compile order from the outputs of the custom build step. Is there another way to force correct compile order in VS2010?
Visual Studio supports parallel builds, it can build more than one project at the same time. This will not work properly if it cannot properly see the dependencies between projects. A custom build can certainly be a troublemaker here. The number of parallel builds is configurable, setting it to 1 would be a very crude but effective workaround. Tools + Options, Projects and Solutions, Build and Run, "maximum number of parallel project builds" setting.
But don't do that, parallel builds can be a huge time saver. You fix this kind of problem by setting project dependencies explicitly. Right-click the project that uses the generated C++ files in the Solution Explorer window and click Project Dependencies. Tick the check box for the project that produces the C++ files. In case it is relevant to other readers, check this answer for a way to create a project that only does the custom build step and nothing else.
Visual Studio 2008 by default executes custom build tools first. The order can be changed via right click menu on project with command "Tool Build Order". This facility is not available in Visual Studio 2010. I do not know of a work-around.
Consider using Visual Studio 2010's "Properties >> Configuration Properties >> Build Events >> Pre-Build Event" as the place where you should issue command(s) to build source files that must be compiled first. In the Command Line field, call upon the cl.exe compiler or use a small external makefile to compile those files. Visual Studio will then compile the rest of your project following this initial step.
I resolved my problem when I noticed that my custom build step runs for only one file at a time. It runs for the next file on the next build etc.
The reason apparently is that my custom build steps are calling a batch file and VS2010 creates one temporary batch file to execute all custom build files.
The solution was pointed in this discussion:
http://social.msdn.microsoft.com/Forums/en-HK/msbuild/thread/ca392036-ebdb-4812-930e-f90aa445cca5
It is simply to prefix all calls to batch files with a "call" statement, thus not terminating the execution of the master batch file prematurely.
Is there a way to integrate StyleCop in a NAnt script such that the build fails if there are too many style violations?
There doesn't seem to be a NAnt task for StyleCop, but we've found StyleCopCmd. However this only seems to generate an XML file as output that we'd have to parse. Is there some easier solution?
Yes - I set StyleCop up at work just last week! (I didn't use anything other than StyleCop...)
Basically, all I needed to do, was to get StyleCop working in Visual Studio 2008, making sure that my codebase passed all of it's warnings, and then changed the setting in the .csproj file to make it's findings Errors, instead of Warnings.
Then, when I ran the same NAnt script, the build should pass as before.
But the trick is to go back into your code, violate one of the rules but quit out of VS2008 and then run your build script. The code should fail the StyleCop rule and fail your build.
Hope this helps!
You don't need to do anything with NAnt at all.
You just have to two things once:
add two lines to every .csproj file
include the StyleCop files in your project and put them into source control
You can find a more detailed description of the process here:
http://blogs.msdn.com/b/sourceanalysis/archive/2008/05/24/source-analysis-msbuild-integration.aspx
After that, StyleCop will run on EVERY build, no matter on what machine (and without installing it on each machine) and no matter how the build was started (from Visual Studio, from MSBuild...).
So, as long as NAnt calls MSBuild to actually build the solution, StyleCop will run as well.
In case you don't want to do it thru MSBuild, you can do it using StyleCopCLI http://stylecopcli.sourceforge.net/
Will Visual Studio choke on customized .csproj files?
For example, I wanted to add a Target to update the version number in all AssemblyInfo.cs files. I plan to invoke this from the command line with MSbuild.
As another example, I would like to include the build timestamp into the compile, like so. This would be a pre-compile step (I guess), and unlike the example above, this one would run from within a build inside Visual Studio.
Will VS be ok with this?
As long as the code is a valid MSBuild extension, Visual Studio should be able to handle it. Under the hood the project files are really just MSBuild files and MSBuild does the dirty work of the VS build system. So as long as the file remains a valid MSBuild file it should be just fine.
Yes it does allow customizations. We integrated FxCop with our release-mode builds this way.
It will complain when you first load the project file after it's been edited, saying "it's been tampered with, do you wish to continue loading?" Just hit yes and continue on your merry way. It also lets you check a box to ignore the rest of the projects in the solution for the same warning.