(CSLA 1.4) DLL Hell in .NET after all?

Q Johnson posted on Tuesday, November 28, 2006

I'm modifiying an old CSLA 1.4 app in which I had been including the CSLA project in my solution. I decided to to start by simplifying a bit and removed that project (after confirming the source location). Then I added references to the debug versions of the library components (only four of them in 1.4) in the two remaining projects that require them.

Now my Task list in VS 2003, I see a pair of these error messages:

Warning: the dependency 'CSLA.Server.DataPortal, Version=1.4.2523.20457, Culture=neutral, PublicKeyToken=87a33c0b07abb16c' in project 'NpUtility' cannot be copied ot the run directory because it would overwrite the reference 'CSLA.Server.DataPortal, Version=1.4.2523.19211,Culture=nuetral,PublicKeyToken=87a33c0b07abb16c'.

I've got a pair of them for ServicedDataPortal too (different versions referenced, though: 20460 and 19220).

And I've even got trouble with SQLDMO:

Cannot copy assembly 'Interop.SQLDMO' to file 'D:\V_Projects\NpUtility\NpUtilityWin\bin\Interop.SQLDMO.dll'. Access is denied.

I only have one version of 1.4 on this machine (although I have 1.52 and have been careful NOT to reference it).

What have I done? And, more importantly I guess, what can I do to fix this so that I can get back to work? (I actually tried deleting the dlls from the projects' bin folders, but when I rebuild those same older versions are being written back into them from somewhere!)

Thanks in advance.

Fintanv replied on Tuesday, November 28, 2006

A few suggestions [I feel your pain ;-)].

1. Check the references path for each of the projects.

2. Make sure the dll's you are referencing from all projects reside in a single location (ex. Lib sub-dir), and add that sub-dir to your references path. This should be done even if your production app will use the dlls from a GAC reference. This applies not only to CSLA dll's but any and all third party dll's you will use in your app.

3. Fire up notepad2 and take a look at the proj and sln files to see if there are hidden references to the offending dll's.

Regards, Fintan

RBrown replied on Tuesday, November 28, 2006

I concur with the previous posts. Had the same issue in an non-Csla project once and had to trace back through every reference in the app as well as any references in the library projects being used. I have used the Reflector tool, which is probably a better tool, but the poor man's version is to simply double click the references in VS and view the referenced DLLs and versions. You'll find the culprit that way, adjust, and recompile.

Q Johnson replied on Monday, December 04, 2006

Thanks for the help, guys. I finally worked out the cause of my problem and was able to cure it.

By the time I had a handle on it I had already made it worse instead of better. I was fighting myself in two significant ways. First, the combination of VSS source code control and the Wise setup project in my solution were trying to keep the same version of dlls in my run directory. And by including CLSA's components as projects rather than lib dlls, I was changing version numbers while I was building all the time. I think at one point I had switched from referencing the projects to referencing their output dlls for one or more of the components and you can imagine the chaos that this caused.

I finally just started with a blank solution and built another from scratch with copies of the source files, figured out the plumbing issues, corrected them in my original project, deleted the contents in the run directory and rebuilt successfully.

Thanks for getting me pointed in the right direction! The upgrade is shipping today!