NAnt and the .Net 4 error

NAnt threw this odd error today.

The reason for it being odd was the version of the .Net framework being used in the call: .Net 4.0, instead of 3.5.  While I have 4.0 installed, I was trying to build a 3.5 project.

A little searching and I soon had a good guide of how to build 4.0 projects using NAnt, but this wasn't the solution to my problem.

Why 4.0?

Now it is possible to tell NAnt which framework to use, the -t: switch from the command line or in the main NAnt.exe.config file. I tried, and failed. NAnt threw the same error.

I wanted to stop NAnt using .Net 4.0, but how? Well, near the bottom of the config file is a list of supported Frameworks, of which 4.0 is one.

Removing the entry for 4.0 fixed the problem. Certainly this is a quick fix as NAnt has a problem with .Net 4.0 on my PC, but not a problem to be fixed today.

Update

Thanks to Rawdon for mentioning the path to the configuration file. You can find this in %InstallLocation%\NAnt\bin\NAnt.exe.config

Also from the comments. Paul Stewart has found the cause of the problem and written it up in this post.

TFS and MSBuild properties

My current client uses TFS as build server and MSBuild for deployment scripts. Whenever I have to change the scripts I spend time searching for the various properties which they expose. So this is my reminder, to kick start the process next time.

MSBuild

There are many different ways of using MSBuild but the list of Reserved Properties is always a good start. An example property is “$MSBuildProjectFile”, which returns the directory where the project file is located. From here I can often navigate using relative paths to the various places I need to go.

Any talk of MSBuild would not be complete without mentioning these extension libraries; SDC Tasks and MSBuildTasks. They provide a hosts of extras from re-writing XML files to creating web sites.

TFS

The build process (Team Build) is built upon MSBuild and, like all processes which are managed with MSBuild, it provides a set of extensions for querying the environment and managing the process. The first port of call is the MSDN page. After reading through this which is lengthy, I would recommend having a look at Martin Woodward’s post; useful Team Build properties.

Picasa 3 OS X and a shared image database

At home I use Macs and for viewing photos I use Picasa. It is the best tool I have found for the task as; it is happy to let you choose where to put the images and if I make corrections it doesn't change the originals.

Central library

One annoyance though is that each computer has it's own library locally, so when I add new pictures both libraries have to scan the watched folders.  So I spent an hour hacking around to see if I can move the local database to a share on my home server.

Symlinks

Picasa 3 keeps the image database in:


I found the path after looking in the Preferences -> Network page.  Now I moved in to a terminal window to;

• Create a PicasaDb on my home server
• Copy the local database to the folder on the share
• Rename my original database
• Create a symlink to the database now living on the server share

With all this in place I fired up Picasa and it still worked, first hurdle over.  I then edited an image and still no problems. I check the timestamps on the database files on the server and they had been updated plus, Picasa had not created a new database locally.

Next time I will attempt the same on the other computer to find out if Picasa will happily share a database.

Reset Remote Desktop Connections

Being able to connect to the desktop of another server is an essential part of most developers working day. Whether it is to configure IIS or to kick of a deployment, starting up the Remote Desktop Connection client is often the quickest way to complete the task.

Unfortunately the basic configuration only allows for three connections at any one time. Also, if someone just closes the client, their connection is not cleared. It will hang around in a disconnected state until someone connects to the physical machine to clear any unused connections.

There are two DOS commands which solve this problem. The oddly named; QWINSTA and RWINSTA.

qwinsta /server:SuperServer

The displayed list will include the session Id which you can use with the next command, rwinsta, to reset the sessions. Type the following to reset session 1 on SuperServer:

rwinsta 1 /server:SuperServer

Be sure to pick sessions with the state “Disc” as connections marked as “Active” my really be active.

Often the simplest tools yield the biggest gains. The discovery of these two commands has saved many hours of work. I no longer have to go through the IT support process and have an engineer go to the physical machine.