Posts Tagged ‘visual studio’

Quickly, run!! It’s the Cyclomatic!

September 28, 2011 2 comments

Cyclomatic….the first time I saw that word pop up in a Visual Studio Code Analysis warning, I thought I was seeing things. It sounded like some cheesy killer robot from a bad 1950’s sci-fi movie. But no, it’s a real thing. And it’s not nearly as complicated as it sounds (no pun intended).

Cyclomatic Complexity is, simply put, a single number that represents the number of independent paths through your code. The idea is that the higher the cyclomatic complexity, the less maintainable and more error-prone your code will be. Generally, cyclomatic complexity is classified as follows:

Complexity Description
1 – 10 simple code, low risk
11 – 20 moderately complex code, moderate risk
21 – 50 complex code, high risk
51+ overly complex code, virtually untestable and unmaintainable, unacceptable risk

So what should you do with this? Try to keep you cyclomatic complexity as low as possible, that’s what. A good rule of thumb is to keep it at 10 or lower, although code analysis tools like Visual Studio and FxCop won’t usually complain until you hit 25 or so. Visual Studio will calculate this for you (right-click on a project, choose “Code Metrics”). However, it doesn’t work for websites. There is a third-party alternative that will called NDepend, but it isn’t free for commercial use. And even for academic or non-commercial use, you have to renew the free license about every month. If anyone knows of any good free alternatives, please share!



Code Coverage and Strongly Signed Assemblies

September 28, 2011 Leave a comment

I had a problem the other day that stumped me for a while. We just started a new project and immediately dove in to start coding. A few days later, I decided it was time to clean up the code before it got out of hand, so I ran Code Analysis and started cleaning up the problems. One I came across was this on:

System.IO.FileLoadException: Could not load file or assembly ‘xxxxxx’ or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A). File name: ‘xxxxxx’ —> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A)

This puzzled me, because I had just finished signing the assembly with a strong name. After some Googling, I realized that it was due to the code coverage I had recently configured. After running code coverage, Visual Studio needs to re-sign the assemblies, and there is a separate place to define the key for that re-signing process. To get to it, open up your .testsettings file, go to the “Data and Diagnostics” section, click on “Code Coverage”, then click the “Configure” button above.

Re-Signing Assemblies


Team Foundation Server vs. Subversion – An Objective Comparison

June 25, 2010 22 comments

I asked by my client to write up a comparison of Microsoft Team Foundation Server (TFS) and one other SCM (Software Configuration Management) system, so they could evaluate whether TFS was a goof solution or not. I picked Subversion as the other one to compare to, because it is one of the most popular systems out there. I tried to stay away from most of the “religious wars” about TFS vs. Subversion and tried to look at it objectively in several key areas.

Ease of Use and Learning Curve

TFS: For developers with a background in using Visual SourceSafe and Microsoft development tools, TFS is much more familiar.

Subversion: This requires more of a learning curve for developers familiar with Microsoft environments. Instead of the more familiar check-in/check-out paradigm, Subversion uses the edit/merge/commit concept.

IDE Integration

TFS: By far the best integration into the Visual Studio IDE, and the best choice for programming in .NET languages. Not the best choice if you’re not developing in Visual Studio.


Subversion: Fairly good integration into Visual Studio, especially with additional third-party tools and plug-ins, but not as good as TFS. This is probably the better choice if you’re not programming in a .NET language, though, especially if you’re not using Visual Studio.


Scope and Productivity

TFS: In addition to source control, TFS also has features that help with project management, especially Agile development, test driven development (TDD), managing test scripts, and defect tracking. TFS is not marketed as a pure source control product, it is an application lifecycle management product.

Subversion: Subversion is only a source control tool, and doesn’t include any project management, testing, or defect tracking functionality.



TFS: TFS is integrated with Active Directory, and users are Active Directory users. Has a nice GUI interface for management. TFS also has better support for implementing overall corporate or project check-in policies, and better support for measuring metrics.

Subversion: Subversion can be made to work with Active Directory, but it can be tricky to set up.


Features Unique to Each System:

TFS (not available on Subversion):

  • Shelving – Shelving is a way of saving all of the changes from your local development workstation to the TFS server without actually checking in. At a later time you, or anyone else, can “un-shelve” them to a workstation. This can be useful in a variety of situations:
    • Allowing others to review your code on their own machine
    • Switching tasks, for example to fix a defect, before you’re done with the code you have checked out.
    • Saving your progress onto a server, which is backed up.
  • Work Item Integration – associating a check-in to a work item, such as a defect or task. That code can then be tracked along with that work item.
  • Merge History Tracking – stores history of all merges and allows you to query it. This is great for collaborative team environments.

Subversion (not available on TFS):

  • Anonymous Access – Anyone can grab a read-only copy of the code to look at it. This is a bigger advantage for open source development environments than it is for the typical corporate IT environment.
  • Patch Submission – Subversion can compare two completely different builds of the code and generate a patch to update one version to the other. While TFS can do something like this, it is much easier to do in Subversion.
  • Offline Support – Subversion allows for offline work, when the user is not connected to the network or is not on-site. Again, this isn’t a big deal for most corporate IT environments but can be important for open source development.


Web Server

TFS: TFS requires IIS as a web server.

Subversion: Subversion is designed to work with Apache, not IIS. It can be made to work with IIS, but most of those solutions still require Apache to be installed and proxies to be created between the two.


Software Requirements

TFS: Windows Server 2003 or 2008, IIS, Active Directory, SQL Server.

Subversion: Apache, MySQL



  • Visual Studio 2010 Ultimate (7 licenses) – retail is $6900/license, but the price varies greatly on volume of licenses and contracts or agreements previously existing with Microsoft. It also depends if you have an MSDN Subscription or not (or if you buy one along with Visual Studio). Other editions of Visual Studio 2010 will have more limited functionality with TFS, but will also cost less.
  • Team Foundation Server 2010 – $500
  • TFS Client Access License – $500 for first 5 developers, plus $500/developer after that.

Subversion: Free (open source)

All in all, I think both systems are quite capable. Currently we use Visual SourceSafe 2005, so pretty much anything would be an improvement. However, TFS is a better choice for us overall because:

  1. We’re exclusively in a .NET development environment.
  2. We’re working at a large government agency, so the cost isn’t a huge obstacle.
  3. The client likes the support that comes with TFS.
  4. The client already has contracts in place with Microsoft, thus lowering their initial cost of adoption for TFS.

For open source projects, or small projects either at home or at start-ups, I think Subversion would be an excellent alternative.