Develop Reference

How to dynamically load and unload (reload) a .dll assembly

I'm developing a module for an external application, which is a dll that is loaded.
However in order to develop, you have to restart the application to see the results of your code.
We have built a piece of code that loads a dll dynamically from a startassembly:
startassembly
var dllfile = findHighestAssembly(); // this works but omitted for clarity
Assembly asm = Assembly.LoadFrom(dllFile);
Type type = asm.GetType("Test.Program");
MethodInfo methodInfo = type.GetMethod("Run");
object[] parametersArray = new object[] { };
var result = methodInfo.Invoke(methodInfo, parametersArray);
Effectively we have a solution with a startassembly which will be static and a test assembly which will be invoked dynamically, which allows us to swap the assembly during runtime.
The problem
This piece of code will load a new dll every time and search for the highest version at the end of the assembly name. e.g. test02.dll will be loaded instead of test01.dll, because the application locks both startassemly.dll as well as test01.dll. Now we have to edit the properties > assembly name all the time.
I want to build a new dll while the main application still runs. However for now I get the message
The process cannot access the file test.dll because it is being used
by another process
I have read that you can unload a .dll using AppDomains however the problem is that I don't know how to properly unload an AppDomain and where to do this.
The goal is to have to reload the new test.dll everytime the window is re-opened (by a button click from the main application).

You cannot unload a single assembly, but you can unload an Appdomain. This means you need to create an app domain and load the assembly in the App domain.
Exmaple:
var appDomain = AppDomain.CreateDomain("MyAppDomain", null, new AppDomainSetup
{
ApplicationName = "MyAppDomain",
ShadowCopyFiles = "true",
PrivateBinPath = "MyAppDomainBin",
});
ShadowCopyFiles property will cause the .NET runtime to copy dlls in "MyAppDomainBin" folder to a cache location so as not to lock the files in that path. Instead the cached files are locked. For more information refer to article about Shadow Copying Assemblies
Now let's say you have an class you want to use in the assembly you want to unload. In your main app domain you call CreateInstanceAndUnwrap to get an instance of the object
_appDomain.CreateInstanceAndUnwrap("MyAssemblyName", "MyNameSpace.MyClass");
However, and this is very important, "Unwrap" part of CreateInstanceAndUnwrap will cause the assembly to be loaded in your main app domain if your class does not inherit from MarshalByRefObject. So basically you achieved nothing by creating an app domain.
To solve this problem, create a 3rd Assembly containing an Interface that is implemented by your class.
For example:
public interface IMyInterface
{
void DoSomething();
}
Then add reference to the assembly containing the interface in both your main application and your dynamically loaded assembly project. And have your class implement the interface, and inherit from MarshalByRefObject. Example:
public class MyClass : MarshalByRefObject, IMyInterface
{
public void DoSomething()
{
Console.WriteLine("Doing something.");
}
}
And to get a reference to your object:
var myObj = (IMyInterface)_appDomain.CreateInstanceAndUnwrap("MyAssemblyName", "MyNameSpace.MyClass");
Now you can call methods on your object, and .NET Runtime will use Remoting to forward the call to the other domain. It will use Serialization to serialize the parameters and return values to and from both domains. So make sure your classes used in parameters and return values are marked with [Serializable] Attribute. Or they can inherit from MarshalByRefObject in which case the you are passing a reference cross domains.
To have your application monitor changes to the folder, you can setup a FileSystemWatcher to monitor changes to the folder "MyAppDomainBin"
var watcher = new FileSystemWatcher(Path.GetFullPath(Path.Combine(".", "MyAppDomainBin")))
{
NotifyFilter = NotifyFilters.LastWrite,
};
watcher.EnableRaisingEvents = true;
watcher.Changed += Folder_Changed;
And in the Folder_Changed handler unload the appdomain and reload it again
private static async void Watcher_Changed(object sender, FileSystemEventArgs e)
{
Console.WriteLine("Folder changed");
AppDomain.Unload(_appDomain);
_appDomain = AppDomain.CreateDomain("MyAppDomain", null, new AppDomainSetup
{
ApplicationName = "MyAppDomain",
ShadowCopyFiles = "true",
PrivateBinPath = "MyAppDomainBin",
});
}
Then when you replace your DLL, in "MyAppDomainBin" folder, your application domain will be unloaded, and a new one will be created. Your old object references will be invalid (since they reference objects in an unloaded app domain), and you will need to create new ones.
A final note: AppDomains and .NET Remoting are not supported in .NET Core or future versions of .NET (.NET 5+). In those version, separation is achieved by creating separate processes instead of app domains. And using some sort of messaging library to communicate between processes.

