RADE has grown significantly in size and complexity over the past four years.  What started off as a relatively simple classic ASP application has grown to 8+ .NET assemblies, with numerous 3rd party DLL references.  Current R&D is going to further increase the size of the build. In addition to that, we've developed several vertical products on top of RADE which need to be updated as new revisions of the base framework are completed.

It's come to the point where I need to get to a one step build.  The first move in here was to implement Remotesoft Protector in my build process as protecting the assemblies ended up being one of the bigger pains in the butt when building.

So to kick things off, we need to work with MSBuild a little bit.  Originally, I tried using the <exec> call from MSBuild.  This didn't give me the flexibility to loop through the files being generated.  So I started writing a custom build task.  Please read this great article on building custom tasks if you are new to this.

In summary, I defined a number of get/set methods for the globals I wanted the build engine to set, and in the Execute function I set it up to loop through the passed .DLL files, and execute Protector on each.  After the dlls were processed, they were moved out of the protected folder and the protected folder was removed.  If you are having problems getting your task running, check out this article on debugging  custom MSBuild tasks.

RADE uses a Visual Studio 2008 Web Deployment Project to deploy all of the files on build, so to implement the new task we need to do some editing in the project.  Open the project either with a text editor, or in Visual Studio by a right click on the project and choosing "Open Project File".  This part is quite simple.  First ensure that the assembly generated by building your task is in the same folder as the web deployment .wdproj file.  Next we need to add a line near the top of the web deployment project:

   1: <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

   2:     <UsingTask TaskName="Landor.Deploy.BuildTasks.RemoteSoftProtector" AssemblyFile="Landor.Deploy.Buildtasks.dll"/>

   3:     <PropertyGroup>...

Here we point the UsingTask call to both the namespace and class of our protector code, as well assembly.  One more change to make.  Scroll to the end of the project and you should see a number of empty <Target> tags.  We need to add some code to the Name="Afterbuild" tag.

   1: <Target Name="AfterBuild">

   2:         <ItemGroup>

   3:             <DLLFiles Include="$(MSBuildProjectDirectory)\Release\Bin\*.dll"/>

   4:         </ItemGroup>

   5:         <RemoteSoftProtector

   6:             Files="@(DLLFiles)"

   7:             ProtectorEXEPath="C:\Program Files (x86)\Remotesoft\Protector\bin\protector.exe"

   8:             ProtectorParams="-neutral -string -cctor -clrversion v2.0.50727"

   9:             BinFolder="$(MSBuildProjectDirectory)\Release\Bin\"

  10:             Exclusions="AjaxControlToolkit.dll;Microsoft.Xml.Schema.Linq.dll;ZedGraph.Web.dll"

  11:         />

  12: </Target>

Two things occur here.  First, in the <Itemgroup> tag we are initializing a variable called DLLFiles, and it's getting all the .DLL files in the project's Release\Bin build folder.   Note that this process creates a semi-colon delimited list of full paths and files.

The next thing that occurs is actually calling the build task using the <RemoteSoftProtector> tag.  The tag name should/must match the name of the build tasks' class.  Within this tag, we are setting all of the defined public properties, using the same name as those defined with our build task class.

I've posted Visual Studio 2008 source/projects/solution

This concludes a day of fun learning how MSBuild and custom tasks work.  Hopefully it helps you out a bit.  Bugs or comments, let me know.

When .NET based assemblies go out the door, it's incredibly simple for others to get access to your code.   Download Lutz Roeder's Reflector and take a look at what some of your assemblies have to say.  The code visible is likely not going to be anywhere near as elegant as the original.  The comments will be gone.  The gist of what you are doing will be there.  If you would prefer that your work be a little tougher to get at, read on.

Obfuscation was one of my first answers to this problem.  An obfuscator ships with Visual Studio Pro, free and there are many available on the market.  Obfuscation just didn't do it for me.  I once helped a customer troubleshoot problems with one of their software solutions from an unnamed vendor using Reflector and walking through the obfuscated code.  This was really a painful experience, it does make it harder to figure out what is going on - but a friend of mine suggested a product that takes code protection one step further.

Hello Remotesoft Protector.  This product is pretty cool.  If you purchase the protector product you will receive three components.  Salamander .NET Decompiler, .NET Obfuscator, and .NET Protector.  Initially I was processing my assemblies with both the obfuscator and the protector.   Now a days, I pretty much only run my assemblies through the protector.

Once you've processed an assembly with the protector and you open it up in reflector things are going to look a little different.  Here is a little before and after action for you:

Now lets take a look at the same code, but after being protected:

That's it.  Protector has made all your code go bye bye =)  What's happened here?  As I understand it, Protector compiles all your managed .NET code into native code.  So, yes, is it possible to disassemble native binaries.  The difference here is the height of the bar - with plain .NET assemblies even my grand mother could get my code.  Reverse engineering a native assembly is a different story.  If someone with the skill to do that wants your code - well you must be writing some damn fine code.  It would probably be easier for that kind of person to write it from scratch =)

I've been working on increasing my Joel Test score lately.  One of my biggies is the one step build for RADE.  That sentence really doesn't do the task justice.  The first step I'm tackling in the one step build is automating the process of protecting my .NET assemblies.  I could not find any resources on doing with with MSBuild.  Once I get it working, I'll post some code.

All that said, I highly recommend you check out Protector if code protection is your thing.  The price is a little bit steep at 1899$ for 1-5 developers - but how much money have you invested in that one little DLL or EXE file?