Since downloading the latest version of LLBL (July 25th) (dlls dated August 1st) I get an error on application start:

 Method not found: Void SD.LLBLGen.Pro.ORMSupportClasses.IFieldPersistenceInfo.set_IdentityValueSequenceName(System.String). 

Line 229:           Dim persistenceInfo As IFieldPersistenceInfo = PersistenceInfoFactory.GetFieldPersistenceInfo(field.ContainingObjectName, field.Name)
Line 230:           InsertPersistenceInfoObjects(field.ExpressionToApply)
Line 231:           HandleSchemaName(persistenceInfo)
Line 232:           Return persistenceInfo
Line 233:       End Function

[MissingMethodException: Method not found: Void SD.LLBLGen.Pro.ORMSupportClasses.IFieldPersistenceInfo.set_IdentityValueSequenceName(System.String).]
   ADPDS.IP.DAL.DatabaseSpecific.DataAccessAdapter.HandleSchemaName(IFieldPersistenceInfo persistenceInfo) +0
   ADPDS.IP.DAL.DatabaseSpecific.DataAccessAdapter.GetFieldPersistenceInfo(IEntityField2 field) in C:\Documents and Settings\sbeets\My Documents\Visual Studio Projects\ImplementationPortal\ADPDS.IP.DAL\DatabaseSpecific\DataAccessAdapter.vb:231
   SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.CreatePrimaryKeyFilter(ArrayList primaryKeyFields) +172
   SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.FetchEntity(IEntity2 entityToFetch, IPrefetchPath2 prefetchPath, Context contextToUse) +307
   SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.FetchEntity(IEntity2 entityToFetch, IPrefetchPath2 prefetchPath) +41
   ADPDS.IP.DAL.BaseClasses.PortalUser..ctor(WindowsIdentity nIdentity) in C:\Documents and Settings\sbeets\My Documents\Visual Studio Projects\ImplementationPortal\ADPDS.IP.DAL\NonDataClasses\PortalUser.vb:57
   ADPDS.IP.GUI.Global.WindowsAuthentication_OnAuthenticate(Object sender, WindowsAuthenticationEventArgs e) in C:\Inetpub\wwwroot\ADPDS.IP.GUI\Global.asax.vb:71
   System.Web.Security.WindowsAuthenticationModule.OnAuthenticate(WindowsAuthenticationEventArgs e) +24
   System.Web.Security.WindowsAuthenticationModule.OnEnter(Object source, EventArgs eventArgs) +471
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute() +60
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +87

I can't work out whether I've screwed up my upgrade or what. I've trying deleting and reregistering the runtime files in the GAC; I've verified that no old versions of the runtime files exist on my machine; and I've uninstalled and reinstalled (and re-gened) LLBL. What am I missing?

First of all, if possible, avoid having the ORMSupportClasses dll in the GAC. It's not necessary. If the code generated compiles, your project works with the latest version, as the setter is missing in older versions so if your project in vs.net was compiled against an older version, it would not compile.

Your webapplication itself, the bin folder, does that folder contain the lastest runtime lib dll as well?

Otis wrote:

First of all, if possible, avoid having the ORMSupportClasses dll in the GAC. It's not necessary.

I was having some problem (I've forgotten exactly what) to do with strongly named dlls that required me to put the runtime libs in the GAC.

Otis wrote:

If the code generated compiles, your project works with the latest version, as the setter is missing in older versions so if your project in vs.net was compiled against an older version, it would not compile.

My code compiles without a problem; the error is at runtime only.

Otis wrote:

Your webapplication itself, the bin folder, does that folder contain the lastest runtime lib dll as well?

The bin directories also contain the runtime dlls and these are the latest also.

ChicagoKiwi wrote:

I was having some problem (I've forgotten exactly what) to do with strongly named dlls that required me to put the runtime libs in the GAC.

I think this (http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=2790) is the post I saw which prompted me to put the runtime files in the GAC.

ChicagoKiwi wrote:

Otis wrote:

First of all, if possible, avoid having the ORMSupportClasses dll in the GAC. It's not necessary.

I was having some problem (I've forgotten exactly what) to do with strongly named dlls that required me to put the runtime libs in the GAC.

Otis wrote:

If the code generated compiles, your project works with the latest version, as the setter is missing in older versions so if your project in vs.net was compiled against an older version, it would not compile.

My code compiles without a problem; the error is at runtime only.

Otis wrote:

Your webapplication itself, the bin folder, does that folder contain the lastest runtime lib dll as well?

The bin directories also contain the runtime dlls and these are the latest also.

If the runtimes are in the gac, the bin folder doesn't need htem, as the version in the gac is loaded.

For testing, could you please remove ALL runtime libs from the gac and solely place them in the bin folder and go from there? At runtime a version is loaded without the method, which causes the error.

The issue was versioning. After explicitly deleting and re-adding the runtime files from the GAC and restarting IIS the problem seems to be fixed.

ChicagoKiwi wrote:

The issue was versioning. After explicitly deleting and re-adding the runtime files from the GAC and restarting IIS the problem seems to be fixed.

Especially restarting IIS (or teh asp_net workerprocess) can help indeed, as it otherwise doesn't necessarily re-load the assemblies. (don't get me started on asp.net and signed assemblies... )