We recently installed LLBL 2.0 on our TFS build machine along side v1.5. For some reason, the build process was referencing the old version instead of the new version, thus never succeeding. I uninstalled v1.5 and the build process started working agian.

Why? I don't know.. Just glad I can move on to something else. Took me a while to notice the path was wrong in the buildlog.txt.

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Csc.exe /noconfig /unsafe- /checked- /nowarn:1701,1702 /nostdlib- /warn:4 /baseaddress:285212672 /define:TRACE 



/reference:"C:\Program Files\Solutions Design\LLBLGen Pro\RuntimeLibraries\DotNet20\SD.LLBLGen.Pro.DQE.SqlServer.NET20.dll" 

/reference:"C:\Program Files\Solutions Design\LLBLGen Pro\RuntimeLibraries\DotNet20\SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll" 

It's VS.NET: if you load a .net 1.1 v1.0.2005.1 project in vs.net 2003, and you have v2 and v1.0.2005.1 installed it will pick the v2.0 dlls (you don't want) If you load a .net 2.0 v2.0 project into vs.net 2005 and you've both versions installed, it will pick 1.0.2005.1's dlls. You also don't want that.

I think it's the registry paths which tell vs.net where to find assemblies for the 'add reference' dialog. As both filenames are the same, it will pick odd versions, DESPITE the version specified in the csproj file. Oddly enough, vb.net doesn't do this that often.

Otis wrote:

It's VS.NET: if you load a .net 1.1 v1.0.2005.1 project in vs.net 2003, and you have v2 and v1.0.2005.1 installed it will pick the v2.0 dlls (you don't want) If you load a .net 2.0 v2.0 project into vs.net 2005 and you've both versions installed, it will pick 1.0.2005.1's dlls. You also don't want that.

I think it's the registry paths which tell vs.net where to find assemblies for the 'add reference' dialog. As both filenames are the same, it will pick odd versions, DESPITE the version specified in the csproj file. Oddly enough, vb.net doesn't do this that often.

You know, I have to admit I THOUGHT it was working before we started generating our DAL in C# instead of VB.NET last week, but but since we had only done one or two builds, I couldn't remember. It must be a problem with C#.