Just Code it!

Comment or Leave a Message

Please Comment or Leave a Message if this is what you are looking for or if you have any question/comment/suggestion/request.

To me, one of the most surprising thing about NAnt is that it doesn’t support colours out of the box.
NAnt is an amazing tool that allows to build software through a set of really powerful tasks. You can download it from here: http://nant.sourceforge.net/.
I use it quite a lot in different projects and one thing I always missed is the support for colorised console output.
I think that echoing something using different colours helps a lot, even if only to provide a quick spottable info that can help the user (the guy in front of the pc that is waiting for the build to complete) to understand the build stage (especially if it is a long build with several stages).
As soon as I had some time to spend on it I decided to write this feature myself and here I am, sharing this with whoever needs it for its own personal/business process.
I provide the DLL that you can use freely. If you find it useful the only thing I ask is if you can leave a comment and if you have a web page, add a link to this page to help other users.

What it adds
In brief this is the list of functionalities that you will have:

  • setcolour – to select the current colour
  • pushcolour/popcolour/resetcolour – to manage a stack of colours, so that you can change a colour and go back to the previous when you are done.
  • echocolour – an upgrade to the base echo task that colours the message
  • execcolour – an upgrade to the base exec task that colours the output in case of error (behaviour and error colour configurable)
  • colourfail – an upgrade to any other generic NAnt task, operation or set of operations that colours the output in case of failure (error colour configurable)

The list of tasks that allow to use those functionalities are (in more detail): (Note that you can have this list using the <helpcolour /> task)


  • <setcolour [colour=”fc”] [bg=”bc”] [preserve=”tf”] /> – Set the current colour.
  • <pushcolour [colour=”fc”] [bg=”bc”] [preserve=”tf”] /> – Push the color in the stack of colours and set it as current colour.
  • <popcolour /> – Remove the color on the top of the stack and set the previous one as current colour.
  • <resetcolour /> – Reset the colours stack and set the original color as current colour.
  • <seterrorcolour [colour=”fc”] [bg=”bc”] /> – Set the colour to use when an error occurs during the execution of execcolour task.
  • <reseterrorcolour /> – Reset the default error colour (red on black background).
  • <echocolour message=”Message Here” [colour=”fc”] [bg=”bc”] [preserve=”tf”] /> – Echoes the message in the chosen colour.”
  • <execcolour [highlighterror=”tf”] …more… /> – Extends the default exec task adding colours capabilities (use the usual “exec” task parameter here). It shows the error using the error colour and, if used with failonerror=”false” and highlighterror=”true” shows the exec exit code using the error colour if it is different from 0 (and logs it as a warning).
  • <colourfail [colour=”fc”] [bg=”bc”]> …any othe task there… </colourfail> – Extends the failure colour to everything executed inside the colourfail initial and closing tags. E.g. <colourfail> <fail message=”simulated failure” /> </colourfail>
  • <initcolours [silent=”tf”] /> – Initialise the default colour using the current console colour. The default error colour is set to the current error color. Using silent=”true” the DLL version number will not be displayed when the first colour task will be used. NOTE: This task is optional and you can use all other tasks without worrying to use this at any time.
  • <helpcolour /> – Shows this help…

fc : specify the foreground colour to use.
bc : specify the background colour to use.
[…] : specify an optional parameter.
tf : use “true” or “false” there.
…more… : indicates other parameters.
preserve : Preserve the current fc and/or bc when fc and/or bc is not specified. This is false if unspecified.
highlighterror: This is false if unspecified.

How to set-up
To use this dll, put it somewhere where your NAnt executable can reach it. If you prefer you can directly add it in the same folder of NAnt.exe.
Somewhere at the start of your NAnt script add this line (assuming that it sits in the same folder):

From now on you will be able to access its functionalities in your script.

Feature – Colour Help Command (helpcolour)
Use this task as a reminder for the supported tasks:

Feature – Direct Colour Change (setcolour)
You can use console color using this syntax:

The output is:

Feature – Coloured Message (Echo Extension: echocolour)
A more direct way to output colour messages is using directly the echocolour task:

With this result:

Feature – Use Colour Stack (pushcolour, popcolour, resetcolour)
There is a way to use the colours pushing and popping them in and from a stack. This can be useful when invoking sub targets that have to set the colour for themselves but you want them to restore the colour to the previous one when finished.
This is a simple Example:

With this result:

To reset the stack at any point you can use the resetcolour task. Example:


This is a more complex example of stack usage:

