Friday, August 24, 2007

Mix:UK 07

Not really .Net related, but I have to admit to excitement at the prospect of going to Mix:UK 07 down in London in September.

Interestingly, the social networking aspect is already hotting up, with a Backnetwork set up and a Facebook event starting to draw in the attendees. Will I go as far as to import those attendee contact lists into my PDA to take? Well, knowing my inability to remember and match names to faces, it'd probably be a good thing to do.

Technically, I'm really going to be interested in the Silverlight tracks - right now I'm almost desparate for the Silverlight team to implement the basic forms controls (buttons, text boxes, etc). Whilst better control support is planned, it does seem to be a very large omission from the 1.1Alpha release.

Of course, there have already been some community projects to rectify that deficiency, as well as commercial offerings, but how compatible would these be with Microsoft's own library, and how much effort would it be to back-migrate from a 3rd part library after the fact?

Anyway, roll on Mix and I'll see you in London!

Monday, June 11, 2007

Using a global ProductInfo.cs file

When a project gets beyond a certain size, it becomes impossible to keep the multitude of AssemblyInfo.cs files up do date, particularly for copyright and version numbers.

The solution to this problem is to use a single ProductInfo.cs file that every project links to, which contains the common data that would normally be duplicated across many AssemblyInfo.cs files.

Here are the contents of ProductInfo.cs

using System.Reflection;

using System.Runtime.CompilerServices;

using System.Runtime.InteropServices;

[assembly: AssemblyConfiguration("")]

[assembly: AssemblyCompany("My Company Limited")]

[assembly: AssemblyProduct("My Product")]

[assembly: AssemblyCopyright("Copyright © 2006-2007")]

[assembly: AssemblyTrademark("")]

[assembly: AssemblyCulture("")]

[assembly: AssemblyInformationalVersion("v1.0 alpha")]

// [assembly: AssemblyKeyFile("MyCodeKey.snk")]

 This allows the AssemblyInfo.cs file for any assembly to be pared down to the following:

using System;

using System.Reflection;

using System.Runtime.InteropServices;

[assembly: AssemblyTitle("MyCompany.MyProduct.MyAssembly")]

[assembly: AssemblyDescription("Description of MyAssembly")]

[assembly: ComVisible(false)]

[assembly: CLSCompliant(true)]

[assembly: Guid("b76c311c-f681-48d1-b2e0-9f691feb239f")]

[assembly: AssemblyVersion("")]

[assembly: AssemblyFileVersion("")]

There are 2 ways to add a link to the ProductInfo.cs to your projects:

1.Drag and drop (the easy option) 

This method simply entails dragging the linked ProductInfo.cs from an existing project and dropping it the Properties folder of your project.

2.Add Existing item (an alternative option)

This method includes add an existing item to your project, by right clicking on the project file and selecting Add -> Existing Item from the context menu. Then navigate to the directory containing the ProductInfo.cs file and select the ProductInfo.cs file. Finally (and  this is the clever bit) select the Add Link option from the dropdown attached to the Add button.

I tend to add a solution (virtual) folder called "Solution Items" to each large solution I'm working on and add the ProductInfo.cs file to that. I can then easily drag-and-drop as needed.

When this technique is coupled with automated Assembly versioning, your live becomes much easier!

Thursday, May 31, 2007

Numbers, numbers everywhere - fixing VS2005's Assembly Numbering Limitations

Assembly numbering isn't something that a developer will generally bother too much about - so long as your references are up to date and the code works, what does it matter if the AssemblyVersion or AssemblyFileVersion are permanently locked at Unfortunately, with the complex interaction of class-libraries in large projects, we need to be a bit more deliberate about things.

The two properties in question, AssemblyVersion and AssemblyFileVersion, are controlled through assembly attributes in the AssemblyInfo.cs file for a class library. You can find this in the Properties folder of a project.

When you create a new Class Library project, these properties will be set as shown in the following snippet from AssemblyInfo.cs.