Not the way forward in .NET Core 3 and .NET 5+
Some of the answers here assume working with .NET Framework. In .NET Core 3 and .NET 5+, the correct way to load assemblies (with ability to unload them) in the same process is with AssemblyLoadContext. Using AppDomain as a way to isolate assemblies is strictly for .NET Framework.
.NET Core 3 and 5+, give you two possible ways to load dynamic assemblies (and potentially unload):
Load another process and load your dynamic assemblies there. Then use an IPC messaging system of your choosing to send messages between the processes.
Use AssemblyLoadContext to load them in the same process. Note that the scope does NOT provide any kind of security isolation or boundaries within the process. In other words, code loaded in a separate context is still able to invoke other code in other contexts within the same process. If you want to isolate the code because you expect to be loading assemblies that you can't fully trust, then you need to load it in a completely separate process and rely on IPC.
An article explaining AssemblyLoadContext is here.
Plugin unloadability discussed here.
Many people who want to dynamically load DLLs are interested in the Plugin pattern. The MSDN actually covers this particular implementation here:
https://learn.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support
2021-9-12 UPDATE
Off-the-Shelf Library for Plugins
I use the following library for plugin loading. It has worked extremely well for me:
https://github.com/natemcmaster/DotNetCorePlugins

what you're trying to do in the code you posted is unload the default app domain which your program will run in if another isn't specified. What you're probably wanting is to load a new app domain, load the assembly into that new app domain, and then unloaded the new app domain when the user destroys the page.
https://learn.microsoft.com/en-us/dotnet/api/system.appdomain?view=netframework-4.7
the reference page above should give you a working example of all of this.

Here is an example for loading and unloading an AppDomain.
In my example I have 2 Dll's: DynDll.dll and DynDll1.dll.
Both Dll's have the same class DynDll.Class and a method Run (MarshalByRefObject is required):
public class Class : MarshalByRefObject
{
public int Run()
{
return 1; //DynDll1 return 2
}
}
Now you can create a dynamic AppDomain and load a Assembly:
AppDomain loDynamicDomain = null;
try
{
//FullPath to the Assembly
string lsAssemblyPath = string.Empty;
if (this.mbLoad1)
lsAssemblyPath = Path.Combine(Application.StartupPath, "DynDll1.dll");
else
lsAssemblyPath = Path.Combine(Application.StartupPath, "DynDll.dll");
this.mbLoad1 = !this.mbLoad1;
//Create a new Domain
loDynamicDomain = AppDomain.CreateDomain("DynamicDomain");
//Load an Assembly and create an instance DynDll.Class
//CreateInstanceFromAndUnwrap needs the FullPath to your Assembly
object loDynClass = loDynamicDomain.CreateInstanceFromAndUnwrap(lsAssemblyPath, "DynDll.Class");
//Methode Info Run
MethodInfo loMethodInfo = loDynClass.GetType().GetMethod("Run");
//Call Run from the instance
int lnNumber = (int)loMethodInfo.Invoke(loDynClass, new object[] { });
Console.WriteLine(lnNumber.ToString());
}
finally
{
if (loDynamicDomain != null)
AppDomain.Unload(loDynamicDomain);
}

Here is an idea, instead of loading the DDL directly (as is), let the application rename it, then load the renamed ddl (e.g. test01_active.dll). Then, just check for the original file (test01.dll) before loading the assembly and if exists, just delete the current one(test01_active.dll) and then rename the updated version then reload it, and so on.
Here is a code shows the idea :
const string assemblyDirectoryPath = "C:\\bin";
const string assemblyFileNameSuffix = "_active";
var assemblyCurrentFileName = "test01_active.dll";
var assemblyOriginalFileName = "test01.dll";
var originalFilePath = Path.Combine(assemblyDirectoryPath, assemblyOriginalFileName);
var currentFilePath = Path.Combine(assemblyDirectoryPath, assemblyCurrentFileName);
if(File.Exists(originalFilePath))
{
File.Delete(currentFilePath);
File.Move(originalFilePath, currentFilePath);
}
Assembly asm = Assembly.LoadFrom(currentFilePath);
Type type = asm.GetType("Test.Program");
MethodInfo methodInfo = type.GetMethod("Run");
object[] parametersArray = new object[] { };
var result = methodInfo.Invoke(methodInfo, parametersArray);

"Member 'HttpClient' is declared in another module and needs to be imported" in Mono.Cecil / Fody

