Avatar of dungla
dungla
Flag 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.
C#

Avatar of undefined
Last Comment
dungla

8/22/2022 - Mon
ptmcomp

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

ASKER
ptmcomp, what did you mean?

So how can I do this task?
ASKER CERTIFIED SOLUTION
ptmcomp

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
GET A PERSONALIZED SOLUTION
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.
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?
This is the best money I have ever spent. I cannot not tell you how many times these folks have saved my bacon. I learn so much from the contributors.
rwheeler23
ptmcomp

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?
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
ptmcomp

Do you also delete the shadow copy?
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
dungla

ASKER
Yes I do, and thank again for your help