One of the problems with dumping Iesi.Collections is that the BCL (even 4.0) have no non-generic ISet.
To facilitate the eventual switch to .Net 4 I have pushed a number of commits to master which reduce use of the non-generic set collections. This still targets .Net 3.5 and I think it's unintrusive enough to be acceptable even in a 3.4 (if we do such a release). Most commits shouldn't be controversial (replacing private occurrences of ISet with ISet<>), but there are some public interfaces that change, detailed below. These two seemed fairly straightforward so they are already pushed to master, but please speak up if you think this was a bad idea: QueryKey.cs and related: Use strongly typed ISet<FilterKey> to prepare for a world without ISet. https://github.com/nhibernate/nhibernate-core/commit/78f76cec860a4352a73526c7737d67934faa3c33 Use strongly typed ISet<EntityKey> for IPersistenceContext.NullifiableEntityKeys. This match all current use inside the NH code base. https://github.com/nhibernate/nhibernate-core/commit/f2cb250898ddf2bd1abd8290b6c158f0cc4b7e91 ISet is also used in the IDeleteEventListener interface and related code, to track the set of entities which have already been visited. I propose to change the interface to use ISet<object> instead. I have a patch prepared for this, which is not merged yet: IDeleteEventListener, IEventSource: Use generic ISet<> instead of non-generic in method signatures. IdentitySet: Make it inherit Set<object> instead of Set, since the latter has no counterpart in SCG. https://github.com/oskarb/nhibernate-core/commit/f06d4f1c0bc12a94bd60cfd5e66fc013e1b7ef28#diff-8 Any comment on this breaking change? After the above three patches, NHibernate itself no longer relies on non-generic sets. The only remaining use in NHibernate core are in the 5 classes that support their use in mapped classes. It seems to me that as a last resort one can always use an ISet<object> instead of ISet. Given that, is there any valid reason to keep support for ISet in mapped classes? Apart from backwars compatibility of course. Removing that support would surely not be acceptable in 3.4, but only in 4.0. /Oskar
