Visual Studio adding executable file with same nam

问题:

In Visual Studio 2008, I added WinScp.dll (in project root) as a reference and immediately there was a yellow icon. At compile-time:

• The type or namespace name 'WinSCP' could not be found (are you missing a using directive or an assembly reference?)
• Resolved file has a bad image, no metadata, or is otherwise inaccessible. Could not load file or assembly 'E:...\winscp.exe' or one of its dependencies. The module was expected to contain an assembly manifest.

After an hour's frustration, I figured out that if I removed WinSCP.exe as a project file (also in project root), everything compiled fine. Weird!!!!

The problem is that I need both WinSCP.dll and WinSCP.exe in my output directory. What do I do?

EDIT: I understand that there are workarounds, such as renaming the files or changing the paths. I renamed the exe at first; now I rename the dll (thanks @Michael) because it does not require me to also specify the renamed exe in my code.

But why is there a problem in the first place? WinSCP.dll and WinSCP.exe are two different files. Is this a bug in Visual Studio, or an intricacy of dll/exe that I don't understand?

回答1:

WinSCP.dll and WinSCP.exe are two different files

Not to the assembly loader, it doesn't pay attention to a filename extension. All it knows is that it needs to find an assembly with a display name of "winscp". When searching for a match, it first tries an EXE file with that name, next a DLL file. Something you can see with the Fuslogvw.exe utility. Display names are described in this blog post by the Microsoft guy that worked on the Fusion component:

The "name" part is usually the file name of the assembly, excluding the extension. So for assembly foo.dll, the "name" part is "foo". Of course, since I said "usually", there are times when the "name" part is not the same as the file name excluding extension. I will discuss this in a bit.

Emphasis added. So it finds WinSCP.exe first and that's a kaboom, it is not a valid .NET assembly. The simple workaround is rename the DLL, that changes the display name of the assembly.