With this result:

Feature – Exec with coloured failures (Exec Extension: execcolour)
In order to quickly use the exec task but with coloured failures, you can use the execcolours task. Those are some examples:
A Simple exec that fails (Building a solution with an error in it):

This is the output:

An option is to suppress the failure (as in exec task), but force to highlight the error anyway. This is optional:


Feature – Change Error Colour (seterrorcolour, reseterrorcolour)
The error colour can be changed at any time using seterrorcolour and reseterrorcolour (to bring it back to the default “red” colour):

And this an excerpt of the output:

Feature – Color the failure of any other task (Generic Extension: colourfail)
If you want to highlight the build failure of any other NAnt task or your other custom task, you can still do so using colourfail!
Here is a really simple example of usage:

And the result will be:

Another different example is:

Resulting in:

Of course you can wrap the whole script in this task, having the coloured error feature always active.
An example that shows this is action is the following:

With the expected result:

Feature – Init the default colour and error colour (initcolours)
This task is optional. Everything works even if this is never used.
You must use this as first task if you want to remove the display of the version number that is automatically shown the first time a colour task is used.
When used it will change the default colour and error colour using the current one. This allows to change the result of the task resetcolour and reseterrorcolour.
This is an example:


Note that the colour of the console is still recovered despite the default colours have been changed.

More about Colours
The colours must be colours recognised by the console. The system is quite robust but it is safer if you specify the colour using the correct case sensitive string. This because the core tries to match the string to an internal enumeration and this is why it needs to match.
In any case, if the colour is not recognised, or simply wrong, an error will fire allowing to fix the mistake.

Will generate:

I believe this DLL can offer a satisfying set of features to use colours in NAnt with a reasonable degree of flexibility.
Download and use it freely. If you like it, please add a comment and a link to this page to help others benefit of it.
If you have any suggestion, comments or if you want to make a request for something to add in future release, please leave a comment :).

Comment or Leave a Message

Please Comment or Leave a Message if this is what you are looking for or if you have any question/comment/suggestion/request.

If you are reading this post it is probably because you have some trouble trying to have your application to run on a system where some COMs dependencies don’t seem to be happily resolved, or because you can’t afford to register the COMs at all (policy?)… or if you don’t have any COM problem at all, well… keep reading. The DLL Hell is always behind the corner.
Because the problem is quite annoying when happens, I provide at least four solutions so that you can choose the one you find more comfortable to use :). Let me know which one you prefer and if you know other alternative ways to do it as painlessly as possible.

The Problem
Imagine to have a simple application that references a COM object. You try to build your COM and then your app, and eventually you try to run it on your machine and… it works! Good! So you happily go and copy your App and the DLL of the COM in a single folder on a second machine and… BUM! Your App crashes without hope.
So, what’s going on?
The problem relies on the fact that when you use a COM DLL (with Early Binding), you are somehow coupling your App with a precise version of your COM library. This means that if one day you or someone else upgrades the COM DLL, then the App will still continue to work using the original COM it was binded to. What really happens is that your App will not simply try to locate the DLL (using only its name) in the current folder and then in the PATH environment variable, but will actually use a GUID (the CLSID) to locate the COM DLL in the Windows Registry and from there locate the file in the file system. GUID stands for Globally Unique IDentifier (while CLSID is the CLaSs IDentifier) and is automatically generated for you when you create the COM object and automatically used when you reference your COM from your App. If you want to see how to use a COM you can have a look at my other post ([intlink id=”114″ type=”post”]Create a .NET COM and use it in Unmanaged C++[/intlink]).
This GUID is then the only thing that the App will use to locate the COM DLL, and in order to make this work you have to “Register” your COM classes as we already know.
So, what if you don’t want to register it?

Sample Scenario
Let’s assume that we have a couple of COM DLLs with one sample Object each and both with a simple (different) method defined. In my example I have these:

  • MyPippoCOM COM with a SillyAdder class (CoClass)
  • MyOtherCOM COM with a SmarterMultiplier CoClass
  • TestApp exe that uses the two previous COMs using Early Bindings

In TestApp I instantiate the objects using the ProgID.

The Tool
Fortunately Microsoft came up with a (almost) simple solution.
The trick is create a *special* file that will tell to our App how to behave and where to look for what it needs. This file is the “Manifest”.
As a brief description let’s just say that this is a simple XML file and in there we can specify where are the DLLs that we want to provide to our app, bypassing the normal searching behaviour.

