Hi,

When I generate adapter VS.NET 2003 projects references are created for some SD.LLBLGen.Pro.* dlls, pointing to the local LLBLGen install dir. IE:

C:\Program Files\Solutions Design\LLBLGen Pro Demo\RuntimeLibraries\DotNet11\SD.LLBLGen.Pro.DQE.SqlServer.NET11.dll

Is there a way to tell the generator to reference those dll's if I locate them elsewhere? IE, if I have this path on my machine, and copies of the dll's there:

c:\data\code\SomeProject\Trunk\bin\

Otherwise I have to change the references manually after generating.

Thx, Jack

The path written to the project files is read from the registry: HKLM.Software\Microsoft.NETFramework\AssemblyFolders\LLBLGenPro.RuntimeLibraries.Net10 and HKLM.Software\Microsoft.NETFramework\AssemblyFolders\LLBLGenPro.RuntimeLibraries.Net11

These paths are also used by vs.net when you click 'add reference'.

So if you want to use another folder by default, you have to change that registry key's value and you're set. (with new project files, current ones are updated, not overwritten)

Hi,

Here's the problem I'm having... maybe there's a workaround....

I'm in charge of generating the LLBLGen adapter projects for our company.

Other developers use the generated projects (by grabbing a copy from source control management).

Each developer may map the SCM dir (where we have a copy of the LLBLGen dll's) to different local dirs.

So, if I change the registry to something like:

C:\data\code\Common\Trunk\bin

then that's what the references in the generated projects use. Problem is that that path may not exist on the other developer's machines... They might have the SCM dir (where the LLBLGen dll's are) pointed at a completely different local path.

Am I missing something? It seems like this would be a common problem for any team environment.

TIA, Jack

The problem is that VS.NET works with that darn registry key... A vs.net project contains a hint path where the runtime libs can be found. If that path doesn't exist, vs.net will traverse the keys and check if the libs can be found there. It also traverses the GAC if no dlls can be found and if they're located there, it will use these.

You could opt for placing the dll's in the GAC, but I won't recommend this. One solution I'd recommend in your case is to add the dll's to a folder on your project and reference them from there. As project files are modified, not overwritten, it is a one-time setup action.

Another one is a shared folder on the network. But I'm not sure if that's appropriate / possible in your situation.