Announcing: NSandbox on Sourceforge
Have you ever needed to:
- Use a "plugin" architecture?
- Unload an assembly after using it?
- Execute arbitrary code with different security requirements in its own "sandbox"?
- Wanted to test multiple WCF services from the same process, but with different configuration files?
…then NSandbox is the utility library that you’ve always needed
NSandbox is a small library that I’ve thrown together that lets you create, manage, and unload any number of "sandboxes", or AppDomains. It abstracts away the standard .NET remoting infrastructure (MarshalByRefObject and friends), letting you easily invoke methods and subscribe to events on objects in other AppDomains.
Lately I’ve been using NSandbox to do quite a bit of WCF integration testing. Typically this would involve building, deploying, starting, debugging, and stopping a number of services, possibly on different machines. In a tight development loop this can be very cumbersome — sometimes I would spend more time deploying and starting/stopping the services than I would on development. In addition, I usually also had 4-5 instances of Visual Studio open at the same time in an attempt to set breakpoints in both client and server code.
I came up with a way that I could host all of my WCF services within the same process (only 1 Visual Studio debugger!) by separating each service into its own AppDomain. This is a natural match since each WCF service is (typically) configured by an App.config file, and each AppDomain can have its own configuration file specified. Granted, since everything is running in a single process a little more care must be given to the multithreading aspects, but in my experience using NSandbox has been an incredible productivity booster.
So, if you haven’t already, hop over to Sourceforge, download the MSI installer, and try out NSandbox. I’d love to hear any feedback that you have.
Included in NSandbox 0.1:
- bin\NSandbox.dll (reference this from your project)
- doc\NSandbox.chm (compiled documentation)
There are a few good example projects in the SVN code. In particular check out the NSandbox.Tests project. I’m working on incorporating the example code into the installer for the next version (hopefully soon). The examples are built into NUnit tests, though they are actually full-blown integration tests, not just unit tests of the service implementations.
I’ll be posting more about the integration testing soon
Enjoy!
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
October 11th, 2008 at 7:52 am
Sounds appealing! Is it only suited for testing? When you can control (restrict) the permissions of the sandbox, it can be very useful in production environments.
When you run your sandbox, can you supply an alternative config file? I’m working on a project (no, this time it’s not conditions
) where I’d like to test different app.config settings, without having to create many test projects. Is that possible?
October 11th, 2008 at 9:08 am
Hi Steven,
Yes, NSandbox will allow you to write a new App.config file for each new AppDomain (sandbox). Right now I have a “parameterized file” configuration writer that takes a template file and then lets you globally replace “variables” in the format “$variableName$” with different strings before writing the App.config file to disk. Of course, this is just one implementation of IConfigurationWriter and you can make your own.
As for the permissions, right now it’s hard-coded as “full trust” but it won’t be difficult to change this in future versions
This test outlines all of those features:
http://nsandbox.svn.sourceforge.net/viewvc/nsandbox/trunk/NSandbox.Tests/SandboxTest1.cs?revision=12&view=markup
I’ll post some examples soon
-Matt
October 11th, 2008 at 12:32 pm
Thanks Matt.
It would be cool if there was a IConfigurationWriter in the library that you can point at a complete custom config file. The project I’m working on adds a section to the config file.
October 13th, 2008 at 2:35 pm
[...] Announcing: NSandbox on Sourceforge [...]
October 14th, 2008 at 3:32 pm
Matt,
I think you’ve answered my question in your new post. I see now that pointing at a complete config file is no problem for NSandbox! Great stuff.