View DLL Dependencies

[cmay]

I have been having some problems lately where I get the error where it
says that it cannot copy the new DLL b/c it will overwrite a reference
to the old version.

I know why this error happens, but often lately when I fix it, it
doesn't "work".

I have to manually delete dlls, restart VS.Net, close the solution,
stuff like that to get it to work.

Somewhere, something is getting heldup for whatever reason.
Is there any way to take a DLL and find its dependencies? When it says
that there is a reference to DLL XXX.XXX with version 1.123.1233.3211 ,
where is that information stored?

I tried looking at the DLL in ISDASM and tried looking at the project
file in notepad, but no luck.

How can I find these dependencies?

[Nick Malik [Microsoft]]

if you have assemblies A, B, and C, and A depends on B and C depends on B
and A, then you can easily get this problem.

A's dependency on B is defined as a dependency on the DLL file, while B's
dependency is a project dependency, so it is updated with each build.

Problem is, when you compile C, it wants to put both A and B into the
project folder, which won't work, because A depends on a different version
of B than C does.

The way to fix this: go through your projects for A, B and C. Drop every
reference and recreate it. If you make a DLL reference somewhere, make the
same reference everywhere. You cannot mix and match.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"cmay" <cm**@walshgrou p.com> wrote in message
news:11******** **************@ g44g2000cwa.goo glegroups.com.. .

I have been having some problems lately where I get the error where it
says that it cannot copy the new DLL b/c it will overwrite a reference
to the old version.

I know why this error happens, but often lately when I fix it, it
doesn't "work".

I have to manually delete dlls, restart VS.Net, close the solution,
stuff like that to get it to work.

Somewhere, something is getting heldup for whatever reason.
Is there any way to take a DLL and find its dependencies? When it says
that there is a reference to DLL XXX.XXX with version 1.123.1233.3211 ,
where is that information stored?

I tried looking at the DLL in ISDASM and tried looking at the project
file in notepad, but no luck.

How can I find these dependencies?

[cmay]

Yes, I understand why I would get this error, but my problem is that I
fix the issue in VS.Net, but it doesn't take effect like it should.

Basically I have the situation you are describing. I have 3 DLLs (2 of
which depend on the 3rd) which are all referenced by my main project.

From time to time I will update one of the DLLs and forget to rebuild

the others with the new references, and end up with the dependency
errors on the build.

At this point, there is no "fix" that will work 100%.

I rebuild all projects.
I delete all existing DLLs from my components folder.
I re-reference all DLLs.
I delete all the bin folders.
I restart IIS.
I restart VS.Net.
So when I was having this problem last, it kept telling me that there
was a reference to some old version of a DLL, even though I had re-done
all the references for the 3 projects that reference that DLL many
times over.

I wanted to see if I could actually open up the DLLs manually and view
their dependencies, so I could see where the problem was. It has to be
either a) DLLs are not being properly rebuilt w/ their new references,
b) VS.Net is somehow not recognizing that the DLLs have been updated
during the build process.

[hB]

Maintain the References as a project output. (so it will update upon
the rebuild of independant dlls to the dependant ones).

Else if you dont want the references to be used in the code directly,
then what we did is we removed reference from one of the project.
like
A depends on B.
C depends on A and B.
so we made C depends on A (by removing B's reference)
and output of A and C is kept at the same place / directory (or Say a D
project which needs all). So in that directory-location we always have
the latest version of all the Dlls-assemblies.

---
hB

[Nick Malik [Microsoft]]

I have a really odd hunch. May not be anything, but it's easy to check.
http://blogs.msdn.com/nickmalik/arch...21/431206.aspx

Open the project files for each of the projects. Look at the project GUID.
Make sure that all project GUIDs are different.

Like I said... just a hunch.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"cmay" <cm**@walshgrou p.com> wrote in message
news:11******** **************@ g44g2000cwa.goo glegroups.com.. .

Yes, I understand why I would get this error, but my problem is that I
fix the issue in VS.Net, but it doesn't take effect like it should.

Basically I have the situation you are describing. I have 3 DLLs (2 of
which depend on the 3rd) which are all referenced by my main project.

From time to time I will update one of the DLLs and forget to rebuild

the others with the new references, and end up with the dependency
errors on the build.

At this point, there is no "fix" that will work 100%.

I rebuild all projects.
I delete all existing DLLs from my components folder.
I re-reference all DLLs.
I delete all the bin folders.
I restart IIS.
I restart VS.Net.
So when I was having this problem last, it kept telling me that there
was a reference to some old version of a DLL, even though I had re-done
all the references for the 3 projects that reference that DLL many
times over.

I wanted to see if I could actually open up the DLLs manually and view
their dependencies, so I could see where the problem was. It has to be
either a) DLLs are not being properly rebuilt w/ their new references,
b) VS.Net is somehow not recognizing that the DLLs have been updated
during the build process.