and thanks for giving me your time.
Background
I'm trying to create a new HttpClient in Mono.Cecil, and to add it to a field.
Here's my code:
TypeDefinition HttpClientDef = ModuleDefinition.GetType(typeof(HttpClient)).Resolve();
TypeDefinition def = GetSomeTypeDefinitionFromModule();
FieldDefinition field = new FieldDefinition($"${GENERATED_CLIENT_PATH}", FieldAttributes.Private, HttpClientDef);
def.Fields.Add(field);
No problem here, but once void Execute() has returned, an exception is thrown: Member 'System.Net.Http.HttpClient' is declared in another module and needs to be imported.
So what?
I cannot import HttpClient. I've tried many things, and here's what I know:
ModuleDefinition doesn't have a definition for System.Uri or System.Net.Http.HttpClient, for example.
I can, however, get a reference to HttpClient by doing:
AssemblyDefinition httpAssembly = AssemblyResolver.Resolve("System.Net.Http");
TypeDefinition HttpClientDef = httpAssembly.MainModule.GetType(typeof(HttpClient)); // fyi, HttpClient is also in httpAssembly.GetTypes().
Once I have a valid TypeDefinition, I have no idea what to do with it.
ModuleDefinition.Import(def).Resolve() does not change anything ;
new TypeReference(namespace, name, ModuleDefinition, httpAssembly.Name) doesn't work either ;
Neither does calling def directly.
Any idea?
Thank you,
Greg.
Edit 1
Turns out you can't import a type if its reference (in this case System.Net.Http) isn't used in the code.
Now, I can load it using TypeDefinition def = ModuleDefinition.GetType(typeof(HttpClient)).

Creating a new FieldDefinition requires only a TypeReference not a TypeDefinition, so there is no need to call Resolve(). Try this:
FieldDefinition field =
new FieldDefinition($"${GENERATED_CLIENT_PATH}",
FieldAttributes.Private,
moduleDefn.Import(typeof(HttpClient));

For some reason, System and System.Net.Http weren't referenced, even though I had added 'em as references. Explicitly using HttpClient once in my (modified) code forced the reference to exist, and I was able to Import it after that.

How to debug appdomain return values in VS

my c# programm is using multiple appdomains to load/unload assemblies.
My assemblies in the 2nd appdomain are returning an object which inherits MarshalByRefObject.
My Problem now is that Visual Studio tells me that it can't Show information about it.
Obtaining the runtime type of a transparent proxy is not supported in this context.
I can see information about this object when I'm in a class of the 2nd appdomain.
My question now: is it somehow possible to tell Visual Studio to Show me information about this object in 1. appdomain?
Edit:
I found a solution but this is just a Workaround.
I serialize and deserialize the object from/to json to get a clean copy.
var info = Proxy.GetAssemblyInfo(assemblyPath, typeof(IMyAssembly));
#if DEBUG //just to have a debuggable object
var jsonSerializer = new JavaScriptSerializer();
var json = jsonSerializer.Serialize(info);
info = jsonSerializer.Deserialize<AppDomainAssemblyInfo>(json);
#endif
reutrn info;
but if there is a nicer solution please let me know :)
Edit 2:
Some Code to explain it in detail:
var secondAppDomain = CreateAppDomain();
AppDomainLoaderProxy proxy = appDomain.CreateInstanceAndUnwrap(typeof(AppDomainLoaderProxy).Assembly.FullName, typeof(AppDomainLoaderProxy).FullName) as AppDomainLoaderProxy;
var myReturnValue = proxy.getSomeInformation();
//myReturnValue is not debuggable. When I add this to watch-list, VS tells me:
//Obtaining the runtime type of a transparent proxy is not supported in this context.

ComposeParts method not working

