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

user_94990 0
Viewed 198791

Recently I started to get this message randomly:

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

I have a solution with several projects in it. The current build mode is Debug and all projects' configurations are 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 a similar problem, but there was no solution, or at least no working solution.

I tried to delete references to those projects and read 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 in an easy way. It disappeared only after I reinstalled Windows :(

resolveassemblyreference release visual-studio debugging
44 Answers

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 removed 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.

Darren_Steinweg_4180

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.

user_1161760

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

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

user_1016350

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 Visual Studio 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 Visual Studio 2010.

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

  • Switch configuration
  • Restart Visual Studio
  • Build the solution
user_1219910

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.

user_1029370

For me was to remove/delete entire .vs folder(that is an invisible one) and then:

- Build
- Rebuild

and done.

user_46427580

in my case i was working on a branch off master. so i checked out master branch, ran a build and then checked out my branch. It fixed the issue. If you already are on master, i suggest you check out previous commit and then build it.

user_32089110

I had the same problem. I noticed that my db context (EF4) that was located in the project dll wasn't recognize for some reason. I deleted it and created another one instead. and that solved it for me.

user_11897000
user_28786890

Check wether the .vs folder in the project root is hidden or not. Mine wasn't (and it should) since I did a copy/paste from another pc. Deleting it solved the problem, Visual Studio 2015 just recreated it for me.

user_52148080

I had the same issue, non of the provided answers fixed it before. Apparently this could be a problem with the .csproj file. For some reason the references to files that were not even made anywhere in my code were still "missing".

Open your .csproj file with a text editor and look for the files missing, delete, save and be happy.

user_73555610

For me, I was using EntityFramework.6.2.0 Updated to EntityFramework.6.4.0 then problem is solved.

user_12626730
Related