4

I'm having an issue building a project that references a DLL located in the project's bin folder, which up until yesterday was building and running without issue.

The error I'm getting is fatal error CS0009: Metadata file 'c:\MyProject\bin\myClient.dll' could not be opened -- 'Error importing module 'myClient.netmodule' of assembly 'c:\MyProject\bin\myClient.dll' -- The system cannot find the file specified.' Intellisense is similarly complaining that The type or namespace 'Api' does not exist in the namespace 'Client' since it can't find the DLL.

Let me know if you think this is a duplicate, but I've viewed several similar posts and the solutions did solve my problem. Here are some examples:

Specifically, I've tried the following solutions (and combinations of these):

  • Cleaned and rebuilt my project.
  • Made sure that the target framework is not a 'client profile' version of .NET
  • Verifyied that the dll has been added as a project reference
  • Removed and re-added the project reference
  • Verified that the project is showing the DLL in the References section in Visual Studio
  • Repaired .NET
  • Verified the location of the DLL (it is in the local project's bin folder as given by the error)
  • Tried other versions of .NET
  • Closed and restarted Visual Studio
  • Rebooted my machine
  • Verified there are no hidden characters surrounding the 'using' statement
  • Removed all code changes since the last working build
  • Verified the settings in Configuration manager, including that 'Build' is checked

The project calling the DLL is a small class library that resides in a solution with one other small project (a console application). The DLL is an external DLL that I've been using successfully for several weeks in this project/solution. The error arises regardless of whether I build the project from the solution or by itself.

Any ideas about what could be going on?

Community
  • 1
  • 1
user1205577
  • 2,388
  • 9
  • 35
  • 47
  • Perhaps I missed it. Did you in fact confirm that c:\MyProject\bin\myClient.dll exists? – Jonathan Wood Nov 30 '12 at 15:38
  • Yes it exists and at that correct location. I even deleted it, re-added it, and restarted everything. no luck. – user1205577 Nov 30 '12 at 15:39
  • 2
    That's odd. However, it's possible that the DLL relies on another file, which did not exist. It could simply be the 'file not found' error propagating up. – Jonathan Wood Nov 30 '12 at 15:40
  • I considered that, but it's the same dll I've been successfully using for a couple of weeks. The dll hasn't changed, so I don't think it would suddenly be trying to reference another dll. – user1205577 Nov 30 '12 at 15:42
  • Have you checked that framework versions are compatible between the dll and the project that references it? – Igor Nov 30 '12 at 15:44
  • 1
    @user1205577: If my suggestion was indeed the case, it wouldn't be because the dll suddenly started accessing another file. It could happen if one of that dll's dependencies had been removed. I can't know if this is in fact the case, but I do recall seeing that type of situation back in my VB6 days. – Jonathan Wood Nov 30 '12 at 15:53
  • Yep. They're compatible, and have been working together for a couple of weeks. – user1205577 Nov 30 '12 at 15:55

2 Answers2

1

Have you included bin folder in your project accidentally? If yes that might cause the issue. You can't include bin folder in your project as the bin folder will be created by the VS. If you accidentally include bin folder in your project, the bin project will be set to Copy to output which when you compile, the file is deleted and copied to output by Visual Studio that trigger weird behavior that some file is missing.

Hopes this help

John Kenedy
  • 564
  • 1
  • 5
  • 18
0

Well I'm not sure exactly what happened here, but here is what finally resolved the issue:

A good-old-fashioned delete every single file and rebuild the project from those files from scratch. I gave +1 to some of the responses because they were useful to consider, and because there was probably a messed-up reference some where as Jonathon Wood suggested.

user1205577
  • 2,388
  • 9
  • 35
  • 47