Unloading DLLs loaded by []CSE 'LoadAssembly'

General discussions related to using the C# Script Engine in APL+Win.

Moderators: Tech Support, phpbb_admin

Unloading DLLs loaded by []CSE 'LoadAssembly'

Postby Gert.Glantz » December 19th, 2013, 8:09 am

Hi,

Is there a way of unloading a DLL that has been loaded by []CSE 'LoadAssembly'? The 'Close' method does not unload it. Recompiling a loaded DLL fails and I need to shut down APL in order to unload it.

Regards,

/Gert
Gert.Glantz
 
Posts: 16
Joined: November 2nd, 2007, 12:14 pm

Re: Unloading DLLs loaded by []CSE 'LoadAssembly'

Postby joe_blaze » December 19th, 2013, 1:20 pm

Thank you for submitting this question as it is likely that others will have a similar question.

Issue:
A programmer using Visual Studio (or the command line .Net compiler) cannot rebuild a .Net assembly which has been loaded by APL+Win

Background Information:
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.

Suggested Resolution:
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.
joe_blaze
 
Posts: 384
Joined: February 11th, 2007, 3:09 am
Location: Box 361 Brielle, NJ 08730-0361

Re: Unloading DLLs loaded by []CSE 'LoadAssembly'

Postby Davin Church » December 19th, 2013, 2:44 pm

Isn't that true of any DLL loaded by APL (or other application)? Do I (vaguely) remember that we used to have a procedure to explicitly release used DLLs from APL?
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Re: Unloading DLLs loaded by []CSE 'LoadAssembly'

Postby Tech Support » December 19th, 2013, 5:52 pm

Davin Church wrote:Isn't that true of any DLL loaded by APL (or other application)? Do I (vaguely) remember that we used to have a procedure to explicitly release used DLLs from APL?


Not exactly. Since version 9.0, it has been possible to programmatically unload a multi-threaded DLL or Active control from
memory after use by ⎕wcall, ⎕na, or ⎕wi with the combination of the W_Reset and W_ResetUnload arguments to ⎕wcall.
However, they're not applicable to (C#) .NET assemblies (DLLs) exposed as COM. So it will be necessary to restart APL+Win.
Tech Support
 
Posts: 1230
Joined: February 10th, 2007, 7:33 am
Location: Rockville, MD

Re: Unloading DLLs loaded by []CSE 'LoadAssembly'

Postby Davin Church » December 19th, 2013, 6:03 pm

Not exactly. Since version 9.0, it has been possible to programmatically unload a multi-threaded DLL or Active control from
memory after use by ⎕wcall, ⎕na, or ⎕wi with the combination of the W_Reset and W_ResetUnload arguments to ⎕wcall.
However, they're not applicable to (C#) .NET assemblies (DLLs) exposed as COM. So it is necessary to restart APL+Win.

Ah - I think that's what I was remembering. Too bad it doesn't work on .NET.
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Re: Unloading DLLs loaded by []CSE 'LoadAssembly'

Postby brent hildebrand » December 19th, 2013, 8:12 pm

What if you load a .Net assembly in an APL session which itself is loaded as a COM object by another APL session? Will terminating the APL COM session and unloading it, cause the .Net assembly to be unloaded? APL <COM> APL <[]CSE .Net>
brent hildebrand
 
Posts: 538
Joined: February 12th, 2007, 5:53 pm
Location: Loma Linda, CA

Re: Unloading DLLs loaded by []CSE 'LoadAssembly'

Postby Gert.Glantz » December 20th, 2013, 4:24 am

Hi,

Thanks for the answers. One question. My assembly is not exposed as COM. I guess what you are talking about is that the []CSE assembly is exposed as COM. Am I right?

Regarding loading from another location other than VS output folders: Since []CSE has loaded the assembly it cannot be replaced by copying a new "VS" version to that other location unless APL is shut down. So loading from another location is not much of a help when you are developing on both platforms at the same time.

/Gert
Gert.Glantz
 
Posts: 16
Joined: November 2nd, 2007, 12:14 pm

Re: Unloading DLLs loaded by []CSE 'LoadAssembly'

Postby Tech Support » December 20th, 2013, 2:18 pm

brent hildebrand wrote:What if you load a .Net assembly in an APL session which itself is loaded as a COM object by another APL session? Will terminating the APL COM session and unloading it, cause the .Net assembly to be unloaded? APL <COM> APL <[]CSE .Net>

Terminating the APL COM session responsible for having loaded the .NET assembly will also unload the same .NET assembly.
Tech Support
 
Posts: 1230
Joined: February 10th, 2007, 7:33 am
Location: Rockville, MD

Re: Unloading DLLs loaded by []CSE 'LoadAssembly'

Postby Tech Support » December 20th, 2013, 3:48 pm

Gert.Glantz wrote:Thanks for the answers. One question. My assembly is not exposed as COM. I guess what you are talking about is that the []CSE assembly is exposed as COM. Am I right?

You are correct.
Tech Support
 
Posts: 1230
Joined: February 10th, 2007, 7:33 am
Location: Rockville, MD


Return to APL+Win & The C# Script Engine

Who is online

Users browsing this forum: No registered users and 20 guests

cron