Visual Studio can’t overwrite an EXE or a DLL file if the file is being locked by another process. Likewise, VB Migration Partner can’t read and analyze a DLL file if the file is being locked by another process. In some circumstances, these locks may cause either the migration process or the Compile command to fail (either in interactive mode or in batch mode, when the /compile option is used with the VBMP.EXE command-line tool). Let’s describe a few of such scenarios.
First scenario - Assume that the VB6 project includes the following migration pragmas:
where the latter pragma tells VB Migration Partner to modify the output path of the .NET project being generated so that it points to the c:\output\dlls directory (see this article for more information). The combined effects of these pragmas is that you can then compile the .NET project and generate the executable file in the same folder where VB Migration Partner looks for the DLLs to be analyzed before the next migration.
Unfortunately, the current version of VB Migration Partner doesn’t support this scenario, because VB Migration Partner always locks all the DLLs found in the folder mentioned in the AddLibraryPath pragmas (and its child folders, if the second argument is True). Therefore, Visual Studio can’t overwrite those executable files when compiling the .NET project and the compilation fails. Notice that this is an issue both with the interactive version of VB Migration Partner and with the VBMP.EXE command-line tool, if used with the /Compile option.
Second scenario - You use either the interactive or the batch version of VB Migration Partner to generate a .NET project, then you attempt to compile it by means of the Compile menu command or the /Command command-line option, or you load Visual Studio and then attempt to compile the .NET project from there. Under these circumstances in some cases, especially when you repeatedly attempt to re-compile the same project, the compilation fails because the output executable file appears to be locked by another project. This issue typically manifests itself randomly.
In all the cases that we could analyze, we found that this issue is caused by a hidden *.vshost.exe project that stays in memory and keeps a lock on the output EXE or DLL file. This process has been created by Visual Studio during a previous launch of the application being tested and wasn’t killed properly when the debug session was over. (This appears to be a Visual Studio bug.) You can see this hidden process by running Windows Task Manager and switching to the Processes tab.
If you indeed find that this hidden process is preventing you from re-compiling your .NET projects, you might want to tell Visual Studio not to create it when you debug the application. You can do this from inside the Debug tab of the My Project folder, or you can add this pragma to the VB6 project being migrated:
Third scenario - This is a variant of the second scenario: You keep two or more instances of VB Migration Partner open at the same time and working on the same projects or sets of projects. If you compile from one of the instances, a phantom *.vshost.exe process might lock the executables produced by the compilation process. If you later attempt to migrate and compile from the other instance, the lock prevents from completing the compilation.
The same problem occurs if you keep a VB Migration Partner instance open while you use the VBMP.EXE command-line tool to convert and compile the same set of projects.