Thank you for submitting this question as it is likely that others will have a similar question.
A programmer using Visual Studio (or the command line .Net compiler) cannot rebuild a .Net assembly which has been loaded by APL+Win
This is a Microsoft limitation of Win32 applications which generally applies only to the development stage of the .Net assembly.
APL+Win is a Win32 application.
For a Win32 application to use a .Net assembly, the object model of that assembly must be exposed as COM.
Microsoft has not provided a way for a Win32 application to release a .Net application domain that has been exposed as COM.
This condition applies to any .Net assembly exposed as COM which is loaded by a Win32 application such as APL+Win or Visual Basic 6.
This condition applies to the APL+Win cse system function because it uses a COM interface to load the .Net assembly.
Here are some of the implications of this limitation of a Microsoft Win32 application:
Once loaded by a Win32 application the .Net assembly exposed as COM will not be released until the Win32 application is closed
It is not possible to overwrite the .Net assembly file while it is loaded by a Win32 application
There is no limitation on the use of the .Net assembly because any number of instances of a .Net or Win32 application may simultaneously load and use the .Net assembly exposed as COM
A programmer who is developing a .Net assembly exposed as COM for use by a Win32 application will observe the effects described above if that programmer loads the .Net assembly exposed as COM by a Win32 application from the development location of that .Net assembly
. For example, the exception message received when Microsoft Visual Studio tries to overwrite the .Net assembly, currently loaded by a Win32 application, when the programmer attempts to Build/Re-Build the Visual Studio project is "Error 12 Unable to copy file "obj\Debug\....dll" to "bin\Debug\....dll". The process cannot access the file 'bin\Debug\....dll' because it is being used by another process." The "other process" in this exception message is the Win32 application which currently has the .Net assembly loaded from the development location of that .Net assembly
This situation can be easily resolved by the programmer by making a copy of that .Net assembly in a location different from the development location of that .Net assembly and loading the .Net assembly from the different location into the Win32 application. This copy procedure must be repeated each time the .Net assembly is re-built in Visual Studio, however it is good practice to do so because in a production environment the Win32 application will not be loading the .Net assembly from the development location of that .Net assembly.
These effects will also be observed if an end user attempts to overwrite a .Net assembly exposed as COM which has been loaded by a Win32 application, for example if the .Net assembly is being updated with a new version. This is why, when applying updates, it is recommended that all other applications be closed.