Link to home
Start Free TrialLog in
Avatar of dungla
dunglaFlag for Viet Nam

asked on

Load assembly to another domain in COM+ application

Hi all,

Few day ago, I have a question about how to load assembly to another application domain. Now I met another issue.

My main application is running in COM+. Right now, already succeed to load dynamic compiled assembly to new application domain create within COM+ session. But the problem is: When I unload the domain and wish to delete the loaded assembly, but I can't.

(1) In the normal application (not COM+), I have succeed to compiled a C# file in runtime to assembly, then create new app domain -> load compiled assembly to new domain -> invoke method -> unload domain -> delete compiled assembly -> successfully.

(2) In COM+ application, I have succeed to compiled a C# file in runtime to assembly, then create new app domain -> load compiled assembly to new domain -> invoke method -> unload domain -> but cannot delete compiled assembly -> exception: the file was used by another process.

When running in debug mode, I've found the main difference is:
In (1) C# file store in D:\test.cs -> compile to test.dll assembly -> test.dll stored in D:\test.dll (same directory with C# file).

In (2) C# file store in D:\test.cs -> main application place in D:\MainApp -> compile to test.dll assembly -> test.dll stored in D:\MainApp\bin\Debug\test.dll and do not appear same as (1) D:\test.dll.

I think this is the reason why I cannot delete the assembly file.

Anyone please help me.
Avatar of ptmcomp
ptmcomp
Flag of Switzerland image

In COM+ you need to deal with signed assemblies. By default a signed assembly cannot reference any not signed assembly.
Avatar of dungla

ASKER

ptmcomp, what did you mean?

So how can I do this task?
ASKER CERTIFIED SOLUTION
Avatar of ptmcomp
ptmcomp
Flag of Switzerland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of dungla

ASKER

set the CachePath of AppDomainSetup is mean the application will load assembly into the CachePath right? Did you mean when I first compile my C# file (D:\test.cs) and return an assembly named test.dll into D:\MyApp\bin\Debug\test.dll. After that, create new AppDomain with CachePath set to (just for example) C:\SecondaryAppDomainCachePath. When creating remote loader object within new AppDomain, process will copy the test.dll from D:\MyApp\bin\Debug\test.dll to C:\SecondaryAppDomainCachePath\test.dll and then all execution will doing with C:\SecondaryAppDomainCachePath\test.dll right?
Yes, you're right. But first I would check why the assembly is still loaded and by what process. Is the debugger loading it and fooling you?
Avatar of dungla

ASKER

ptmcomp,

I've got it :-), very simple. Before compile the C# file, set GenerateInMemory property of CompilerParameters to true, it will use the assembly in memory (not use in physical folder). Set AppDomainSetup.ShadowCopyFiles to "true". After that, compile the file and load to new AppDomain. Execute, then unload AppDomain, i'm able to delete the dll file.

CompilerParameters.GenerateInMemory = true;
CompilerParameters.OutputAssembly = "test.dll"

AppDomainSetup setup = new AppDomainSetup();
setup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory
setup.ShadowCopyFiles = "true";

AppDomain domain = AppDomain.CreateDomain("SecondDomain", null, setup);

// load assembly and execute

// unload domain
AppDomain.Unload(domain);
domain = null;
File.Delete (CompilerParameters.OutputAssembly); // successful

Thank for your help
Do you also delete the shadow copy?
Avatar of dungla

ASKER

Yes I do, and thank again for your help