.Net Assembly Vs. File Versions

Thursday, 26 June 2008 00:11 by RanjanBanerji

In my opinion a commonly misunderstood feature in .Net is the concept of Assembly vs File Versions.  While .Net tried to resolve the issue of DLL hell by providing the concept of Assembly and File Versions I do not believe many people use them correctly.  In this post I am going to present my way of interpreting the differences and how I use File versions and Assembly versions.

Think, Don't Read

Now I am asking for trouble.  But here is my issue.  I often come across developers who make decisions based on what they read and not based on careful thought and analysis.  I hate when someone says let's do this because its a Microsoft Best Practice.  Why is it a Best Practice I ask?  Does it apply to your situation?  The reply I often get is "but its a Microsoft Best Practice."  Recently I interviewed about 10 people for a Java developer position.  I asked each candidate to tell me what "Spring" is and why should it be used.  The answers I got included:

  • Everyone uses Spring
  • Spring is a must for Java projects
  • Spring is now almost a standard
  • You cannot build a Java application without spring.

and many others.  But no one, not even one, told me what Spring was and why it was a good idea to use it.  And therein lies the problem.  A lot of us go by buzzwords, blogs, books etc and not by what we know by virtue of careful thought and analysis of the situation.  Hmmmmm! said the right way and I could sound like Yoda.  If only I were that cool.

File Vs Assembly Versions

Anyway, back to File Versions and Assembly versions. In this post I intend to talk about when to use or create a File Version vs an Assembly version.

File Version

File Version is a way to version your files (DLL) for any purpose you want.  Neither Windows nor the .Net Framework cares about this version.  So when you create this version and increment it you are the sole consumer of the information held in it.

Assembly Version

This is a way to version assemblies in .Net.  However, unlike File versions the assembly version is used by the .Net runtime and various .Net applications.   Applications use assembly version information to determine which DLL to bind to.  So if you have an application that binds to Assembly version 1.0.0.0 and then you drop Assembly version 2.0.0.0 without any change to the client application, the client application will continue to load version 1.0.0.0.  So even though DLLs are Dynamic Linked Libraries, in .Net the dynamic linking put in a simplified manner is to a specific version.

 

The Difference

An assembly with 2 File versions, say 1.0.0.0 and 2.0.0.0 are the same as far as the .Net Framework is concerned and as far as any application that uses the assembly is concerned.  However, an assembly with two assembly versions say 1.0.0.0 and 2.0.0.0 are treated as two different assemblies or versions of the same one.  If both assemblies exist in the GAC and yes both can your application will have to choose which one to use.   With File Versions only one can exist in the GAC.  One can get into many more technical differences between assembly and file versions but for this post this shall suffice.

Time To Think

Given this basic difference we can now think about (keyword being think) when to use assembly versions and when to use File versions.  When you rebuild an assembly you have to ask the question why?

  1. Is it a nightly build during development?  You really don't have to care much about this.  A File Version increment at a minor level may suffice.
  2. Is it a build for a new version?   If so:
    1. Does the new release change or add a new interface?  Yes?  Increment assembly version.  Why?  A changed interface implies that no one using this assembly in the past can use it as it used to use the previous version.  So effectively you have created a new assembly.  In order to prevent any confusion between the new assembly with its different interfaces you should create a new assembly version so that old applications continue to use the old assembly version and new ones can use the new assembly without any ambiguity.
    2. Does the new release provide a change such that you need to have the previous version still available for use to those who wish to use it?  Yes?  Create an Assembly version.  This way you can retain both copies of your assembly.
  3. Is the new release a bug fix with no interface change?  Do a File version change.  Changing the assembly version does not help you in this case.  In fact it will be detrimental as you will have to tell all consumers of your assembly to bind to the new version.

The worst reason and a very common reason (unfortunately) for assembly versions is to maintain some form of tracking of your DLLs.  Assembly version is not meant for this.  Use File Version for such tracking.  If you use Assembly version changes for each build where there is no interface change or no real need for a new version you may end up asking for too much trouble for you may end up having to update all your client applications to bind to the new DLL.

So think carefully before make the decision to change the Assembly Version.

Oh! and by the way, reading is a good habbit :-)

Categories:   .Net
Actions:   E-mail | Permalink | Comments (11) | Comment RSSRSS comment feed

SharePoint 2007 - Changing Content Without Creating a New Version

Tuesday, 10 June 2008 23:37 by RanjanBanerji

SharePoint offers a neat feature that creates a version of any content the moment you edit it.  This way you maintain a history of all changes, you know who changed information and of course you can revert back to a prior version.  Clearly a great feature.  But what happens if you want to make a certain change without creating a version.  No, I am not talking about turning version feature off.  What if I want to keep versions but not for this one change.

Let me explain. 

  • Imagine a document library or an image library with large numbers (1000s) of large (file size) documents/images. 
  • Imagine that these files (documents/images) add up to 10 GB. 
  • In addition to the files these libraries store properties associated with the file.  Let's suppose one of the property is the state in which the document was created and was represented by the 2 letter symbol of the state (yep, I am talking about states in the US). 
  • Now suppose the customer comes to you and says "I don't want 2 letter state codes, I want the full state name listed"

 

So what are you going to do?  You can assign the task to some poor person to make the data changes (Apparently a path chosen by many SharePoint experts) or you can write some code to do so.  Either way you are going to encounter one large problem.  You are about to experience a huge increase in the size of your database.  Based on my example the increase will be 10 GB.  You see as you make this trivial edit SharePoint will make a new version of not just this edit but of the entire object which will include the entire file (image or document) in question.  So if you had files adding up to 10 GB you will now have 20 GB worth of files.  But is this specific change worth creating a version for?

Also, if you attempt to make this change to all such files as mentioned in my example, irrespective of the approach you took you can make changes only to items that are not checked out to others.

So you have two problems:

  • Database bloat
  • Inability to complete the task due to certain items checked out by others

 

Now if you took the path to update each item via writing code you probably did it as follows (pseudo code included):

public void UpdateItem() { 
        SPListItem listItem = web.GetListItem( fileNameAndPath ); //web is an SPWeb 
        //Get the file
        SPFile file = null;
        file = listItem.File;
        file.CheckOut();

        listItem[ "STATE" ] = stateLookup[ listItem[ "STATE" ] ];

        listItem.Update();

        file.CheckIn( "Metadata Update" );
        file.Publish( "Metadata Update" );
        file.Approve( "Metadata Update" );

}

 

But this approach will create a version and will therefore result in database bloat.  An alternative approach would be to use the system update feature as follows:

public void UpdateItem() {
    SPListItem listItem = web.GetListItem( imageNameAndPath ); //web is an SPWeb
    listItem[ "STATE" ] = stateLookup[ listItem[ "STATE" ] ];  //Lookup the full state name based on the two letter code and assign it to the property
    listItem.SystemUpdate( true );
}

Now with this approach you have the following advantages:

  • No need to check out.
  • It does not matter if the item is checked out by another user.
  • No version is created so no database bloat.

I must add that this approach must be used with extreme caution.  It is not a good practice to change items that others have checked out and if someone has versioning turned on on a list there is probably a reason for it.  Having said that now you know you have a way to get around certain problems if needed.

 

Tags:  
Categories:   SharePoint
Actions:   E-mail | Permalink | Comments (4) | Comment RSSRSS comment feed