Do you have an msi install of the assembly that puts it in the GAC? Also, I do not see a policy file to handle redirect of assembly lookups or side by side execution by CLR. Does this exist? If not, I might be able to provide an msi and policy via some tools we have created.

No, we don't have an MSI installer. Can you also please explain the policy thing a bit?

A policy file tells the CLR where requests for a version of an assembly should be directed. If you don't have a policy assemblies with a strong name will only be found if the versions match. So if you deployed a 1.1.0.0 version and had assembly references to that version and then later deployed a 1.1.1.0 version, the application that was bound to the old version would fail if you removed the 1.1.0.0 version without having a policy file. This is also the mechanism that allows two different assemblies to reliably run side by side on the same machine. For GAC based assemblies, the policy is actually created as an assembly that also gets registered in the GAC. Without policies, you can get into wierd situations once you start deploying new or multiple versions of an assembly. The cool thing is you can define both backward and even forward references. So for example, you might want to forward reference all bug fix (say the fourth position) to the latest version but only support backwards references to feature releases (say the third position).

AFAICS, it would be hard to define such policy because most release of NHibernate introduces breaking changes (they are minors, but they are).

So I think that it is better to let the user test the new version and do changes if required (or apply its own policy).

The problem is that clients do not have the private key to define a policy which must be packaged as an assembly to be put into the GAC. Hence, (this what I am doing currently) the client must create the NHibernate dll and sign with their private key to create an assembly that can be put in the GAC and have a policy file. Of course the alternative is to not put in the GAC, but then each application will have its own instance of the NHibernate assembly. In terms of breaking changes, I would hope that your versioning is aligned with most product versioning in that feature and bug enhancements are always backward compatible but major changes are not. You will have a lot of unhappy people if you break code for a bug fix of new feature (at least my clients are this way).

I'm keeping 1.0.1 source-compatible with 1.0, so I'm mostly only adding things (or not changing anything of course), like adding methods to a class (not interface), adding classes, etc. But I'm not sure if 1.0.1 will be binary compatible with 1.0. Specifically I'm not sure about adding methods - will the policy/redirection mechanism cope with it? What if just the order of some methods of an interface has changed?

I could actually put the .snk in CVS, but several other members of the team objected to this, so I'm not doing it for now.

The policy will handle redirecting to the current assembly. For web apps, we typically have as part of the deploy process to touch the machine config such that all app domains will reload their shadow copy of the assembly and pick up the new version for any new request. In terms of adding classes or methods to an existing class, this is a compatible change (won't break an existing client) unless you are doing something that breaks the semantics/behavior of the class that could cause a client to break due to an unanticipated change in functionality. For example, one thing we look at where binary was compatible but broke usage was change in serialization (esp. xml) or format specfications for parsing oriented operations. Another example, would be addition of a new thrown exception in a method that a client has defined try/catch actions around and now do not cover the new exception and hence could result in unanticipated reaction.

Sorry if this question is lame or my terminology is incorrect, but I'm not familiar with signing assemblies ...

For unit testing on an isolated machine, I want "DLL hell" to occur -- I want to be able to drop in a hacked NHibernate.dll in one place and test it in mulitple applications without recompiling them.

How do I do this? I tried commenting out the AssemblyKeyAttribute in NHibernate's AssemblyInfo.cs, but then of course nothing already compiled against a signed NHibernate assembly will recognize it. NHibernate Contrib stuff balks at runtime that it can't find the assembly with the specific version and public key token that it was compiled against.

In any case, what is the standard/required procedure to make modifications to NHibernate, and get everything else to use it?