MSBuild Logger Verbosity

When you build your .net 2.0 projects there are notes appear in the Output window. Those notes are generated by the MSBuild engine. By default the verbosity detailing level of those notes is very common and don't include all the output that given by MSBuild.
You can change the verbosity detailing level by changing the following key in the registry

HKEY_USERS\S-1-5-21-57989841-1409082233-839522115-1003\Software\Microsoft\VisualStudio\8.0\General

key value named MSBuildLoggerVerbosity.

There are four levels, the default is 2. If you want to see the messages then you have to set the value at least to 3. I don’t recommend setting the 4 level because then the amount of output is enormous and it is very hard to find something in it.

Extending the build process – GacUtil task

As part of planning a daily build process I needed to register the current assembly to the GAC. I was Surprised to find that there is no such a task that came with the VS tasks kit. And I was event more surprised to not find such a task in the common extension tasks kit for MSBuild. So I said "This all mechanism is so easily extendable so why no write a task for my own to cover this issue? – and practice in writing MSBuild tasks in the way". So that's what I did.
I write some custom task called GacUtil which get two parameters:
Assemblies – a list of assemblies to work with.
Command – the operation that should be made on the assemblies, Install or Uninstall.

You can use the command by simply add the "using task" attribute in to your .proj file for example.

<UsingTask TaskName="CostumTasks.GacUtilTask" AssemblyFile="$(SolutionDir)\CostumTasks\bin\Debug\CostumTasks.dll" />

And call the task that way

<gacutiltask command="Install" assemblies="$(TargetPath)"/>

The more recommended way is writing your own .tasks and .targets files, and put all your references in it.
The naming standard for such files is [companyName].targets/tasks.

You can download the source code and the .tasks and .target files from here and start work with them.

Daily Builds

I have started learning a while ago about automatic build tools. The purpose of such tools is to automate the build process of your application to determinate time interval - let say once a day. The benefits of such a process are:
1) Every morning you have most up to date application running in your test server.
2) In some future scenarios every morning you can get a list of all the tests that not run well by your unit tests.
3) Because the build process is occurring every day, its make a high quality level of the code made by the programmers' in order to keep the application work every night.

Apparently there is no shortage on the market of such tools. I chose the most common ones that used in the market.

1) MSBuild
2) NAnt
3) Cruise Control .net

After some testing I figure it out that all those tools are giving pretty much the same capabilities, all those tools define a new XML base language that uses targets to combine logical blocks and tasks to do atomic actions like copy directory, get latest from a safe source or open a new virtual directory in IIS.
Some tools, like Cruise Control .net give some extra capabilities like running automated build based on triggers like file change of check in to the safe source, but the base concept is the same.

I chose to concentrate on MSBuild, and it's not because I am a Microsoft freak it's because there is no benefits to the others tool on this one and I prefer to be sure to have support further on.

I did a presentation to my teammates about MSBuild and its concepts. So check it out.
MSBuild Presentation

By the way I forget to mention that all those tools are completely extendable by writing custom tasks and for each tool there is a large community that supports it and helps to solve issues.

Msbuild
NAnt
Cruise Control.net
more links are supplied within the presentation.

Have a nice work.

A great day at work

A couple of days ago I got a chance to be part of something amazing. I am working as a programmer for almost three year and I never been a part of something like that.

The story goes like this. As part of a new project that me and my team just started, we checking some tools and programs that we can get help of to manage faster development. In fact, one of our departments has an application that they have developed a while ago which almost completely covers one part of our project. So we ask them to come and install their application for us that we could check it.
The installation was compounded from two parts:
1) Installing an application's scheme of SDE – which is ESRI's answer for geo database.
2) Installing the application on one of out PCs, including some special configurations.

Although this is sound like common installation for every, or almost every, application, it is important for me to notes that our departments work in completely different environments almost without partnership; in fact this was one of the very few projects that those two departments took part in, and it's a great achievement for our company for its self.

My job in this story was to accompany the installation process and learn about it.
The other department sent a programmer and a DBA to handle the job. After couple of hours of standard installation drill the application, and it's all components, were installed. The DB was created including the necessary scheme. And we all site there and say our prayers that the application will work. But as you probably know it's never work for the first time… and apparently for us it didn’t for the second and the third also.

After a while and some tries in different directions we got a conclusion that there is a problem with some part of the code. But because the installation, as it should be, included only the dll's, without the source code, it was impossible to run a debugging process and see what is going on down there.
As I saw that they have some debugging issues, and because programming is our field, my team leader, Shani, and myself immediately run to help.
With some help of the Reflector we managed to take out the suspicious code and try to run it in deferent solution, after a while we discovered the problem, which by the way was a problem with the user mane that we taking from the active directory. After that it's all was working.

So you probably asking yourself "what was so amazing in this process... its sound like programmer common day". Don’t you?
So I tell you. During this process I learned about security and programming patterns. About advantages of the operations system that can be easily used which I had no idea about them. Also I learned about some cool tools that make my work easier and my applications stronger. But the most important thing that I learned from that event is that a huge amount of knowledge was lying under my nose and I didn't even have idea. And did I mention all this was in one day?

So I had a real great experience working like some kind of per programming with my colleague fellows and my conclusion to you is always look for a way to improve your work and yourself from your surrounded circle - friends, workmate, family or just cool dudes that you met in the local bar.

Take care.