The Problem of the Tool
The problem here is that writing what you need here is not always (actually almost never) easy. In fact, in order to describe the COM that you App will have to use, you must “describe” it, specifying all the GUIDs, ProgIds (if you need it), and other nasty details that are generally (and fortunately) auto-generated for us when we Create and use a COM in a normal/standard way… So why do we have to suffer now? Fortunately we don’t, we are safe this time as well :P.

The Basic Solution – Understand What’s Going On
Based on Microsoft Documentation, the way to create a manifest for your DLL is to use the Tool mt.exe (this is the Documentation).
With this tool you can generate the manifest that you will have to use with your App if you want to achieve our goal.
For example, considering our MyPippoCOM.dll DLL, we could do something like this (from the command prompt, in the folder where the dll and tlb files are stored):

This will generate a file named “mySample.manifest” that, in my case, will contain something like this:

At this point you could do the same thing for the other DLL and then (only after), create the manifest for your app.
This is because with this tool you can only specify one dll and tlb when you generate a manifest and consequently you cannot create a manifest with the data for both DLLs in one go. Fortunately though this tool allows you to merge multiple manifests! So you could use this as final step toward the creation of the Application manifest. I said “toward the creation” because unfortunately the manifest that you will have at the end of this process will be incomplete and could contain some errors as well if you didn’t follow exactly my example and you specified the dll and tlb file using an absolute/relative path instead. I’ll explain later how fix this. For now le’s see how could you merge the two manifests:

The result will be a file named “merged.manifest” that in my case will contain this:

As it stands you cannot use it directly. You need to rename it, fix a couple of things in it, adding some missing informations and you need to build the TestApp without embedding its manifest.
So, first things first. Go back in VS2005 and build our TestApp changing one setting. Open the project’s properties, expand the section “Manifest Tool” and enter in the “Input and Output” entry. In the option screen on the right set “Embed Manifest” to “No”.
Now you can build the project again and this time a file TestApp.exe.manifest (in my case) will sit next to the executable.
Now open it. It should look like this (the dependentAssembly section will include the proper assembly based on which type of build you selected, debug or release):

Now it is just a question to grab our previous merged manifest (from the two COMs) and copy all the content that appears inside the “assembly” tags into the TestApp.exe.manifest, just before the assembly closing tag. In my case this will be the result of this step:

Ok! Almost there.
The final step is to add something that mt.exe doesn’t add for us but that I like to have, the ProgID attribute. You have to do this by hand unfortunately. Just add this attribute to any comClass tag. The final result in my case is this (I optimised some tags a little bit as well):

Note that the ProgID should actually contain the version number as well (e.g. progid=”MyPippoCOM.SillyAdder.1″), but the other version does work if you don’t specify this number when creating the object in your code as in:

That’s all for this first long manual version.
There is a way to skip some steps and do it slightly more automatically.

The Semi-Practical Solution – The Slightly More Automatic Way
A way that I found helpful to adopt is to make usage of the post-build steps feature.
To keep it short and simple, what you can do is edit the post-build event for both of your COMs projects, adding somethig like this:

(and similarly for the other COM).
This will generate automatically a manifest named “manifest.manifest” (nice name uh? :P) in the project output folder.
Then edit the TestApp project’s properties, writing in “Manifest Tool | Input Output | Additional Manifest Files” the location of any manifest that you want to merge.
Those two settings will essentially automate the creation and merge of the manifest that we previously did manually!
You will have to do the final fixes anyway. Maybe you can try to automate this as well :).

The Practical Solution – The Fast Way
I found a way to cheat and generate the manifest with even less work. It is sort of cheating, but it is fast and works! :).
Instead of opening Visual Studio 2005, open VS2010 and create a new project. Just any project, a console app for example.
Now right click the References tab in the solution explorer and select “Add Reference…”.
In the window that will pop-up select “Browse” and navigate where the first COM DLL is located and add it.
Repeat the same process for all the other COMs.
When the References list is completed, expand it and select all the COMs that you just added.
Go in the “Properties” window of the selected references entries and change the value of “Isolated” to True.
Job Done!
Now when you will build the project a .manifest file will be automatically generated and it will contain the correct XML for both COMs.
mine looks like this:

Notice that it contains the ProgID attribute with the version number (“.1″) at the end of the string (see: progid=”MyPippoCOM.SillyAdder.1”). You will have to remove it if you don’t specify it in your TestApp application.
Apart from this, you can directly use this as input manifest for the TestApp saving even more time! :) (you can consider to change the assemblyIdentity attribute if you do this).
NOTE: In order to apply this solution the COMs must be registered on the developer machine. This must be said just in case you did some previous steps and you unregistered them and you didn’t rebuild the projects ever after.

