DLL References Not Updating

[cmay]

Maybe someone can give an idea of why I am having this problem before I
put my fist through the computer screen.


My problem goes like this....

Lets say I keep my DLLs in a folder called "DLLS".

I have an asp.net application called "app" that references some of
these dlls.

I make a change to one of the DLLs in the DLLS directory. (I open the
project, make the changes, build it (successfully), go to the bin
folder and copy it into the DLLS folder).

I open my asp.net application and "rebuild". (The DLL references are
pointing to the right place, and have "Copy local" set to true). The
rebuild does in fact copy the new DLL into the applications bin
directory (I can tell by file size, date, and using ILDASM).

But the rebuild does not enable my new application to gain any of the
changes in the DLL.

For example, lets say I added a class called "WhyDoesntThisCrapWork" in
the new DLL. That class is NOT available to me in the asp.net project.


I open the new DLL in ILDASM and it has everything.

I add the new dll to a new test application and it has everything.

So where could my asp.net application be caching its reference to the
old DLL, and what can I do to fix this and undo the reference?

What is the way you are supposed to be able to update a referenced DLL?

 

[Juan T. Llibre]

How are you "referencing" dll's so they can be
referenced to a directory other than the bin directory ?




Juan T. Llibre
ASP.NET MVP
ASP.NET FAQ : http://asp.net.do/faq/
==========================

 

[Kevin Spencer]

First, the correct way, when using Visual Studio.Net, to reference a DLL in
another project is to include the other project in the same Solution as the
ASP.Net project, and make a reference to the other project. VS.Net will then
manage the placing of the latest DLL from the other project into the correct
path in the ASP.Net project's bin folder at compile time. It is possible to
include a project in many solutions.

There are times when you may use a DLL that is not in a project, and copying
the DLL into the bin folder of the ASP.Net project should work fine.
However, as you are rebuilding the other project, you may be running into
some issue that is caused by your method of updating the DLL in the ASP.Net
project. I would suggest doing it the right way.

You may also be having a problem with not using the bin folder (recommended)
to store your DLLs. When you do this, you may need to make some changes to
your web.config file to tell your ASP.Net app where to look for DLLs. The
following .Net SDK article should be helpful if you decide to continue with
this method:

http://msdn.microsoft.com/library/d...ide/html/cpconhowruntimelocatesassemblies.asp

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[cmay]

I'll look over that file to see if I can gain some insight into what is
going on.


Is using project references really the prescribed best practice? I use
project references when I need to debug a component from within another
application, but we have always compiled our components and referenced
them as DLLs just like you would with any 3rd party DLL.


If we changed our setup to use project references I would have to load
up 50 projects or so in visual studio just to change a line of code in
our application.

 

[cmay]

What I mean is, we have 1 folder where we keep our DLLs, so in each
project you say Add Reference and point to this folder for the DLL you
need to reference. Then this folder is kept in VSS.