// Version information for an assembly consists of the following four values:
// Major Version
// Minor Version
// Build Number
// Revision
// You can specify all the values or you can default the Revision and Build Numbers
// by using the '*' as shown below:

[assembly: AssemblyVersion("1.0.0.*")]
[assembly: AssemblyFileVersion("1.0.0.*")]

Visual studio lets you "default" the Build and Revision numbers using an asterisk (*) in the property. HOWEVER, it ONLY works for the AssemblyVersion property, NOT the AssemblyFileVersion property. This means that whilst your AssemblyVersion can automatically increment, the AssemblyFileVersion cannot.

Fortunately, there's a workaround from Microsoft - an additional MSBuild task that can be added to a project file which causes the two properties to be updated on every build.

Of course there's a downside - setting this up for every project involves adding a line to the .csproj file directly. What follows is a walkthrough of the process.
  1. Install the AssemblyInfo task downloaded from the MSBuild Tasks website.
  2. Create a customised build target file according to the instructions.

    I created a copy in the installation directory, but you can put it wherever you want - just be sure to update the path in step 3 below.

    My customisation was configure the task so that the AssemblyFileVersion had fixed Major and Minor versions, but the Build number represented the day and month the build took place and the Revision number again autoincremented.

    The critical code from the targets file is this:


    You can, of course, configure the task to modify the AssemblyVersion in the same way.
  3. Add the following additional target import to each project file (*.csproj) just after the default Microsoft.CSharp.targets import.

    <Import Project="$(MSBuildExtensionsPath)\Microsoft\AssemblyInfoTask\Custom.VersionNumber.Targets"/>

    This is the magic that instructs the compiler to run the AssemblyVersion task each time the project is build.
It's a small chore to update each project, but the result is a much more useful format for the two properties.

[assembly: AssemblyVersion("")]
[assembly: AssemblyFileVersion("1.0.000214.02")]

The AssemblyVersion build number auto-increments, and the FileVersion includes the build date where before it was just a static value.

There's one slight wrinkle with this method of your project is under source control, however. The AssemblyVersion task it relies on being able to write changes into the AssemblyInfo.cs files just prior to compilation - so if your source control package write-protects files until you check them out, the process will error.

For TFS users, this post on the MSBuild Team Blog gives additional build targets to add to your project file that will check-out the relevant files, and then check them back in again afterwards. It's targetted at automated builds, but is easy enough to modify.

But the simplest method is simple to ensure that AssemblyInfo.cs is checked out before you build by using a pre-build script in each project. The following script works perfectly for TFS-controlled projects (note the quotes, tho', and the use of a relative path for the AssemblyInfo.cs file).
"$(DevEnvDir)\tf.exe" checkout ..\..\Properties\AssemblyInfo.cs

Of course, this won't check in the changed files, but that's sometimes a benefit!

The AssemblyVersion MSBuild Task allows fine-grained control of assembly and file version numbers - when this method is linked with that of a ProductInfo.cs solution file (on which I'll blog later), you gain real control over the meta-data embedded into your products.

Friday, January 05, 2007

Wierd compilation error - corrupt lines in FileList.txt

I came across a very strange error last night that flumoxed my for a while.

Compiling a solution, three of the sub projects failed to compile with the following cryptic error:
Files had invalid value "S....."
It turns out that the cause and solution are both quite simple, but neither is obvious.

Firstly, what does "Files" mean in this context?

Well, when VS2005 compiles a project, it reads a file in the obj directory named .csproj.FileList.txt, creating it first if required. This file contains a list of the DLLs and PDBs that will be generated, as well as one named ResolveAssemblyReference.cache, which (I assume) is passed to the command-line compiler used to actually perform the compilation.

As for the "invalid value", this turned out to be a corrupt line in the file, nothing more, so the solution is just to delete the obj\.csproj.FileList.txt file completely, clean the project and rebuild. Job done.

Strangely the only reference I could find to the FileList.txt file was in this posting by Sayed Ibrahim Hashimi, confirming that this is one of those undocumented "features" of VS2005.