I've been having a hell of a time with the last few releases of LLBLGen. Normally, after I upgrade, I stick the runtime libs in the gac, reference the new libs, regen the code, do a build and everything works. However, after upgrading about a week ago (for about the first time since early June), this method produces the following error:

Server Error in '/' Application.
Method not found: Boolean SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.SetNewFieldValue(Int32, System.Object, Boolean).
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.MissingMethodException: Method not found: Boolean SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.SetNewFieldValue(Int32, System.Object, Boolean).

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[MissingMethodException: Method not found: Boolean SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.SetNewFieldValue(Int32, System.Object, Boolean).]
   Mozaic.Portal.BusinessEntities.EntityClasses.PortalsEntity.SetNewFieldValue(Int32 fieldIndex, Object value) +0
   Mozaic.Portal.BusinessEntities.EntityClasses.PortalsEntity.set_ID(Int32 value) +31
   Mozaic.Portal.BusinessEntities.EntityClasses.PortalsEntity..ctor(Int32 iD) +87
   Mozaic.Portal.BusinessServices.PortalManager.Fetch(Int32 portalID) +50
   Mozaic.Portal.BusinessServices.PortalManager.get_CurrentPortal() +113
   Mozaic.Portal.Web.Index.Page_Init(Object sender, EventArgs e) +113
   System.Web.UI.Control.OnInit(EventArgs e) +67
   System.Web.UI.Control.InitRecursive(Control namingContainer) +241
   System.Web.UI.Page.ProcessRequestMain() +197


Version Information: Microsoft .NET Framework Version:1.1.4322.2032; ASP.NET Version:1.1.4322.2032

This happens for all web applications built against the newer releases and on all machines I've tried it on, including my Windows XP development box, another programmers XP box, our Windows 2000 staging server, and our Windows 2000 intranet server.

I did manage to get the assemblies installed in the gac on my local machine after removing all previous llblgen libs from the gac and only installing the latest, however this does not work on all of our servers and I get the error above if the runtime libs are in the gac. I then have to have copies of the lib in the bin directory for my app to run, which causes other problems.

I would love to avoid the gac altogether, but unfortunatly asp.net throws cryptic compiler errors if you reference a strong named assemblies in the gac (see here among others http://support.microsoft.com/default.aspx?scid=kb;en-us;813833). I could also compile my own versions from your source but that can get really tedious, especially when you put out several releases in a week (especially since I would have to re-distribute those custom assemblies to the other developers here each time).

I've performed this same upgrade dozens of times over the last year and a half (basically since LLBLGen Pro was release) and this is the first time I've ever had this problem and now I'm completely stuck. Help!

You're using an older runtime lib in your app at the moment, one which doesn't have the method required: protected bool SetNewFieldValue(int fieldIndex, object value, bool fireChangeEvent)

Each ORMSupportclasses dll has a fileversion. In june I made a mistake, where I set the date in the fileversion to the wrong value (this has to be done manually, sadly enough): mmddyy, instead of yymmdd.

This resulted in a higher value, which then makes the GAC think that a newer version is actually OLDER.

To make sure you use the latest version, you can right-click on the dll, click properties and then the version tab. It should have NOW something like 1.0.20042.062705

I'll now upload versions which are actually correct: 1.0.20042.050708.

As always: first close VS.NET (all instances) then stop w3svc/iisadmin, then remove the assemblies from the gac, then re-install the assemblies into the gac, then restart w3svc and it should work. Do NOT rely on the GAC to handle the version management of the assemblies you want to use: ALWAYS remove the previous versions first, then add new ones.

The GAC is not recommended, but in your case, sometimes you can't avoid it.

Yeah, I'm not a big fan of the GAC, and I can't see how obscure compiler messages is "by design". It's a really lame design if you ask me.

However, I will grab the new version and make sure I clear everything out as you reccomend. I'll let you know how it goes, thanks!

Things seem to be working again. Thanks Frans!

Because of multiple versions of applications which use multiple versions of LLBLGen, do you have a recommendation of how to handle differing versions? Here's the scenario I have inherited:

There is one main version of the application for all clients which runs on the latest LLBLGen libraries. However, there's several custom applications which were written in the past which rely on an older version of the core libraries. Is there a way to run both versions (with or without the GAC)?

Thanks!

This MSDN article might be useful to you - MSDN link

It says ....

As a general guideline, keep assembly dependencies private and locate assemblies in the application directory unless sharing an assembly is explicitly required

I personally have a directory on my local machine where I keep all my application dependent dll's. For llbl, the dlls are ormsupportclasses and database run time libraries. The 'copy local' is set to 'yes' by default.

If I need to ship an older version of my application, I simply place the old version of the dll in this directory and package. Bit laborious, but works

Since starting this thread we've started compiling our own dll's from the source Frans provides, removing the strong naming stuff. This lets us deploy as many versions of the libs to any server we want without screwing up any other application.

It's a bit more work when installing a new version, but less work overall since I don't have to mess with the gac on 4 different machines.

AZWolf7 wrote:

Because of multiple versions of applications which use multiple versions of LLBLGen, do you have a recommendation of how to handle differing versions? Here's the scenario I have inherited:

There is one main version of the application for all clients which runs on the latest LLBLGen libraries. However, there's several custom applications which were written in the past which rely on an older version of the core libraries. Is there a way to run both versions (with or without the GAC)?

Thanks!

Yes, you can have multiple versions of the assembly in the GAC and the application will use the one it was compiled against, unless a policy or config item tells it defferently.

Without the GAC you would just put the version of the DLL built againts in the apps private bin folder.

BOb