The Speedy Solution – The Last Tip!
There is a final tip to avoid even more typing. The only thing to prepare is the merged manifest in the way you prefer and use this one as Additional Manifest File in the Input and Output section of the Manifest Tool in the properties of the C++ TestApp project. Then, instead of setting the Embed Manifest to “No”, Leave it to “Yes”.
This will generate the application exe without any needed manifest and this is ready to be executed side-by-side with the COM DLLs.
No more editing, no more problems :).

Note about VB6 COMs
If you have VB6 COMs the previous method will still work really well (even with a correct ProgID), but if you want to explore even alternative ways, there is an interesting tool that you can try to use to generate the manifest for each specific COM.
You can find the tool here: Make My Manifest
What it does is essentially create a manifest for any VB6 projects (not only COMs) generating a complete manifest with all the project’s COM dependencies.
So this is more exhaustive than our single C++ COM manifest and this means that if you have multiple VB6 COMs that uses others COMs, then the manifests could contain common elements and thus the merge should take care of this. But for the rest it is a quite nice tool to use, so give it a try.

The DLL Hell is not a random name and what I tried to cover in this post is just the tip of the iceberg.
I wanted to write this because I found quite difficult to gather the practical information that I ended up discovering personally through a long series of frustrating experiments in order to properly understand and faultlessly solve the main problem.
I hope that this helped you and you found it interesting.
Let me know if you discovered other ways to solve it or if you have any suggestion/question/information that you want to share ;).

Comment or Leave a Message

Please Comment or Leave a Message if this is what you are looking for or if you have any question/comment/suggestion/request.

Well, there is enough material here to write a book… or at least a bunch of chapters. I don’t like to go through pages and pages that explain the concept but don’t give a tangible example. So, because the matter here is quite boring and not exciting, I’ll go directly to the point.

The goal here is to create a component in .NET, register it as COM and use it in a nice(!) and not-so-painful way, from C++.

This said let’s start with the bullet points:

  1. Create a .NET project and tell it some way that the result of it will be a COM object
  2. Write a bunch of methods, just to have something to test
  3. Start a C++ project and import all that we need to use our newly created .NET COM component
  4. Initialise and use it in code
  5. Deploy it on a different machine (not the one we are using as development environment)
  6. Enjoy and Comment

When you first see this you could think: “Well… easy!”. Well… not exactly. There are a bunch of stuff to consider if you don’t want to bang your head on the monitor (and keyboard) because you cannot see/use your simple object.

First things first: The .NET COM project

The first things to do here is to choose you preferred Visual Studio environment and launch it. I am using VS2010 as an example.
Start a new project, select Class Library and give it a name (I named mine COMTest). Rename the default class to something sensible (such as “MyPippoClass”… or even more sensible :P).

Write some code

In your custom class (MyPippoClass) write something like this:

Now, in order to make it visible as COM we need to generate the tlb file. In order to do this, right-click on the project and select Properties. Select the “Build” tab and (down in that page) tick the checkbox “Register for COM interop”.
Now, when you build the project you will see that, beside the .dll, there is a file with the same name and extension .tlb (COMTest.tlb in my case). Not finished yet. If you want to use the classes defined in you COM object (and I bet that you want) than in the property windows of the project select the “Application” tab and click on “Assembly Information…”. In the form that will pop-up tick the “Make assembly COM-Visible” checkbox.
Once this is done, you are ready to rock.

The C++ project

Now open you VS environment and create a new C++ project. Create a simple console app and go where the main is.
Now the only (well… almost) thing to do is to import our COM object through its Type Library file (the .tlb that we generated with so much love).
Assuming that you will have the include folder settings configured properly (to point where the type library file is), add this just before the main:

Finally some meat now. Go in the main and write:

Well,  now you will be probably surpised (or frustrated) that myPippoClass does not show any method. Yes, this is the default behaviour of your COM creation. Why? Well, the reason behind this is to allow more robustness when the client will be deployed. Once this is done in fact, and you will go and change the COM component (e.g. adding more stuff), the existing client will continue to work. You are essentially forced to use late binding to interact with your COM object.

If you don’t believe the intellisense and you try to write (C++) this anyway:

you will obtain an error similar to:

