SharePoint Sandboxed solutions allow site administrators to deploy custom web parts without physical (console) access to the SharePoint server. Sandboxed solutions are easily uploaded via Solutions gallery.

Sometimes, while developing a solution, you want to know if your code is running sandboxed or as a normal farm solution. In order to check if the code is running sandboxed or not, you can use the approaches suggested to me by Wictor Wilen and Chris O’Brien.

I recently installed Visual Studio 2010 SharePoint Power Tools (I highly recommended you to install these too). This pack introduces a new ability to check if a sandboxed solution contains any code which will not be able to run sandboxed on a SharePoint farm. (Check this article for more details on SharePoint sandboxed solutions restrictions).

The ability to check if you are using any prohibited namespaces or functions at compilation time ensures that you do not deploy a sandboxed solution that will not work as advertised. However, in case you want to package both Sandboxed and Farm solutions from the same (or similar) code base, there is a simple trick, and this article explains how to it. The typical scenario for something like this is when you have a web part that works as Sandboxed solution but in case your code is deployed as Farm solution you want to use some additional functionalities that are not available while running in a Sandbox. In my case I created Search AutoComplete for SharePoint 2010 Central Administration Web Part, by default it works as Sandboxed Solution but it can only list Service Apps links if deployed as Farm solution.

Here is what you need to do in order to compile both solutions from the same code base:

• Create two new build configurations for your project Debug-Sandbox and Release-Sandbox
  
• Define new Conditional Compilation Symbols: DebugSandbox for Debug-Sandbox configuration and ReleaseSandbox for Release-Sandbox configuration
  
• Open your project file (csproj or vbproj extension) in Notepad
• Locate Project Group tags and make sure you have 4 project groups and SandboxedSolution node in each Project Group node. This node determines if solution is going to be complied as sandboxed or farm solution. Set the value to TRUE for your sandboxed build configurations and FALSE for Debug and Release. (As shown on picture below)
  

To separate your code preprocessor directive needs to be used, as in this example:

protected override void Render(HtmlTextWriter writer)
        {

#if DebugSandbox || ReleaseSandbox
            //This code block will compile if sandboxed build configuration (Debug-SandBox or Release-Sandbox) is chosen
           writer.Write("Hello world, I am a sandboxed web part!<br/>");
           writer.Write("This web part is sandboxed solution and cannot retrieve total number of sandboxed solutions.");
#else
            //This code block will compile if non sandboxed build configuration is chosen
           writer.Write("Hello world, I am NOT a sandboxed web part!<br/>");

            SPUserSolutionCollection solutions = SPContext.Current.Site.Solutions;
            writer.Write(string.Format("There is a total of <b>{0}</b> sandboxed solutions installed in this site collection!<br/><br/>", solutions.Count));

            if (solutions.Count > 0)
            {
                writer.Write("These are the installed solutions:<br/><ul>");
                foreach (SPUserSolution solution in solutions)
                {
                    writer.Write(string.Format("<li>{0}</li>", solution.Name));
                }
                writer.Write("</ul>");
            }
#endif

            base.Render(writer);

        }

When you compile this example as a farm solution it will display the list of installed sandboxed solutions. When compiled as sandboxed solutions it will display a message text only.

Conclusion

This technique might come handy when you have two web parts that have only few differences and you do not want to maintain a separate code base just for that. The down side of this approach is that you cannot have both build configurations deployed to the same site collection at the same time because both share the same feature id.