I've been authoring some test data for my ongoing Mapguide Enterprise \ MGOS work.  For consistency with my existing tabular test data, I need to migrate some Mapguide 6.5 maps over to Enterprise.  This is quite the chore.  I really wish Autodesk would have kept updating the Mapguide 6.5 Data Migration Tool and bring that up to support a current release of Mapguide.  Even with the tools flaws, it was still a good start on migration - but oh well, that's another rant completely..and maybe another side project that I just don't have time for =)

Anyhow, I wanted to share the Pima County Mapguide Color Chart.  I can't believe I hadn't found this page sooner.  A fantastic, and crucial reference.   Tons of useful settings for the chart generator.  Show the hex codes for using the colors in HTML, Decimal RGB values for Mapguide Enterprise \ Autocad.  The colors under the Decimal heading are the RGB values - ordered in Red, Green, Blue.  I've been using the chart in this config.

Thanks Pima County.  Hopefully, you guys were able to come up with a programmatic method of creating this chart.  I'd hate to be the guy tasked with 'eyedropping' all these colors using Photoshop or something.

The decimal values by the way should work with AutoCAD too.

SourceGear recently released a 64 bit native built of the Vault server.  I'm on a real x64 kick lately and really enjoy not seeing *32 beside my processes in task manager.  Vault is one of the best source control providers out there, and you cannot beat the price either.  It is core to my professional life.  Next to Visual Studio - it is one of the most important pieces of software I use. So, did a quick backup of my databases, un-installed the old server and installed the shiny new x64 code.  Problems!

First off, my server was running IIS in 32 bit mode.  This was required to run the previous releases of Vault.  Once the install was complete, I started a dos window and set IIS back to 64 bit:

cscript.exe C:\Inetpub\AdminScripts\adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 0

Then I ran an iisreset.

When I fired up my browser to check the vault service, there was a problem.  All it would display was "Service Unavailable".  At this point, even html files were not being served out.  Did a search on the Sourcegear forums and couldn't find anything.  It's been a long week and I was not firing on all cylinders - so I called up the support team.  (Good thing I renewed my maintenance, oh, this morning =D).  At this point Beth from SourceGear and I brainstormed through the situation and came to the following conclusions:

I was the first customer to call with x64 problems.  Yay for being first!

In IIS Manager, the application pool was disabled.  A check of the event logs showed the following information:

Source: W3SVC-WP

Event ID: 2268

Could not load all ISAPI filters for site/service.  Therefore startup aborted.

This prompted a check the web service extensions.  Sure enough, there was a web service extension there configured for ASP.NET pointing to the 32 Bit assemblies.  I prohibited this extension, and added a new one pointing to the 64 bit aspnet_isapi.dll.  Re-enable the application pool and load a page in the browser - still nothing.

Finally - the last step needed to get everything serving properly was to run the following from the x64 framework folder:

c:\windows\microsoft.net\framework64\v2.0.50727\aspnet_regiis -I -enable

So in summary the following steps should get your Vault server upgraded and running in native x64.  Bear in mind, my server is ONLY running Vault and these steps will break ASP.NET 1.1 applications (and lower) and possibly other code you might have running on the server.

   1: Backup SGVault and SGMaster databases (did I even need to include this?)

   2: Un-install the 32 bit Vault server

   3: Install the 64 bit Vault server

   4: Run cscript.exe C:\Inetpub\AdminScripts\adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 0

   5: Run c:\windows\microsoft.net\framework64\v2.0.50727\aspnet_regiis -I -enable

   6: Start IIS Manager. 

   7: Double check the vault virtual directories to ensure the ASP.NET version is set to v2.0

   8: Prohibit the ASP.Net 32 bit isapi web service extension

   9: Add the ASP.Net 64 bit isapi web service extension

  10: run IISReset.exe

mmmm x64 goodness.  Thanks again to Beth for helping me work through this =)

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.

Hey Visitors,

One of my colleagues let me know that things are a little wonky here when viewing in the page in Internet Explorer (Thanks Shawn) .  I think I've figured out what the problem is - but haven't found a fix just yet.  Hopefully will get things looking proper for you guys soon.

sorry about that..

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?