Metadata file '...\Release\project.dll' could not be found in Visual Studio

Question

Recently I started to get this message randomly. I have a solution with several projects in it. Current build mode is Debug and all projects' configuration is set to Debug. But when I try to run the main project - sometimes it gives me a few errors all of which are "Metadata file '...\Release\projectX.dll' could not be found" - and, look, it says about RELEASE folder, though current mode is Debug. Why? I tried to search for reference to "Release\projectX.dll" inside all solution files and I found one in ResolveAssemblyReference.cache file.

I made a good search over the internet and found a few people with the similar problem, but there was no solution, or at least no working solution.

I tried to delete references to those projects and readd them, but in some time I start getting these errors again.

It seems like a bug. Why does it search for referenced projects in Release folders when I always use Debug mode?

PS. For those who met this problem: I couldn't solve it with an easy way, it disappeared only after I reinstalled windows :(

Answer 1

I seem to recall having a similar problem a few months ago. I solved it temporarily by copying the referenced DLL to the Release folder, thus satisfying Visual Studio's expectations. Later, I discovered the reference to the Release DLL in my actual code. You should try doing a search through the entire project for \release\project.dll.

Also, I have noticed that Visual Studio unit test projects sometimes put a "DeploymentItem" attribute on each of the test methods pointing to your target DLL, and if you switch between Debug and Release, Visual Studio can get confused if the DLL is no longer in the expected location. In my experience, these attributes can be safely deleted if you didn't put them there yourself as part of a "single deployment" scenario.

Answer 2

Did you check the Configuration manager settings. In the project settings dialog top right corner.

Sometime it happens that between all the release entries a debug entry comes in. If so the auto dependency created by the dependenc grapgh of the solution gets all confused.

Answer 3

When you say you deleted references to those projects and re-added them, how did you re-add them, exactly? Did you use the "Browse" tab in the "Add Reference" dialog in Visual Studio? Or, did you use the "Projects" tab (which lists neighboring projects in your solution)?

Edit: If you use the "Browse" tab, and manually add the reference to your .dll that is located in the /Release folder, then Visual Studio will always look for the .dll in that location, regardless of what mode you're currently in (Debug or Release).

If you were remove the actual .dll file from the Release folder (either manually or by doing "Clean Solution"), then your reference will break because the .dll does not exist.

I'd suggest removing the reference to ProjectX.dll, and add it in again--but this time, use the "Projects" tab in the "Add Reference" dialog. When you add a reference this way, Visual Studio knows where to get the appropriate .dll. If you're in Debug mode, it will get it from the /Debug folder. If in Release mode, the /Release folder. Your build error should go away, and you also will no longer be (improperly) referencing a Release .dll while in Debug mode.

Answer 4

We have that problem quite often, but only with references to C++/CLI projects from C# projects. It's obviously a bug deep down in VS that Microsoft decided not to fix because it's 'too complex' and they promised an overhaul of the C++ build system which is now targeted for VS 2010.

That was some time ago, and maybe the fix even went into VS 2008, I didn't follow up on it any more. However, our typical workaround was

• switch configuration
• restart Visual Studio
• build solution

Answer 5

I've had this problem before and the only way I've found to solve it is to run Clean Solution and then restart Visual Studio.

Answer 6

I couldn't solve it with an easy way, it disappeared only after I reinstalled windows :(