I've got an ITagger and an IWpfTextViewMargin, both are exported as MEF components. I want to import the ITagger in my Margin code, and then use some members in that Tagger.
Now I tried to use ComponentContainer in the Margin class, then import the IViewTaggerProvider. I used the following code, which can be found in many MEF tutorials
[Import(typeof(IViewTaggerProvider))]
public IViewTaggerProvider vt_provider { get; set; }
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new AssemblyCatalog(typeof(TestMargin).Assembly));
_container = new CompositionContainer(catalog);
//Fill the imports of this object
try
{
this._container.ComposeParts(this);
}
catch (CompositionException compositionException)
{
System.Diagnostics.Trace.WriteLine(compositionException.Message);
}
and the export code.
[Export(typeof(IViewTaggerProvider))]
[ContentType...
The exported class is defined in another namespace but same assembly.
Here I got problem that ComposeParts(this) throws ImportCardinalityMismatchException. I don't know why the parameter is this. I tried to pass the catalog to it, there is no exception but the import is also null. I also referred to debug mef failures and believe that the exported class has the right contract name and export type identity.
After checking the assembly with Visual MEFx and debugging, I found that probably it's because the IViewTaggerProvider imports a Visual Studio IClassificationTypeRegistryService, which is also an MEF part and results in a rejection of the IViewTaggerProvider.
[Primary Rejection]
[Exception] System.ComponentModel.Composition.ImportCardinalityMismatchException: No valid exports were found that match the constraint '((exportDefinition.ContractName == "Microsoft.VisualStudio.Text.Classification.IClassificationTypeRegistryService") AndAlso (exportDefinition.Metadata.ContainsKey("ExportTypeIdentity") AndAlso "Microsoft.VisualStudio.Text.Classification.IClassificationTypeRegistryService".Equals(exportDefinition.Metadata.get_Item("ExportTypeIdentity"))))', invalid exports may have been rejected.
So one solution is to add the assembly that exports IClassificationTypeRegistryService. It's a Visual Studio core editor service but I cannot find which assembly exports it. Anyone knows this?
Or any better possible solutions?

Try VisualMEFx. Here is a short blog entry about getting started https://ihadthisideaonce.com/2012/02/22/getting-started-with-visual-mefx/. Once you have it up and running, use VisualMEFx to load the TestMargin assembly and see if any IViewTaggerProvider is exported from that assembly.
Also remember that ImportCardinalityMistmatch doesn't only mean that an export is missing. It can also mean that there are too many exports available that can satisfy the import and MEF has no way of choosing which one to use. So when you are examining your composition in VisualMEFx, check to see if there are too many.
This parameter:
void Bootstrap()
{
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new AssemblyCatalog(typeof(TestMargin).Assembly));
_container = new CompositionContainer(catalog);
//Fill the imports of this object
try
{
var objectToSatisfy = this;
// var objectToSatifsy = new SomeOtherObjectWithImports();
this._container.ComposeParts(objectToSatisfy);
}
catch (CompositionException compositionException)
{
System.Diagnostics.Trace.WriteLine(compositionException.Message);
}
}
When you call ComposeParts you pass an object to the method. MEF will take the object that you pass and see if there are any imports on it that need to be satisfied. If it finds any imports, it will look in the catalog and try to satisfy them. You can pass any object you want to the ComposeParts method. So I've modified your sample code a little to show two different options. One option is to create some object that needs to be satisfied, and then give it to the container for composition. This is what I have done in the commented out line var objectToSatisfy = new SomeOtherObjectWithImports(). But it is often the case that the object we want to compose is the same object that's calling ComposeParts. So we don't need to create a new object to pass to the container, we already have the object, we just need a reference to it. In C# we can get a reference to the current object instance using the keyword this (in VB.NET the keyword is Me). So, when we want to satisfy imports on the same object that is calling ComposeParts, we can do so by using the this reference as the argument to ComposeParts.
The argument to the ComposeParts method is a parameter array. Informally, this just means that when you write container.ComposeParts(this) it is interpreted as if you had written container.ComposeParts(new object[] { this }). In practice this means you can pass multiple objects to MEF at once, like this:
container.ComposeParts(this, objectToSatifsy, thirdObjectToCompose);
If the object calling ComposeParts has no imports on it, then you should not be using this as the argument. Instead, create an object of the type that you want to compose and pass that to the method. Also, unless all the parts that you want to compose are available in the TestMargin assembly, you need to create more AssemlbyCatalogs for the assemblies that do provide the parts and add them to your AggregateCatalog.

Using COM object in C#

I'm trying to use TrustCommerce in my website. I installed dll files from the website, but I can't use it' I'm supposed to be able to use myObject.PushParam(string) and it's not working. Is there something I'm missing here? I found an article about it in PHP:
public static void TrustCommerce()
{
//TCLinkNET.TClinkClass.
object myObject = Orders.COMCreateObject("TCLINKCOMLib.TClinkClass");
}
public static object COMCreateObject(string sProgID)
{
// We get the type using just the ProgID
Type oType = Type.GetTypeFromProgID(sProgID);
if (oType != null)
{
return Activator.CreateInstance(oType);
}
return null;
}

add COM reference to your project, then an introp assembly will be generated for the COM. the way you are using requires reflection to invoke COM methods. 3.5 or less, do not forget to distribute the interop assembly with your application installer.