Error “Metadata file '…\Release\project.dll

Question

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 :(

Answer 1

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.

Answer 2

I've also seen this error in solutions where I have multiple projects (usually netTiers projects where I've updated one or more of the sub-projects to target the 4.0 framework). It can be problematic to remove. Oftentimes it can be resolved, however, by first fixing all other errors in sub-projects (eg, any missing references), individually rebuilding those sub-projects, then removing/adding back any references to those sub-projects in Visual Studio. Personally, I've had little luck resolving this error by cleaning the solution alone.

Answer 3

I had this problem and it was due to an invalid method in the offending library (dll) that did not return a value, e.g.

public bool DoSomething()
{
   //I never bothered putting code here....

}

When I commmented this out everything compiled :)

Answer 4

Well, my answer is not just the summary of all the solutions, but it offers more than that.

Section (1):

In general solutions:

I had 4 errors of this kind (‘metadata file could not be found’) along with 1 error saying 'Source File Could Not Be Opened (‘Unspecified error ‘)'.

I tried to get rid of ‘metadata file could not be found’ error. For that, I read many posts, blogs etc and found these solutions may be effective (summarizing them over here):

1. Restart VS and try building again.

2. Go to 'Solution Explorer'. Right click on Solution. Go to Properties. Go to 'Configuration Manager'. Check if the checkboxes under 'Build' are checked or not. If any or all of them are unchecked, then check them and try building again.

3. If the above solution(s) do not work, then follow sequence mentioned in step 2 above, and even if all the checkboxes are checked, uncheck them, check again and try to build again.

4. Build Order and Project Dependencies:

   Go to 'Solution Explorer'. Right click on Solution. Go to 'Project Dependencies...'. You will see 2 tabs: 'Dependencies' and 'Build Order'. This build order is the one in which solution builds. Check the project dependencies and the build order to verify if some project (say 'project1') which is dependent on other (say 'project2') is trying to build before that one (project2). This might be the cause for the error.

5. Check the path of the missing .dll:

   Check the path of the missing .dll. If the path contains space or any other invalid path character, remove it and try building again.

   If this is the cause, then adjust the build order.

   ---

Section (2):

My particular case:

I tried all the steps above with various permutations and combinations with restarting VS few times. But, it did not help me.

So, I decided to get rid of other error I was coming across ('Source File Could Not Be Opened (‘Unspecified error ‘)').

I came across a blog: http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539

I tried the steps mentioned in that blog and I got rid of the error 'Source File Could Not Be Opened (‘Unspecified error ‘)' and surprisingly I got rid of other errors (‘metadata file could not be found’) as well.

---

Section (3):

Moral of the story:

Try all solutions as mentioned in section (1) above (and any other solutions) for getting rid of the error. If nothing works out, as per the blog mentioned in section (2) above, delete the entries of all source files which are no longer present in the source control and the file system from your .csproj file.

---

Answer 5

It seems to happen when you checkout a solution with multiple projects that have references between them, and you haven't built it before. If you have references directly to the dlls, instead of referencing the project, you'll get this message. You should always use the Projects tab in the Add Reference dialog to add a reference to a project in the same solution. This way, VS can know the correct order in which to build the solution

Answer 6

I agree with most of the answers posted here. However if all the suggested solutions didn't work, consider that you probably have another kind of error in your error list, that is preventing VS to build a project's DLL needed for the other projects. Then no matter the build order or configuration, you won't be able to get rid of "metadata" error till the other issues are sorted out.