The only pain is that to make this work, you have to code in a way that is not very elegant and nice. You will have to query the method that you want to invoke on the instantiated COM object…
Something like this (don’t be scared):

Are you still there? Good!

If you don’t like it, I don’t like it. It is clear why, but what if we don’t care about this problem and we want to simplify all this?
Fortunately a solution exists, and it is pretty simple as well. Hurray!

Go back to your C# project, expand the “Properties” folder in your solution explorer and open the “AssemblyInfo.cs” file.
Just to put some order in what we will do, go where the line “[assembly: ComVisible(true)]” is (if you have “false” instead of “true” then you did something wrong in one of the initial steps. Simply double-check them or change the “false” to “true”).
Immediately underneath add this line:

Note here: Types that use a dual interface allow clients to bind to a specific interface layout. As already mentioned (and this is why it is generally discouraged, despite the ugly code): any changes in a future version to the layout of the type or any base types will break COM clients that bind to the interface. But… But now our C++ side is nicer to work with.

Go to the C++ code and try to use your COM instance. Be sure that the dll (and tlb) are updated, and you will see that your instance will expose (thanks to the intellisense)  all the methods and properties that we wrote.
Note that if the intellisense still doesn’t work, it could be due to intellisense itself that is somehow slow and dumb sometime (especially in C++). But if you write the following code the compiler should build without any problem.

Of course this will build but will not work. We still need some extra code to allow our program to interact with COMs.

As first line in our main function add this:

Then at the end don’t forget to add:

Now it should be happy!

If you did everything correctly and you run this on your dev machine you should see this output:

Isn’t it cool? Yes! Well… somehow.

Deploying it on another pc

If you try to copy this exe to another machine and the COM dll as well and you try to launch the exe you will obtain a not-so-nice (assuming that we are doing all in debug mode): “This application has requested the Runtime to terminate it in an unusual way. Please contact the application’s support team for more information.”

What’s now?! Well, you need to tell the system how to find your COM DLL. You can simply do it registering the dll (in the target machine) using the RegAsm tool provided with the .NET framework.
You can find it in:

or (if you are not using the .NET 4.0):

Simply run (assuming RegAsm.exe in your path and the dll in your current folder):

The output of the registration operation should be similar to this:

If you launch your C++ exe now everything should work fine :).

One or few more words. If you move your exe in a folder without your DLL you will have again the nasty crash. To solve this problem (in case you care about this) you need to run another tool (gacutil) that we will essentially use to register our DLL in the global assemblies cache.
After locating it just run it on your DLL with the /if option that will essentially force the installation of the DLL in the GAC.

Theoretically it should simply be:

Practically instead it depends on your framework version and what you have installed on your machine.

If you build your code using the .NET framework 4.0, then probably you will have to copy the gacutil tool from your dev pc into the other.
The fastest way (just to have it working without too many operations) is to copy the whole folder:

in your target machine and run the gacutil in there.
Once you do it you will see that it doesn’t work… again? Yes again. This is because, in order to do this, we need to give a strong name to our assembly.
The output of the gacutil registration will in fact be:

Well… let’s do it.

There are two ways of doing it, one semi-manual and the other more automated.
Just to explore both options let’s see both of them starting from the semi-manual one.

Open the command prompt (on your dev pc) and go where the generated COM DLL is.  Then from here (just for simplicity) run the command:

if your sn.exe is not in the path, then use the one in the same folder of the gacutil writing something like this (if you don’t want to move folder and assuming that you have my folder structure):

the result will be a file called (surprise) test.snk and the console output will be:

Well done.

Now open you C# project and go again in the property windows, “Signing” tab now. Tick the “Sign the assembly” option and from here you can select the file that we have just created (test.snk).
If you want to use the more automatic way directly instead, from here open the drop down box and select “<New…>”. In the dialog box that will pop-up remove the tick from “Protect my key file with a password” and enter a nice name (e.g. “MyComTestKeys”). Once you will press “OK” the system will automatically create a “MyComTestKeys.snk” file in your project and will give a strong name to the assembly.

If you build now and deploy the DLL and try to run the gacutil again you will succeed!

Note that you will need to unregister/register again the DLL with the RegAsm tool.

Now sit, relax, take a breath and launch again the C++ exe in its own isolated folder.

Well Done!

The journey ends… well… actually it starts here.

Please comment and leave any feedback/request about this or any other argument (it can be completely unrelated if you want). I will try to answer and explain more concepts in the future posts.

For now: Good Bye! :)