I've noticed a trend with 3rd party vendors to append some form of NET20 to the end of their assemblies now that .Net 2.0 has come out, our favorite product included. I'm using .Net 2.0 and I'm using LLBLGen, BUT when I first wrote my "MyCompanyCommonFramework" assembly, I used SD.LLBLGen.Pro.ORMSupportClasses.NET20, I was using LLBLGen 1.2005.x and compiled my assembly with that reference. I've since gone to the beta and in this same assembly now, I want to use SD.LLBLGen.Pro.ORMSupportClasses.NET20 (v2), but it blows up when I try to compile because I've used EntityCollectionBase2 as a parameter type in some of my methods and as the return type.

If I rename my assembly and follow suit and append NET20 to it, it still doesn't really indicate what I want because I would need NET20.LLBLGenV1 and NET20.LLBLGenV2 appended to the end seeing as prior apps use the v1 of LLBLGen.

Can I use the version number in my assembly to help me out somehow?

Obviously using the vendor version as part of my assembly name is not only ugly, but dumb as well. Any other ideas would be greatly appreciated.

NickD wrote:

Any other ideas would be greatly appreciated.

I'm not sure I follow. Is it blowing up because EntityCollectionBase2 doesn't exist in the new version of the ORMSupport classes, or because your compile is pointing to the wrong ORMSupportClasses?

BOb

It wants there to be a <type> for that collection. But, that really isn't the point, because ultimately, there are going to be differences between versions of vendor assemblies. So, my real question is what does using a version number in my own assembly do for me? Does it allow me to use different 3rd party assemblies inside of a different version of my own assembly?

Hopefully this makes sense. At least a little bit...