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.
Related
I just created a Report Project with 1 .rdl in Visual Studio 2008. I then deployed the report to the SSRS Server and I can now see the report in the Report manager.
I made a change to the report using report builder 3.0.
Is there a way that I can "get latest version" from the report server of the .rdl when I open my report project in Visual Studio again?
I am guessing that 1 way would be to download the .rdl and add back (overwriting) to the report project but I am wondering if VS has a built in function to take care of this for you?
There is no built in functionality in VS to attach to an SSRS instance and pull down the .rdl files. Since they can be moved, edited and deleted, outside of the designer there could be numerous issues with doing that. Just check all your local project files into source control and manually update if needed. Since I don't edit outside of VS I never had to deal with "pulling the latest version from ssrs". However, I have come across third party tools that may have functionality to make it easier.
If this is going to become a daily struggle for you then you may want to take the time now to automate the process using the ReportExecution2010 or ReportExecution2005 web service api.
Visual Studio is used to create and deploy reports, once they are deployed, there are no links between the report in Visual Studio and the Report Server, and there will never be. Think about it, you can deploy the report to X servers, so how could Visual Studio find which report you are talking about.
To ensure you are working on the latest version, you will have to download it and overwrite as you say, although I would compare it instead to see if there are changes not deployed.
If you are working with other developers that would potentially redeploy the report, then you can just check the last modification user of the report.
In all cases, I would strongly suggest to always check-in/commit when you deploy a report.
If you want to download several reports from the report server, then you could use a tool like RSScripter for example.
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.
TFS 2012 includes excellent support for code-reviewing changesets. However, we have some legacy projects that we want to code review. Once the quality has been brought up to spec, we will start using changeset reviews - however the code changes infrequently, so it's not practical to just review the changesets and improve quality through natural code-churn.
Is it possible to code-review a file or project in it's entirety, rather than just a changeset?
In TFS 2012 this is not an option. If the project is small enough there is a trick, you can right-click the folder in source control, do "checkout..." and then request the review. That allows you to review up to 4000 files at a time.
In TFS 2013 a new feature was added, Lightweight Code Commenting in Web Access. This allows you to annotate the code directly from the code tab in Web Access.
There are 3rd party code review options available on Codeplex, I haven't used them in quite a while, but they might add something more to your liking:
Team review
Team Code Review Workflow
Malevich
Our team are looking into implementing Code Analysis as a check in policy in TFS.
We've decided on which rules we want to enforce but won't be applying the policies to TFS for a while as we are currently migrating to TFS 2010.
In the meantime to get used to it and start removing Code Analysis warnings the dev team are going to start manually enabling Code Analysis.
So, is there a way we can publish or automatically enforce a set of rules without having to manually edit the properties for every project in every solution?
For sharing Code Analysis settings between projects in VS 2008, see
http://blogs.msdn.com/b/codeanalysis/archive/2006/11/16/faq-how-do-i-share-managed-code-analysis-rule-settings-over-multiple-projects-david-kean.aspx. (The article was written for VS 2005, but the same approach is appropriate in VS 2008 as well. In VS 2010, use of a shared rule set file is a better approach, although it may be specified using the same imported target mechanism.)
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.