vshost.exe一直在访问我的.dll，我在构建它时无法更新它

Question

I have set an output folder for my .dll project though the Project Properties, which I call "Output".

The problem is, from an empty Output folder, the first time I Build the project, it's fine. The second time, I get the following error:

Error 328 Unable to copy file "obj\\Release\\MyLibrary.dll" to "......\\Output\\Release\\MyLibrary.dll". The process cannot access the file '......\\Output\\Release\\MyLibrary.dll' because it is being used by another process.

The "another process" is the vshost.exe from Visual Studio. Since it keeps acessing MyLibrary.dll, it can't be deleted or replaced, thus why the error. This keeps the MyLibrary.dll on the Output folder not updated. However I have other .dll projects in my solution in which this does'nt happen.

The solution I have used so far to update it is to close the VS (thus closing vshost.exe), then run a .bat file which deletes the file Output\\Release\\MyLibrary.dll, then open the VS again and Rebuild it's project.

I know little of what exactly vshost.exe does, so I have no idea from where to start to clear this problem from the root. I don't know why this happens to a specific .dll. I appreciate any idea that helps me investigate why this happens.

Answer 1

vshost.exe is the Visual Studio Hosting process. It is a custom CLR host that loads your EXE and makes debugging easier. You can turn it off, that has very few side-effects. Project + Properties, Debugging tab, untick the "Enable the Visual Studio hosting process" option.

You are more likely to find the real problem in your program now. With the most common issue that your program doesn't quit when you ask it to. You will still get a build error, you'll now see your own EXE fingered as the one that keeps a lock on the DLL. You will also see it back in the Task Manager's Process tab. Which also allows you to kill it.

It isn't that clear to me how programmers recreate this problem. Pressing Ctrl+F5 instead of F5 certainly will do this, always press F5 to immediately attach the debugger when you start the program. Using Debugger + Stop Debugging will now reliable stop the program. You can otherwise use Tools + Attach to Process to get a debugger attached again later to find out what your program is doing.

Anti-malware is a common scourge worth mentioning, they get way too excited when they see an executable file appear from nowhere. If you use Avast then just uninstall it completely, it is quite incompatible with VS.