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/
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 currently have a solution with a number of projects which include Unit Tests.
We've got a CI build and a separate Scheduled build and I would like to be able to run Code Coverage on the latter (not the CI).
At the moment we are using Visual Studio 2010 and TFS 2008. None of these can be changed.
I've looked around for hours and lots of suggestions mention a Process tab to select in the Build Definition however further investigation shows that the combination of VS/TFS that we have does not have this option.
Another source says to modify some testsettings such that they contain the Code Coverage option (which I have done) and then define the Test Settings file in the build - but I have no idea how to do this (http://www.codewrecks.com/blog/index.php/2010/06/14/running-code-coverage-in-tfs2010-builds/).
I have a testsettings configuration that will run code coverage locally so my issue is that I need the MSBuild TFSBuild.proj file to know which testsettings file to use when running it's tests (through the <RunTest>true</RunTest> option).
Any help on this would be greatly appreciated. I've trawled through the various other proposed solutions but none seem to match this. They either use a better version of TFS, or do something else.
EDIT. I suspect I might be restricted to using an Exec task within the build script and running the Vsperfmon.exe command with some arguments. If this is the case please provide an example because I've no idea how to capture the results from this command and tie them to my Scheduled build.
Thanks all.
Please hear me out as this question has been modified extensively.
I have an msbuild target that I want to execute after each project in my solution is built from the IDE. I can easily do this by creating an msbuild replica of my solution, but you can't use it within visual studio. You can go through the projects properies as specify an after build process, but this is quite tedious, especially if you have more than 2 projects.
Is there a better way to execute a target for all projects in a solution within the IDE? I just can't believe that VS2010 doesn't give you an easier option.
BTW, does VS 2012 Beta support a full MsBuild file instead of the brain dead solution file?
What I get from your question is that you've extended the build process and then created a 'shadow' msbuild file that does what the solution file normally ends up doing during build. As you are aware, solution files are a rather unfortunate visual studio only concept. That issue is nearly impossible to work around.
The idiomatic approach to this problem is leave the solution file alone and modify the individual .csproj files to include the custom build steps that each project would need to be completed according to your process. NuGet does this when you use it, so does NotifyPropertyWeaver. (NuGet works around the solution issue by introducing a '$(SolutionDir)' property)
As an aside, I'm not sure how valuable 'building an installer' is to the individual developer on your team and including in the build seems like it adds friction rather than removes it.
If this is for a custom build server, there's no need to use the solution file at all if you don't mind keeping the two in sync and I'd wholeheartedly recommend that approach.
You can debug msbuild using the visual studio IDE.
There is an undocumented registry switch to enable. See this thorough msdn article:http://blogs.msdn.com/b/visualstudio/archive/2010/07/06/debugging-msbuild-script-with-visual-studio.aspx
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.
I've inherited a body of Visual C++ source that consists of about a dozen sub-projects. One of these is an empty "MakeAll" project that depends on all the others, so I can build the entire project by setting the MakeAll project active and selecting "Build All."
I'd like to automate this process, and coming from a linux environment, my instinct was to generate a Makefile and build from the command line. The IDE will generate .mak files for each of the sub-projects, but not for the top-level MakeAll. (I'm assuming this is because it contains nothing but dependencies.)
The linux answer would be a Makefile that simply descends into each of the sub-projects and executes make in each one. But a quick look at the .mak files showed that each wants to be told which of several configurations to use -- and apparently some use Debug, some use Release, and some use configurations concocted by a previous developer.
What's the accepted way to build a set of projects like this from the command line?
Thank you!
You don't have to use make - if you have everything as solution files (.sln) then you can automate the build by using the msbuild tool:
msbuild solution.sln
Also, why do you have a "MakeAll" project? Visual Studio doesn't require this kind of hackery, just do a "build all" and it will build everything satisfying dependancies just like a typical "make all" rule would.