Obfuscation, Code Analysis, and Check-In policies

As mentioned before, we’ve started to use SmartAssembly to obfuscate some of our products. We also use Team Foundation Server (TFS) as source control and build server. Using obfuscation with code analysis caused some issues, which were compounded by our check-in policies.

Obfuscation prevents analysis of code using reflection. Code analysis uses reflection to analyse code. There is, therefore, a bit of a problem if you try to use both during your build process, either within Visual Studio, or on a build server. Code analysis would often crash:

… and if you looked in the Code Analysis logs, you’d see it was FXCop failing:

Typically, the errors are things like “Index was outside the bounds of the array”.

Therefore, if you have a check-in policy that demands that code analysis has been run, you can’t run obfuscation within your Visual Studio builds. There is a risk that the obfuscated assembly will cause Code Analysis to crash, and if Code Analysis doesn’t complete, you won’t be able to check-in your code. The example code in my previous post shows how to set up a condition so that you don’t obfuscate locally built assembly. That way, you can at least check your code in, and during development I’m not too concerned about the assembly being obfuscated. In fact, I’d rather it wasn’t, so that I could debug it more easily.

However, you’ve still got the problem of builds on the build server trying to run code analysis on an obfuscated assembly. They will still generate the same error, and you really do have to obfuscate at the point. There are three solutions that I found:

  1. Turn off code analysis within the build process. Edit your build definition, go to the Process tab, and set Code Analysis to “Never”

    You will not then see code analysis warnings/errors within TFS. However, developers will still have to run code analysis before check-in, so they should still see any warnings/errors at that time.
  2. Modify the .csproj file. You could duplicate the ProjectGroup for Release in the .csproj file, add conditions to them so one runs inside Visual Studio and the other outside (i.e. on build server), and finally set the Code Analysis to not run on the build server:

    This works – I tried it – but I don’t like modifying the .csproj file if I can avoid it.
  3. Configure Code Analysis to run for Debug builds only. Then configure your build process to run Code Analysis “As Configured“. This means that you’ll have to do a Debug build before you save pending changes, but during the server’s build it won’t run Code Analysis on the Release configuration (which is what we’re obfuscating):

That second option feels a bit complicated to me, and the first optoin won’t give me any warnings in my build process, so I prefer the third option. I mean, Debug seems likely to be what I’d be using during development anyway…

Advertisements
Obfuscation, Code Analysis, and Check-In policies

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s