Development with a Dot

Introduction I recently posted about my projects  Isolator and ReferencesScanner , which allow us, respectively, to run .NET code in isolation and to list all of an assembly's references. Now, I'm going to present a change to  Isolator  that allows checking for a plugin's references with white and black lists. Any references on the white list will be allowed, and any on the black list will be denied. Using Isolator with References Scanning There is a new class, ScannedIsolationHost , which features four new properties: public HashSet<Type> SafeTypes { get; } public HashSet<Assembly> SafeAssemblies { get; } public HashSet<Type> UnsafeTypes { get; } public HashSet<Assembly> UnsafeAssemblies { get; } So, we have new properties: SafeTypes : list of Type references that are safe to use SafeAssemblies : list of Assembly references that are safe to use UnsafeTypes : list of  Type  references that are unsafe to use UnsafeAssemblies :...

Introduction The purpose of Isolator , my framework for running isolated (sandboxed) code is to be able to, well, run code (known as plugins) on distributed, isolated instances (hosts). I initially created two isolation hosts: Process ( ProcessIsolationHost ): a new process is created to host and run the plugin Assembly Load Context ( AssemblyLoadContextIsolationHost ): a new assembly and assembly load context are created to host and run the plugin Now I'm introducing a new one, that allows to execute code on another machine:  ClientIsolationHost . I'll show you how to use it now. Client Host Isolation The idea is to be able to run code on a different machine, while keeping the same capabilities: We pass an existing plugin instance to the host which is then handled transparently Modified context properties are returned from the host to the caller Standard output and error are also returned The result value from the plugin's execution is returned...

Update: see my other post on distributed Isolator and on refereces scanning . Introduction Code isolation, also known as sandboxes, are an important topic in any enterprise-level programming language: the means the ability to run code in a secure way that does not affect the main program. This used to be relatively easy to achieve with the .NET Framework, but it is no longer so, since .NET Core was introduced. I will talk a bit about it and how we can implement something similar. Code Isolation in .NET Custom app domains are gone from .NET since .NET Core. Officially they were removed because they were heavy and hard to maintain. There is still the AppDomain  class and we always have a current app domain, which can be accessed from AppDomain.CurrentDomain , but the AppDomain.CreateDomain method now returns an exception on all platforms. App domains were great, from a programatic point of view, because they allowed us to create new ones with custom permissions, which could then b...