Even though there are a number of sandboxing technologies that are becoming increasingly popular due to ease of deployment (like Docker), it can still be desirable to construct a sandbox within an existing architecture, especially if you’re hoping to meet some strict guidelines (like SOX). If you’ve ever dealt with C#, then you might already be familiar with Microsoft’s sandbox solution: Application Domains. By creating and running code within an Application Domain, you can create a tailored environment for your classes. For example, you could configure the permissions of an App Domain so that any running code could have access to a local filesystem but would have no ability to download from the Internet. In theory, this toolset can be a wonderful bounty for any software architect, and in some cases, this promise can actually be fulfilled with relative ease. If you’ve already compiled and strongly signed an assembly of your own creation, the Application Domain can serve as a desired sandbox without much investment on the part of the developer. However, in some cases, you might be biting off more than you’ll wish to chew. Take dynamic compilation, for example. If you have any part of an architecture that JIT compiles and deploys C# code, there’s probably a strong interest in sandboxing. In this case, though, Application Domains and the .NET platform become a bit more tricky, especially due to permissions and due to the fact that dynamic compilation creates temporary files. Even though it’s certainly possible to achieve success in such a scenario, I can vouch for the high threshold of pain that one must possess in order to eventually arrive on the mountain top. So, unless dynamic compilation is completely necessary within your legacy system, you might want to forego that route and simply use Application Domains with DLL injection instead. Otherwise, you might be tearing all of your hair out…and in my case, I simply can’t afford to lose any more.