What must I update in this LLBLGen-reliant code?

Question

I updated some broken references in a solution (new computer, reintroducing a large solution to its 3rd party components and to TFS).

I'm down from a starting point of 11,257 errors to only a few dozen. The first one that isn't fixable by pointing to the new location of 3rd party DLLs is:

The best overloaded method match for 'SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.PostProcessNewDynamicQueryEngine (SD.LLBLGen.Pro.ORMSupportClasses.DynamicQueryEngineBase)' has some invalid arguments

The code it's complaining about (which compiled before, obviously) is in DataAccessAdapter.cs:

/// <summary>Creates a new Dynamic Query engine object and passes in the defined catalog/schema overwrite 

hashtables.</summary>
protected override DynamicQueryEngineBase CreateDynamicQueryEngine()
{
    return this.PostProcessNewDynamicQueryEngine(new DynamicQueryEngine());
}

This is generated code; here is the unit header for the file (DataAccessAdapter.cs):

///////////////////////////////////////////////////////////////
// This is generated code. 
//////////////////////////////////////////////////////////////
// Code is generated using LLBLGen Pro version: 3.5
// Code is generated on: Tuesday, April 17, 2012 8:37:28 AM
// Code is generated using templates: SD.TemplateBindings.SharedTemplates.NET20
// Templates vendor: Solutions Design.
// Templates version: 
//////////////////////////////////////////////////////////////

The DLLs the project is referencing (SD.LLBLGen.Pro.DQE.Access.NET20 and SD.LLBLGen.Pro.ORMSupportClasses) are Runtime Version v2.0.50727, Version 3.5.0.0

I see that the file was generated over a year ago - do I need to regen this file? If so, how? Is it not getting regenerated because the solution is not at present compiling? If that's the case, it could be a "Catch-22"...

Answer 1

I see that I needed to re-route the path for the assembly reference/DLL. I have two versions installed (3.5 and 4.0), and it was still pointing to 3.5