Automating the Righthand Dataset Visualizer build process and a refresh build

Since the last version released I become aware of an issue in the visualizer. If you were working on a project that referenced newer DevExpress assemblies the visualizer might have reported an exception due to the binary incompatibility with its references to the DevExpress assemblies - a assembly binding issue.

(If you want just the binaries you can skip to the end of the article and download them.)

The solution is to use a custom build of DevExpress assemblies. If you have their sources you can build your custom DevExpress assemblies using these useful scripts.

Then I have to use those custom built assemblies with my visualizer but I want to use them only for release build, not for debug. So I created a folder named CustomAssemblies under visualizer solution. I added a reference path to this folder to all of the visualizer projects. Which means that the MSBuild will use assemblies in this folder if they are present or ones from GAC (the original ones) if the folder is empty. Unfortunatelly the reference paths are global to the project and you can't have two different sets for two different configurations.

So the building of the release version looks like: populate CustomAssemblies folder with custom DevExpress assemblies, run MSBuild on Release configuration and at the end clear the CustomAssemblies folder so the debug version works with the original DevExpress assemblies. But there is one more obstacle. The license.licx file lists public key of the DevExpress assemblies and it doesn't match the one found in custom version. So I have to replace all occurences of the original public key with my custom version public key before the build and restore the originals after the build. Problems solved.

The actual release process involves also {SmartAssembly} which merges all assemblies into a single file and signing it with a certificate+timestamping and finally zipping the rather large result. Because I am not a masochist I decided to create a FinalBuilder project that does all of this automatically for me (except for building custom DevExpress assemblies).

Let me know if there are still problems!

Righthand.DebuggerVisualizer.Dataset.2008_v1.0.1.zip (12.67 mb)

Righthand.DebuggerVisualizer.Dataset.2010_v1.0.1.zip (12.67 mb)

Read more about Righthand DataSet Visualizer here.

Final Builder as a helper

Today I’ve tried to ILMerge a WinForms application that uses a bunch of DevExpress controls to produce a single executable in response to this thread. Just for testing purposes.

The thing is that ILMerge is a console application that requires a healthy amount of command line parameters. Not wanting to type them like crazy, I’ve opted to use ILMerge action within Final Builder that provides an UI for entering parameters (which are mostly long paths to assemblies involved in merging):

image

Instead of writing all those paths in command line and figuring out the command line parameters syntax I just clicked few “folder buttons” and navigated through open file dialogs.

The bottom line is that I’ve spent half a minute with Final Builder instead of many minutes in command prompt. The only drawback is that I’ve spent additional minutes writing this post.

Looks like I’ve found another use for Final Builder as well.

Packing assemblies to a single file for Righthand.Dataset.Visualizer

A while ago I’ve created Righthand.DataSet.Visualizer, an advanced DataSet visualizer. Today I’ve added support for displaying a single table as well. It wasn’t a big deal but I guess people will find it useful.

Now, there is one things I weren’t too happy about until today: I reference a lot of DevExpress assemblies and I have to redistribute all those assemblies along mine two (my visualizer comes in form of two assemblies). Which makes a lot of assemblies in total and even worse, if two visualizers use slightly different DevExpress versions you are in for a trouble.

So I’ve decided to pack everything to a single file. ILMerge, a free assembly merging tool from Microsoft, won’t work for me since it has problems with reference to Microsoft.VisualStudio.DebuggerVisualizers even though I don’t want to redistribute it. So I tried Xenocode Postbuild for .NET which does all sort of hacky things with .net assemblies, it even allows to create a setup that doesn’t require .net framework installed at the target machine. Among other features (obfuscation, optimization, etc.) it provides an assembly merging option that I successfully used in my case. Here are the required steps for my case:

1. Start Xenocode Postbuild for .NET, click on Application tab. Use Add… button to add required assemblies to pack together (you can add assemblies individually or pick most important ones and then use Scan Dependencies button to add referenced ones):

application

2. If you want only to pack assemblies then use Null – For test and debugging purposes or any other preset you want, just make sure you set other options appropriately.

presets

 

 

 

3. On the Protection tab I did uncheck all metadata obfuscation (since I am not after obfuscation here) by right clicking on the root node and selecting Unselect Tree menu item. I don’t use any Disassembler Suppression either. I left moderate code obfuscation (level 3 in scale 0..4), just for testing – this option shouldn’t cause any trouble since it should keep functionality the same. If there are problems with the later it means that the tool sucks heavily.

