I have just recently installed cppcheck which had some pretty good recommendations for static analysis of c++ code online. cppcheck is installed properly and I can run it successfully from command line or the gui. I then installed the Visual Studio Plugin v1.1.0 for cppcheck and I am very disappointed with this plugin.
The project I am working on is so large it just seems to hang, although there is no feedback so I can't say if it's doing anything at all, and what appears to be minimal support for troubleshooting. I was hoping that maybe some proficient users could make some recommendations on how to improve the performance.
I have already removed all checks other than Errors, which is not ideal but I am attempting to speed it up by reducing what it needs to do.
I have attempted to add a regular expression to the exclude include files but I cannot be sure it is even working.
I really don't have time to grab the source code and start debugging it.
I would really like to embed this tool inside of visual studio so that all the developers will actually use it. I have also added cppcheck as an external tool into visual studio, but it really is just a poor man’s attempt to do what the plugin really should do, especially since macros have been removed from visual studio so I cant run it automatically on save.
http://www.codeproject.com/Tips/472065/Poor-Man-s-Visual-Studio-Cppcheck-Integration
I think it will greatly increase the likelyhood that the developers use the tool if cppcheck is set up to run on save, which is a great feature of the plugin, if it would just work.
In the end I would just really like this plugin to work.
In the end I decided to add the cppcheckgui.exe to my list of external tools in visual studio. It circumvents the plugin but still works easily for my needs.
I have found using cppcheck together with visual studio's built in code analysis has proven to work very successfully. Both focus on different problems in the source code and the usage of both together I believe provides a more complete analysis of my code.
Related
Where I work, we've gone to great lengths to create a build script in Fake that does a whole host of things, so that developers can check what's going to happen on the TeamCity server before committing. It's great when run from the command line, but I'd really like the ability to have that script called when doing a build from within Visual Studio.
From my own research, I've not found anything that currently allows this, nor have I found any VSIX that does what I want. I'm currently running on the assumption that if I want to proceed with this thinking, that I will need to write a VS Extension myself.
Does anyone here know of any existing VSIX, or any way to change the default behaviour of build?
For reference, target VS is 2015.
If it's just parameters you're trying to pass eg.
code.exe -b
Then you can change the build settings in the solution under properties>debug.
Visual Studio and TFS have both tools to collect and report on code coverage for a project or solution. What we're interested in knowing, though, is how much of the changed code has been covered by tests. We'd like to be able to identify a baseline changeset in TFS and then get a report on what code was changed in the current build, what portion of it was covered by testing, and most importantly, what portion wasn't. As far as I can see, the code coverage reports and analysis in Visual Studio
don't take into consideration what code has changed--they only tell you about code coverage for the entire project or solution.
Unfortunately, there's no out of the box functionality from TFS or Visual Studio for getting what you want.
The Code Churn and Code Coverage perspectives from the TFS data warehouse won't help much as the code churn perspective only tracks lines of code that changed, not which methods were changed.
Looking at an alternate option, you might be able to get what you're after using SonarQube's differential views but they are date based, not changeset/commit based. Plus the SCM plugin needed hasn't been tested against TF Version Control so I don't know if it will work (I haven't tried it myself). If you're using git with TFS then it should work fine, you'll just have to go through the hassle of setting it all up.
If you are looking at alternatives, NDepend can provide this feature and it has pretty good integration with Visual Studio.
NDepend lets you compare two versions of a codebase. You are able to choose what the baseline is, for example a specific build from last release or just the previous build. You can then query against the diff.
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
Why should one go for Windows Installer XML (WiX) when we have in built .net MSI installer?
It would take me hours to rant about everything I hate about VDPROJ. I won't because in my (expert) opinion it's already settled law that VDPROJ sucks. If your install is so simple that you haven't noticed any problems, then be my guess and stick with it. But if you already find yourself fighting the tool trying to get it to do things it doesn't do, then take my advice and dump it fast for WiX.
10 things I hate about VDPROJ
No MSBuild Support. Sure, you can call devenv from the command
line but it's not as good.
No exposing of the critical concept of
a component. Every file/reg key is a keyfile of it's own component.
No effective way to fully exclude automatic dependency scanning.
Shortcuts are always Advertised
No way to describe a service.
No way to describe many things which leads to overuse of custom
actions.
No way to fine control the scheduling / execution of
custom actions. Too abstracted.
Abstraction is wrong. Deferred
CA's are scheduled with Impersonation which breaks on Vista.
Various limitations lead you down a path of massaging the built MSI
during postbuild to get around all the limiations. Results in a
very poor build automation hacks.
Merge Module directory tables
are authored incorrectly.
100 other things suck that I'm not
remembering right now.
The introduction of WiX tutorial gives the basic idea about WiX advantages comparing to other setup development tools (including VS setup projects):
declarative approach
unrestricted access to Windows
Installer functionality
source code instead of GUI-based
assembly of information
complete integration into application
build processes
possible integration with application
development
support for team development, both
in-house and third-party
free, open source
Hope this helps.
Visual Studio deployment packages can only be built by visual studio. They cannot be built using plain MSBuild command lines, which makes them less than ideal for e.g. build servers.
All the above answers have included most of the annoying features of Visual studio setup projects (.VDPROJ), one thing that most people have missed.
.VDPROJ file format is such that, and if we make a small
change to one single entry it completely rewrites all the entries
within which makes it impossible to merge changes from 2 different
branches.
Some of us don't want to use / can't use the .NET installer.
Some of us don't want to have to install Visual Studio to distribute a program, written in, say, Borland Delphi. WiX and .NET have nothing to do with one another.
WiX provdes a much more complete feature set than the .NET installer.
I think most people here understand the importance of fully automated builds.
The problem is one of our project is now using an integrated Visual Studio Setup project (vdproj) and has recently been ported to Visual Studio 2008. Unfortunatly, those won't build in MSBuild and calling devenv.exe /build on 2008 just crashes, apparently it does that on all multi core computer (!!!). So now I have the choice to either rollback to .Net 2.0 and 2005 or simply ditch Visual Studio deployement, but first, I'd like a second opinion.
Anyone knows of another automated way to build a .vdproj that will not require us to open the IDE and click on stuff?
WiX was what I had in mind when saying we would ditch vdproj. Do you have any experience with it, good things, caveat?
The low cost solution is to switch to using ClickOnce, which you can automate using MSBuild. But if you still need to create a Windows Installer package, you will need to convert your project to WiX (pretty straight foward) and build that with your solution.
This will get you started:
Automate Releases With MSBuild And Windows Installer XML
I've used WiX a little bit before, and generally I found that it's great once you figure out what to do but there is a steep learning curve. If you spend a solid day going over the WiX tutorial you should be be able to get 80% of your setup working.
WiX Toolset Tutorial
I had the same requirement and ended up using what is suggested in these two links
David Williams Blog
MSDN article
Basically, since Team Build, by itself, will not build the setup projects for you, this approach has you add a new build step after the regular build is complete. This step fires off a second build by launching the devenv.exe. The IDE will build your setup files. The extra build is a bit costly but we only needed it for builds that were going to be pushed out. The Daily build at most would need this customization our CI build does not need to build setup files each time.
After that you execute some Copy commands, once again build steps that show up in your Team System build results, to move the setup files to a network share etc.
It feels a bit like a kluge at first, but it does work, it is also a full-fledged part of the automated build in Team System so it worked for my Continuous Integration goals.