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:
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.
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.
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.