appdomain

My goal is to create an executable that will start a shadow copied application. The trick is, I want this starter program to have no external dependencies and not have to contain any knowledge about the program it has to start. I also want it to be the only executable in the directory. In other words, I want it to "run" a .dll assembly not an .exe assembly. (I can require that the name of the .dll file being loaded into a new AppDomain be the same everytime, like Main.dll or something like that.) It looked like AppDomain.ExecuteAssembly would do exactly what I wanted. It says it will start

Is it possible to run an IronPython interpreter inside my .Net application, but inside a sandbox? I want to deny the IP script access to the filesystem while still allowing the app itself access. Would this involve running the scripting engine in a second AppDomain? How would I handcuff it so it can't do whatever it pleases? Here's an article explaining how to create an AppDomain and execute code in a sandbox . Just create the AppDomain and handcuff the code that runs inside it. 来源： https://stackoverflow.com/questions/4393153/sandbox-ironpython

I have a library that I use that uses WCF to call an http service to get settings. Normally the first call takes ~100 milliseconds and subsequent calls takes only a few milliseconds. But I have found that when I create a new AppDomain the first WCF call from that AppDomain takes over 2.5 seconds. Does anyone have an explanation or fix for why the first creation of a WCF channel in a new AppDomain would take so long? These are the benchmark results(When running without debugger attached in release in 64bit), notice how in the second set of numbers the first connections takes over 25x longer

I'd like to use an object across AppDomains. For this I can use the [Serializeable] attribute: [Serializable] class MyClass { public string GetSomeString() { return "someString" } } Or subclass from MarshalByRefObject: class MyClass: MarshalByRefObject { public string GetSomeString() { return "someString" } } In both cases I can use the class like this: AppDomain appDomain = AppDomain.CreateDomain("AppDomain"); MyClass myObject = (MyClass)appDomain.CreateInstanceAndUnwrap( typeof(MyClass).Assembly.FullName, typeof(MyClass).FullName); Console.WriteLine(myObject.GetSomeString()); Why do both

Background I have a Windows service that uses various third-party DLLs to perform work on PDF files. These operations can use quite a bit of system resources, and occasionally seem to suffer from memory leaks when errors occur. The DLLs are managed wrappers around other unmanaged DLLs. Current Solution I'm already mitigating this issue in one case by wrapping a call to one of the DLLs in a dedicated console app and calling that app via Process.Start(). If the operation fails and there are memory leaks or unreleased file handles, it doesn't really matter. The process will end and the OS will

I want to create an application domain with default permissions and load assembly into the application domain with default privileges and execute the methods inside the assembly. You may take a look at the following article on MSDN. Or if you want to construct an instance of some type inside another AppDomain (assuming this type has a default constructor): var domain = AppDomain.CreateDomain("NewAppDomain"); var path = @"C:\work\SomeAssembly.dll"; var t = typeof(SomeType); var instance = (SomeType)domain.CreateInstanceFromAndUnwrap(path, t.FullName); The instance variable returned with this

My aim is to make a missing dependency check between 2 given folders. Imagine the following setup. Root\DirA\A.dll Root\DirB\B.dll B depends on A. So given these folders, I want to create a new AppDomain, load B.dll and have the dependency from DirA(A.dll) automatically resolved and isolated in that new AppDomain. Isolation is key here given that when I unload this AppDomain I want to create a new one with potentially DirA as a dependency again but DirC libraries that require it so in the case that DirC has a dependency on DirB as well I want it to throw an exception. Edit: Adding a code

Since dynamic assembly loading requires appdomain loading to enable killing the assembly with unloading related appdomain, is there a "max" number appdomains in a process to be loaded? I am thinking of a server based application that each user can run his proprietary C# code dynamically. But what if, say, 2000 users log in and load their codes? Are there any possible restrictions I might encounter besides the number of appdomians? thanks. Almost all CLR limits are based on "as memory permits". The only exception I know of is the number of members of a class, restricted to 65536. That's based

I'm fairly new to reflection and I was wonder what I would use a (second) AppDomain for? What practical application would one have in a business application? There are numerous uses. An secondary AppDomain can provide a degree of isolation that is similar to the isolation an OS provides processes. One practical use that I've used it for is dynamically loading "plug-in" DLLs. I wanted to support scanning a directory for DLLs at startup of the main executable, loading them and checking their types to see if any implemented a specific interface (i.e. the contract of the plug-in). Without creating