It is possible to share data between AppDomains without the costs of Marshalling. But it is a rather hacky way. You can create a source data object which is shared by reference between all AppDomains. This way you get all data into one shared object without the costs of Marshalling. Sounds too easy to be … Read more
From the MSDN documentation of System.Reflection.Assembly.ReflectionOnlyLoad (String) : The reflection-only context is no different from other contexts. Assemblies that are loaded into the context can be unloaded only by unloading the application domain. So, I am afraid the only way to unload an assembly is unloading the application domain. To create a new AppDomain and … Read more
In IIS 6, go to the Application Pools section, and right-click > Properties on the pool which hosts the ASP.NET application in question. Go to the Performance tab and uncheck “Shutdown worker processes after being idle for:” In IIS 7, go to the Connections pane and find Application Pools, and select Advanced Settings for the … Read more
The single most important use is that your code has to have one – i.e. everything you write in C# executes in an AppDomain. That is quite important ;-p If you mean additional app-domains: When using plugins and other untrusted code, it allows you both isolation, and the ability to unload them (you can’t unload … Read more
If both assemblies are compatible you can define in the app.exe.config or web.config file to always use the new version by declaring bindingRedirect . example <configuration> <runtime> <assemblyBinding xmlns=”urn:schemas-microsoft-com:asm.v1″ appliesTo=”v1.0.3705″> <dependentAssembly> <assemblyIdentity name=”Regcode” publicKeyToken=”b03f5f7f11d50a3a” culture=””/> <bindingRedirect oldVersion=”0.0.0.0-65535.65535.65535.65535″ newVersion=”1.0.3300.0″/> </dependentAssembly> </assemblyBinding> </runtime> </configuration> this config entry for dotnet 1.0 tells the asembly loader always to use … Read more
For .net versions core 3.0 and later: You can now unload assemblies. Note that appdomains are no longer available in .net core. Instead, you can create one or more AssemblyLoadContext, load your assemblies via that context, then unload that context. See AssemblyLoadContext, or this tutorial that simulates loading a plugin then unloading it. For .net … Read more
More specifically AppDomain domain = AppDomain.CreateDomain(“New domain name”); //Do other things to the domain like set the security policy string pathToDll = @”C:\myDll.dll”; //Full path to dll you want to load Type t = typeof(TypeIWantToLoad); TypeIWantToLoad myObject = (TypeIWantToLoad)domain.CreateInstanceFromAndUnwrap(pathToDll, t.FullName); If all that goes properly (no exceptions thrown) you now have an instance of TypeIWantToLoad … Read more
This seemed to do the trick: var loadedAssemblies = AppDomain.CurrentDomain.GetAssemblies().ToList(); var loadedPaths = loadedAssemblies.Select(a => a.Location).ToArray(); var referencedPaths = Directory.GetFiles(AppDomain.CurrentDomain.BaseDirectory, “*.dll”); var toLoad = referencedPaths.Where(r => !loadedPaths.Contains(r, StringComparer.InvariantCultureIgnoreCase)).ToList(); toLoad.ForEach(path => loadedAssemblies.Add(AppDomain.CurrentDomain.Load(AssemblyName.GetAssemblyName(path)))); As Jon noted, the ideal solution would need to recurse into the dependencies for each of the loaded assemblies, but in my specific scenario … Read more
You need to invoke CreateInstanceAndUnwrap before your proxy object will execute in the foreign application domain. class Program { static void Main(string[] args) { AppDomainSetup domaininfo = new AppDomainSetup(); domaininfo.ApplicationBase = System.Environment.CurrentDirectory; Evidence adevidence = AppDomain.CurrentDomain.Evidence; AppDomain domain = AppDomain.CreateDomain(“MyDomain”, adevidence, domaininfo); Type type = typeof(Proxy); var value = (Proxy)domain.CreateInstanceAndUnwrap( type.Assembly.FullName, type.FullName); var assembly = … Read more