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 :...

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...