Alot of these are very good questions but the set that really struck out at me were...

Do your developers have to consider obfuscation? or just your build engineer?
How does this effect your design?

Obviously an answer of build engineer only to the first question pretty much answers the second question. There is however an implicit design decisision which must be made in order to allow for this to happen. You cannot use reflections to dynamically load items based upon name. If you did there would necesarily be a dependency of in depth knowledge on the part of the build engineer.

I personally use obfusication at times (rarely) as I find it to be of little actual protection. If someone seeing your object structure will allow trade secrets to be revealed or will allow them to by-pass security in some way; you have much bigger problems. Keep in mind that with obfusication your code is still intact .. just looks a bit different. While it may take someone longer to realize the relationship between A2332 and C3423 than it would for them to realize the relationship between Customer and Orders ... they can still learn it.

For a process ... it is generally accepted that obfusication should occur as part of your staging or release cycle. Generally speaking unit tests are not run as part of the obfusication process (obfusication should by its very nature be transparent) but integration tests ARE generally run. The integration tests should pick up things such as not being able to dynamically load a type through reflections.

Because it is generally applied during the staging or release cycle other things such as continuous integration are generally not effected.


Hope this is useful for you.

Cheers,

Greg

One possible way is to run peverify.exe to check if everything has been done properly.

Below is a nice wrapper for peverify that can be integrated into the build cycle:

www.jasonbock.net/.../Default.aspx" rel="nofollow">www.jasonbock.net/.../Default.aspx">www.jasonbock.net/.../Default.aspx" rel="nofollow">www.jasonbock.net/.../Default.aspx

There is an app called assembly lockbox that encrypts the assemblies after they have been compiled. You dont need the encrypted versions of the assemblies at all until it is time to ship. For debugging you can just drop the unencrypted assemblies into the application folder and they will be used automatically instead of the encrypted versions.

You can find it at http://alb.gibwo.com" rel="nofollow">http://alb.gibwo.com">http://alb.gibwo.com" rel="nofollow">http://alb.gibwo.com