5

I'm developing a unit test project (let's say XXX.UnitTest) to test ViewModels in another project (XXX) in my solution. I can add the reference but when I build, an error states that it cannot find that same project (XXX)

Error 42 Could not load file or assembly 'XXX, Version=1.0.2.66, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified. XXX.UnitTest

  • I did a clean rebuild of all projects in my solution.
  • I verified that the assembly with that version number (1.0.2.66) did exist in the path I was referencing.
  • I removed and re-added the reference both as a project and through the Browse tab.
  • I made sure that the version number was not specified in the csproj file.
  • I verified the referenced assembly with Dependency Walker.
  • I verified that both projects were targeting the x86 platform. (As suggested here Tips to help debug "Could not load file or assembly X or one of its dependencies")

Does anyone know what else can cause this problem?

Community
  • 1
  • 1
Blanthor
  • 2,568
  • 8
  • 48
  • 66

3 Answers3

1

Last week I had this same problem. It turns out my solution and projects were on a network resource. If I moved the solution to the local drive, the problem went away.

  • This problem happened regardless if I used a mapped drive or an UNC path.

  • This problem happened even with a Code Access Security Policy of "Full Trust" for the URL.

  • I believe the problem occurs on Windows XP computers and not Windows 7 computers, but have not tested or verified.

  • I believe it has something to do with the Share permissions.

    • If I try to use "offline folders" for the network resource, I get "access is denied".

    -.

  • Setting NTFS permissions has no effect.

  • Adding user to administrators group has no effect.

  • I did not test to see if problem exists on removable local drives.

Work Around

Move solution and projects to a local hard drive.

Comment

I think this is a bug in Visual Studio 2010.

AMissico
  • 21,470
  • 7
  • 78
  • 106
  • I found a temporary fix was to reference the assembly in the working folder, which in this case is a deployment folder I am debugging out of. Your fix seems to be related and interesting, in that it is also path-related. – Blanthor Jul 27 '10 at 15:08
  • I have to award this answer as the closest thing there is to a solution. It appears that it must be worked around by changing to local paths. In my case however the drive was already local, but I had to change the reference to the deployed assembly in my local drive. – Blanthor Mar 31 '11 at 20:33
1

I came across this post while searching for the answer. Here is the solution. In the config file of QTAgent32.exe and devenv.exe in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE, add the following element to the section:

<runtime>
    <loadFromRemoteSources enabled="true" /> 
</runtime>

This can be added to machine config file (C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Config\ machine.config) for all VS2010 tools. Be sure to run notepad as administrator to allow machine.config to save.

See this link for details: http://msdn.microsoft.com/en-us/library/dd409252%28VS.100%29.aspx

Chi
  • 41
  • 7
  • Thanks. This wasn't a Web project but a WPF project. Unfortunately I am not working in this environment. So I cannot tell try any new fixes. – Blanthor Mar 31 '11 at 20:28
  • Wow, I've been searching everywhere for the same problem. This one really works for referencing assemblies from a network drive!! Thanks! – Herman Cordes Dec 14 '11 at 08:05
0

I have the same problem. I'm running VS 2010 on Windows Server 2003; both running within a VM on a Mac. My VS project is in the mac home folder (~/) which is mapped as Z:\ from the Windows side. At build time, VS studio generates an error saying it can't find the UnitTests.dll or one of its dependencies. I get the same error with a small test project. If I move the project to the Windows C:\ drive, the dll reference resolves and unit tests work. I tried to add the reference Blanthor mentions, but couldn't get it to work.

refraction
  • 1