Last post Jul 23, 2007 03:20 PM by Darrel D
Jul 20, 2007 03:39 PM|Darrel D|LINK
Visual Studio 2003 is not noticing when a dll reference is changed in asp.net projects, when the project reference is changed by another person in the source safe project .For an example Lets say that we have a custom component on the network that is stored
in j:\CustomComponents\Encryption\v2\Encryption.dll, which is referenced in the ASP.NET project. Then we create a new version of the component and save it in a folder called v3. In Visual Studio one of the members in the source safe project then changes the
reference in the web application to point to the new location j:\CustomComponents\Encryption\v3\Encryption.dll, and then check it in. It will run and compile just fine from that person's computer. When another person on the team gets the latest version of
the project however Visual Studio still thinks that the network path for the dll is stored in the v2 folder. Things will not run and compile. But however if you view the project file in a text editor it will say that the dll reference is pointing to v3, which
is correct. It is just inside of Visual Studio that the reference is wrong. It seems to be completely ignoring what is in the project file. We have been unable to figure out where it is getting the v2 from. We have deleted files from the temporary cache locations,
but the reference inside Visual Studio is still wrong. The only way the reference will get updated is if each member on the team who needs to run the project, checks out the project, deletes the reference from visual studio and then re-adds it.
This severely limits the ability for multiple developers to work on the same project as we are constantly having to duplicate project reference changes, and we can never be sure that the references are correct. Everything works just fine with WinForm applications,
despite referencing the same dlls that are in the asp.net ones.. It is only WebForm applications that is causing the problem.
Help would be appreciated. What can we do to get Visual Studio to reread the project file to get the proper dll references.
Jul 23, 2007 07:16 AM|Kevin Yu - MSFT|LINK
When you add reference to a certain assembly, the VS.NET will actually copy that assembly file to the local folder of this project, if Copy Local has been set to true. So when this project runs, it will look in the local folder for the referenced assembly.
The IDE will not look for a new one if the assembly on the network drive changes. So, I would suggest you add this assembly to your project as a file. So each time you get latest version, it will be get. And in the reference property, set Copy Local to false.
Each time you're going to run the application, manually copy the latest version of assembly to the bin folder and it will work as expected.
Jul 23, 2007 11:41 AM|Darrel D|LINK
THanks for your response but I don't think that answer is exaclty right, at least from what we have observed. If copy local is set to true, Visual Studio does, when the the poject is compiled or the IDE is opened, get the dll from the network and not the
local folder. So if we overwrite the dll on the network drive with a new version of the assembly, Visual Studio does correctly get the changes to that dll. The problem is when in the web project we change the file path of where Visual studio should get
the dll. If we look at the actual project file in a text editor it might say that the file path is j:\CustomComponents\Encryption\v3\Encryption.dll. But when we open up the project in Visual Studio it says the dll should be taken from j:\CustomComponents\Encryption\v2\Encryption.dll.
Which means both while programming, and during compilation it takes the dll from the v2 location, which it should not be doing. So it continually gets the dll from the network, just from the wrong spot.
I have tried the following:
- Deleted the VSWebCache from my local profile
- Deleted project files from C:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files
- Cleared out the local bin folder. (But for all three of these visual studio still reads from the wrong network folder.)
- Did a seach for the text j:\CustomComponents\Encryption\v2\Encryption.dll (but that string does not exist anywhere on my computer.But still Visual Studio uses it.)
- Even did a registry search for that string. (It still does not exist.)
And actually clearing the VSWebCache caused reference problems, just like when a project file is updated from source safe. All the refrence paths that are listed when Visual Studio is next opened seems to revert to an earlier state, probbably to the orignal
location of the dll when it was first added. I have to delete all the references from within the IDE and re-add them.
Jul 23, 2007 03:20 PM|Darrel D|LINK
I have been able to find the cause of the issues. There was actually two problems:
1) Visual studio uses a file with the extension .vbproj.user that is stored in the web cache area of the developers profile. Visual Studio looks there first to find the location of the dll references. And only if it does not find it in there, does it look
in the project file. Changing a reference using the IDE will change your individual .vbproj.user file but not everyone elses on the team. We may be able to get around this problem by creating a macro that clears the references in the .vbproj.user file, so
that Visual Studio will always look in the project file.
2) Visual Studio uses the dll references to store the folder that the dll is in, not the exact location to the dll. Lets say that we have a dll named dataaccess.dll in the /v2/encryption folder that is referenced in the project file, and used by the encryption
dll. Visual Studio then stores that directory name. Later in the project file it then sees a reference to a dll named encryption.dll that is in a /v3/encryption folder. But because there is a dll with the same name in the v2 folder, and it was referenced
first, it uses the v2 version instead. When we add a reference using the VS IDE, Visual Studio likes to add all dlls from that location, which is why the references ended up as it is. We will be able to get around this issue by making sure that when we compile
a component, copy local isn't set to true for any dlls it may need to reference