Thought I'd christen my newly repaired blog (crossing fingers) with a new post about Service Pack 1 for the .NET Framework 1.1 - which has been available for over a month now (yes, I have been busy):

SP1 - http://www.microsoft.com/downloads/details.aspx?familyid=A8F5654F-088E-40B2-BBDB-A83353618B38&displaylang=en

Yesterday I finally had a chance to update my machines and take a closer look. Ironically, on the same day I had a fantastic conversation with Vivek Nirkhe from the VS 2005 Team System group ( http://lab.msdn.microsoft.com/vs2005/teamsystem/ ) on the issues of versioning; updating assembly version versus file version; and best practices for build process to handle distribution during development, the pass to QA and final release. He was kind enough to provide feedback on some of my concerns about SP1.

Much to my surprise, SP1 doesn't version the updated .NET Framework assemblies, which happen to contain a long list of fixes. My immediate thought was:

Why aren't they versioning their assemblies and shipping a publisher policy?

A publisher policy makes it possible for you to deploy updated assemblies to the GAC, and all installed applications will automatically bind to those updated assemblies. UNLESS, they override policy in their own app.config file. Therein lies the problem, according to the following blog post by Junfeng Zhang on the subject: 

http://blogs.msdn.com/junfeng/archive/2004/10/11/240822.aspx

In summary he states:

1. The service pack is security related, and we don't want customers to opt-out by publisher policy override
2. The main reason for the concern in #1 is because through publisher policy override you must specify which assembly to override. Since SP1 includes multiple files, it is possible that applications will forget to include ALL of the assemblies in the override, and thus create a situation where some assemblies are 1.1, others SP1.

Ok, so this is a good call, because we all know this would happen and create a support nightmare. But, this exposes an inherent limitation to assembly versioning in .NET 1.1, which I have spoken about in some of my talks on the subject.

Assembly redirection, publisher policy overrides, and related assembly binding concepts can be configured in XML, through the local app.config or web.config for particular applications and subdirectories. But, you have to specify individual assemblies one-by-one even if you are configuring a single policy that should apply to multiple assemblies. If you miss one, time to trouble-shoot. But, if all SP1 files all carry the same version number, and no other group of updates carry that number, then shouldn't it be possible to specify a publisher policy override in one fell swoop, by identifying the version number the override applies to? 

My wish list on this subject:

1. Make it possible to deploy a publisher policy-like DLL to my local app.config, that supplies a binding policy that could group a number of assemblies and policies in a single DLL. Easier than an open XML config file that can be edited, and less error prone because it can be tested and deployed to clients.
2. With this, SP1 could have updated version, shipped a publisher policy, and provided a publisher policy override in assembly format for anyone to override just in their application. They might need to do this, if for example they need some time to update fixed to their application for the service pack. I know, it is supposed to be backward compatible, however sometimes clients depend even on bugs in previous versions, for their code to work...strange and lame, but true.
3. With this, deployment of fixes to local applications not installed in the GAC could include policy DLLs instead of hand-rolled updates to the local app.config/web.config. What if the customer has edited those config files? That means our installations have to edit the config, not ship a new one. This is painful. Let me ship a DLL that specifies a policy.

We don't have these options today, readily available, so they made the right choice for SP1 and vendors will have to make sure their apps function against it. And, there are plans to improve the versioning and deployment of framework vs. application assemblies in the future. Find out more in this insightful article by Cathi Gero and Jeffrey Ritcher:

http://www.theserverside.net/articles/showarticle.tss?id=AssemblyVersioning

So, the dogfood is just ok, and that's why with SP1, MSFT opted out of eating it. For single-assembly updates, it tastes a little bit better.