We have just licenced v4 of LLB and want to work out our migration path from v3.1.

First, I want to add the new dlls to the websites that use LLB. I am hoping that the existing dlls will work without recompiling as long as I add a bindingRedirect for each SD dll. Is that true? I don't mind compiling the odd one or two solutions that break, but hopefully the 0+ solutions will work.

What is the config element I need? Something like this?

<dependentAssembly>
        <assemblyIdentity name="SD.LLBLGen.Pro.ORMSupportClasses." publicKeyToken="**********"" />

        <bindingRedirect oldVersion="3.1.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>

Presumably I will need one of the above for each dll.

I notice some name changes of dlls from 3.1 to 4.0 though. Can the bindingRedirect handle these too?

Once the websites are working, we can then compile the code at our leisure with the 4.0 dlls.

Does the above make sense or do I need to recompile everything first then republish all the dlls for the websites?

this won't work, you have to regenerate the code and update the references in the vs.net projects, then recompile. We merged 3 assemblies into one (linq, queryspec and ormsupportclasses are now all in ormsupportclasses) and the name of the ormsupportclasses dll changed (no .NET20 suffix anymore).

I'm not sure why you'd want to use a bindingredirect and not re-generate the code and recompile?

Create a branch of your code, generate the v4.0 code onto that, compile, fix the issues you run into, merge back.

Otis wrote:

this won't work, you have to regenerate the code and update the references in the vs.net projects, then recompile. We merged 3 assemblies into one (linq, queryspec and ormsupportclasses are now all in ormsupportclasses) and the name of the ormsupportclasses dll changed (no .NET20 suffix anymore).

OK.

Otis wrote:

I'm not sure why you'd want to use a bindingredirect and not re-generate the code and recompile?

Well, we use a component approach where each distinct piece of functionality in our 2 websites is a stand alone module. We have over 80 solutions for these 2 websites. Then along with the 20 or so other solutions that use LLBLGen that means we need recompile > 100 VStudio solutions.

Also, this approach worked for v2.7 to v3.1 and bought us some time to recompile.

Otis wrote:

Create a branch of your code, generate the v4.0 code onto that, compile, fix the issues you run into, merge back.

Yes indeed. 100 times:-) Although I can probably script a lot of it.

If a few work OK without changes, then I might let TeamCity do the builds and deploy the artifacts to staging.

Thanks again for your response.

UPDATE: The migration went better than expected. No issues came up that needed fixing apart from renaming references. Thanks for doing a great job with compatibility!