The VS 2008 assembly reference problem

Published Fri, Oct 2 2009 11:42

I’m not sure if anyone has noticed this, but VS 2008 won’t be able to get to an assembly stored in a UNC shared folder after it’s been opened for some time. Let me give more info on this…

We’ve set up a UNC shared folder which has several assemblies which are shared by all our projects (it includes internal and external – ex.: NHibernate.dll – assemblies and we’ve set it up because it ensures that all the projects will always build against the latest dependent assembly).

When you load a solution in VS, it compiles ok…the problems happen when you leave VS open for a long time without building. For instance, I’ve left it open with solution X two days ago and today it simply wouldn’t compile the damn thing and it kept saying it couldn’t access the UNC shared folder (when I tried to add the assembly again through the add reference dialog). I had to close all VS 2008 instances in order to solve this problem (yep, just opening a new VS instance still gave me the same message).

has anyone faced this problem? can we do anything to solve it (without closing and reopening all VS instances)?

by luisabreu

Filed under: VS

Comments

# Andrew Davey said on Friday, October 02, 2009 6:14 AM

Have you tried mapping a drive letter to the share instead of using it directly? I find drive letters a little more reliable sometimes.

# luisabreu said on Friday, October 02, 2009 6:22 AM

I haven't...need to ask the other guys to see if they've tried it.

# Pervez Choudhury said on Friday, October 02, 2009 10:09 AM

The apprach we take at work is to keep all of the external references within a folder in the solution called Libraries, with subfolders for each external library. Using Subversion, these can then be externals so that you can get the benefit of only having to update them in one place and and when you checkout to build, they will be part of the local file structure on your PC, and you will not have the UNC problem.

# luisabreu said on Friday, October 02, 2009 4:15 PM

Pervez, let me see if i got it right. what you're saying is that you've got a folder inside the current solution folder which points to a svn folder of another project (and this svn folder has the shared assemblies). is this it?

if it is, I've run into 2 problems:

1.) if you go to another machine, you need to start by getting the project you're working and then you need to create a folder that references that exernal svn folder. furthermore, the svn folder must have the same name as the one the guy that created the solution gave (I put my sln files into source code control)

2.) running an update in the top solution folder (which contains the subfolder which points to the external svn folder) won't result in an update in the contained external folder (you need to update that folder - I'm using tortoise).

since I'm not a svn master, this might all be wrong. if that is the case, please correct me :)

the unc shared folder makes building really easy: wherever I open the project, I can just build it because all the machines know where the shared assemblies are.