protection

4. Clear all checkboxes in Optimize tab.

5. On the Output tab I made sure that Single application executable option in Link and Code Generation group is selected and Righthand.DebugerVisualizer.Dataset.Visualizer assembly is the main one. I also selected .\Setup for the output folder.

output

6. By clicking Xenocode Application button the final, single file, output is written to the disk.

And that’s it. I got a single file with all required assemblies packed together. Just that easy. Note that I intentionally used only a fraction of Postbuild power.

If you use frequently Postbuild you should also consider using Final Builder tool, an automated build and release management tool that supports Postbuild out of the box (I am sure other such tools support Postbuild as well).

And finally, here is the updated visualizer:

RightHand.DebugerVisualizer.Dataset.Visualizer 0.9.14.zip (7.60 mb)

Let me know if there are any problems or if you have any improvement wish.

FinalBuilder4 action for LLBLGenPro available

Yesterday I crafted a [FB4] action for [LGP] that invokes its command line code generator utility (CliGenerator). You can find free download here.
Note: CliGenerator is included with [LGP] SDK which is an extra download available for customers (actually you have to build the utility from sources that ship with SDK).

FinalBuilder4 action for running CodeSmith templates

The past week I was busy creating an automated template based system for generating Developer Express' XPO source code. Heart of the system is based on CodeSmith and my custom templates (perhaps more details about the system in a later post).
Once I've finished all my templates for generating fine XPO code (everything is really powerful and flexible, trust me :-)) I had to find a way to automate the (re)build since there is not only one template.

One of the option was to use CodeSmithGenerator that spits out code based on input parameters in XML file that is part of your project (the same system is used by MSDataSetGenerator). The only weakness of this approach is that it requires several clicks if you have more than one template.

So I went with out of IDE build process because I like to do everything within the single action. Again, I faced three choices:

  1. Use good old command line bat file.
    This would do, but feedback is poor and it won't do handle Visual Source Safe.
  2. Use MSBuild tool that comes with .net 2.
    CodeSmith 3.2 comes with custom MSBuild taks that takes care of running the template generator. However, MSBuild is rather limited out of the box - no UI and no VSS control.
  3. FinalBuilder4. This is great automated build tool and perfect for me in this case. The only drawback is that it doesn't know how to run CodeSmith generator. On the other hand it does everything else.

I went with option 3. But I did have to build an action for running CodeSmith generator. Fortunately for me, build custom actions for FB4 is really simple (I did it before for XSD tool). After a hour or so of coding in VBScript (the easiest way to create a simple FinalBuilder4 action) CodeSmith action was created. The settings screen looks like this:

There are is no support for merging at this point simply because I didn't need it. I might add it in next version.

The result is that I simply invoke FinalBuilder4 via a shortcut and it does everything for me (check out files before, runs CodeSmith generator and check in files after).

You can find CodeSmith action here.

FinalBuilder 4 is out and very useful

If you do serious development then you probably know that you have to deliver executables to your client or to a tester occasionally or perhaps every day, every week, etc. When the project grows it becomes more and more annoying and error prone building it, including all files, copying it to the right folder, notifying the person(s), etc - you probably know all that already. That's why one has to use a proper build tool instead of manually hassle all that steps.
That's why I decided to try FinalBuilder 4 for my VS.NET 2003/.net 1.1 application. Build processes for this application includes building two different configurations and a third, obfuscated version (using Dotfuscator), creating help files (NDoc), an XML schema for certain objects, including some additional files and copy everything to a target folder - more than enough possibilities for a human error.
Creating a build automation rules out the human error and with FinalBuilder 4 it took me only an hour or so - it supports myriad of build actions (against various 3rd party products) out of the box, basically almost everything I needed (except for the XSD thing). All of the actions have an UI designer so setting them properly is just a matter of few clicks and key presses – easy and straightforward. And if it happens that an action you need is missing it is very easy to develop your own using your favorite development technology (COM, scripting, .net). I’ll write more about developing custom actions in the future.
The bottom line is that FinalBuilder 4 proved very useful and valuable tool for me. Setting up a new build process (without my prior knowledge of FB) was very easy and fast and all the actions I need were already there. I guess I could achieve similar automation using free NAnt tool but it would certainly took me more time and I guess NAnt doesn’t have all of the actions FB4 provides out of the box.