I have a few projects that are in progress built against 2004.1 and I dont really want to upgrade them yet and I need to use the with v2004.1 of the runtmes. I have new projects that are about to begin that give me the perfect opportunity to get used to 2004.2.

What would be the best approach for installing 2004.2 so that it doesnt conflict with 2004.1?

I was thinking of installing 2004.2 into a seperate directory and addining a registry key for 2004.2 so that the vs.net ide doesnt get confused about the location of the 2004.2 runtimes and also does not change my existing projects that reference 2004.1 runtimes.

Are there any other gotchas that I havent considered?

The installer will probably ask you to uninstall a previous version, but if you copy the existing 1.0.2004.1 folder, then uninstall it, then install 2004.2 and then you have 2 folders, and they should function fine. Indeed, the only thing you might consider is the registry key so vs.net knows where to locate the runtime libs, but that's all.

I created a "References" folder in my project tree where I manually copied the runtime libraries. Once the code is initially generated I point the LLBLGen/VS projects to reference the libraries in the "References" folder instead of using the GAC versions so that future compilations of the LLBLGen code point to the version of the runtimes I want. This allows me to swap out versions of the runtime libraries when/if necessary. For example, I went ahead and tested the LLBLGen betas on my production tree as all I needed to do was swap out the runtime libraries in the References folder.

If each project you're working on has its own "References" folder where the appropriate copy of the runtime libraries are stored, then you're good to go.

BTW, I do this with all of my xcopyable third party controls as well, such as Infragistics and Data Dynamics. Makes deployment niiiiiice.

Jeff...

jeffreygg wrote:

I created a "References" folder in my project tree where I manually copied the runtime libraries. Once the code is initially generated I point the LLBLGen/VS projects to reference the libraries in the "References" folder instead of using the GAC versions so that future compilations of the LLBLGen code point to the version of the runtimes I want. This allows me to swap out versions of the runtime libraries when/if necessary. For example, I went ahead and tested the LLBLGen betas on my production tree as all I needed to do was swap out the runtime libraries in the References folder.

That's a clever idea! I never thought of that myself. In my 17 project adapter unittest project I had to modify the project references to point to the new debug builds oh my what a pain... Your solution would have solved it instantly!

If each project you're working on has its own "References" folder where the appropriate copy of the runtime libraries are stored, then you're good to go.

BTW, I do this with all of my xcopyable third party controls as well, such as Infragistics and Data Dynamics. Makes deployment niiiiiice. Jeff...

You never had probs with infragistics and this way of referencing? or am I confusing it with copy local? When I set copy local to true, all infragistics controls break and don't function properly. (here, at least)

Otis wrote:

You never had probs with infragistics and this way of referencing? or am I confusing it with copy local? When I set copy local to true, all infragistics controls break and don't function properly. (here, at least)

Never had any problems, although I never changed copy local (goodnight, how I hate how MS handles references in VS. It's a disaster). All satellite assemblies (which are the ones directly referencing the Infragistics controls) have Copy Local = False, while the shell/bootstrapper assembly has the aggregate of all of the references the satellite assemblies contain, but with Copy Local = True. Works like a champ.

Jeff...

jeffreygg wrote:

Otis wrote:

You never had probs with infragistics and this way of referencing? or am I confusing it with copy local? When I set copy local to true, all infragistics controls break and don't function properly. (here, at least)

Never had any problems, although I never changed copy local (goodnight, how I hate how MS handles references in VS. It's a disaster). All satellite assemblies (which are the ones directly referencing the Infragistics controls) have Copy Local = False, while the shell/bootstrapper assembly has the aggregate of all of the references the satellite assemblies contain, but with Copy Local = True. Works like a champ.

aha

It's indeed a struggle. I once had to figure out all the assemblies referenced by the .exe so I could create a .zip file, but changing copy local to true made the controls go bezerk... really weird. .