DLL Hell

  • Thread starter Thread starter cmay
  • Start date Start date
C

cmay

I am squarly in DLL Hell.

I am looking for someone to point me in the direction of some guidance
as to the best practices when working with multiple projects and
dependencies.

We recently converted our main collection of .net code into multiple
projects (rather than grouping them all together into a few big
projects).

Our practice was to compile a project and move the DLL into a folder
where most recent DLLs would be placed (Say C:\DLLs for example). We
let visual studio modify the Build and Revision numbers on the version
for each DLL, and we also had VS.net strongly name them). After the
new DLL is moved into C:\DLLs it is put into VSS so other developers
can do a get on their DLLs folder for the most recent DLLs.

For each project that needed to reference another DLL would be pointed
to this DLLs folder. We didn't use project references because we
didn't want to have to load up all our projects just to change the code
behind of 1 page and successfully build. Also, if we did project
references, I believe that we could not work on one project, and
compile another. What I mean by that is, if I an working on ComponentA
and it is in no place for being put into production, I would be unable
to build WebApplicationA that references ComponentA as a project,
whereas if I used a DLL reference, I could recompile WebApplicationA as
much as I wanted b/c it would be pointing to the last "released" DLL
from the ComponentA project.


So anyway, I am having issues now. Not sure why these issues are
showing themselves now when we have been doing it this way for a few
months now, but these errors are driving me nuts.

I get stuff like:
Cannot copy assembly ... The process cannot access the file because it
is being used by another process. (And this error is on a DLL that has
no references to other DLLs of ours, and hasn't been updated in months)

The located assembly's manifest definition with name
'Namespace.whatever' does not match the assembly reference.

Also, stuff that I do doesn't show up in VSS. So say I add a class ABC
to component XYZ. I move the new XYZ.dll into my C:\DLLs folder. I
even overwrite MyApp\Bin\XYZ.dll with the new one, but the project
MyApp still can't see the changes I made to the XYZ project.


So all that said, back to my orig question. Can someone point me to
some best practices documentation on how deal with multiple projects,
the pros and cons of using project references, if we should be
incrementing our version numbers or not, if we should be strongly
naming our dlls or not etc.

In an ideal world I would just like to be able to rebuild a DLL, and so
long as I haven't broken binary compatability, just overwrite the old
DLLS with the new one and have it work.
 
General:
The idea of a central repository sounds good until you realize that DLLs can
get locked, even in .NET. References in the project work, however, even
references to a central repository. It copies the DLLs to each project, but
it should solve your deploy issue.

If the DLLs are truly global (i.e., the exact same version used by all
projects), you can put them in the GAC. I would not do this until you were
fairly stable, however, as the GAC can store multiple versions of a DLL and
end in another form of hell. You can alleviate this by allowing the app to
use newer versions. Make sure the DLLs you place in the GAC are truly
"global" in nature.

Specific:
Check if the DLL in question is read only. You will also want to check
permissions on it. It may also be in use by a project that never cleaned it
up (rare, but it can happen). If so, reboot.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
cmay said:
I am squarly in DLL Hell.

I am looking for someone to point me in the direction of some guidance
as to the best practices when working with multiple projects and
dependencies.

We recently converted our main collection of .net code into multiple
projects (rather than grouping them all together into a few big
projects).

Our practice was to compile a project and move the DLL into a folder
where most recent DLLs would be placed (Say C:\DLLs for example). We
let visual studio modify the Build and Revision numbers on the version
for each DLL, and we also had VS.net strongly name them).
Click to expand...

Ok that's your first problem. Never let VS auto increment your
AssemblyVersion. After each build you should increment AssemblyFileVersion
_not_ AssemblyVersion. AssemblyFileVersion is informational and used to
track releases. AssemblyVersion controls assembly loading compatibility.
Only increment AssemblyVersion whey you want to force dependant assemblies
to be recompiled against the new version, or use the old and new version
side-by-side.

When you increment AssemblyVersion, you break compatibility. That's what
AssemblyVersion is for.
After the
new DLL is moved into C:\DLLs it is put into VSS so other developers
can do a get on their DLLs folder for the most recent DLLs.

For each project that needed to reference another DLL would be pointed
to this DLLs folder. We didn't use project references because we
didn't want to have to load up all our projects just to change the code
behind of 1 page and successfully build. ...
[snip]
Click to expand...


That's your choice, but it's easier to use project references. But you're
correct that project references have hastles of their own. Using binary
references to compiled DLL's will work, basically along the lines you're
doing it. Some of your other headaches may survive fixing your
AssemblyVersions, but start with that.

David
 
David,

Thanks for the insight on the AssemblyVersion vs AssemblyFileVersion.

I bet that will ease a lot of our problems!


Chris
 
Back
Top