Glimpse works great with .Net 4.0 but I started thinking about using it with SharePoint 2010 and also creating a plugin that displays SharePoint specific information that could be useful in debugging a custom SharePoint application.

My First port of call was to download the Glimpse source code and try to back port the core module to .Net 3.5. When I had this working I plugged it into a SharePoint site and made some configuration entries and had Glimpse up and running with SharePoint.

I have now created the beginnings of a SharePoint plugin that I will be working on and I wanted to get some feedback on what information would be useful for people to see in the SharePoint tab. Please feel free to leave some suggestions here or drop me an email.

Here is a screenshot showing Glimpse working with SharePoint (.Net 3.5) and the beginnings of a SharePoint plugin.

So what is a Sandboxed solution?

The Sandboxed solution feature in SharePoint 2010 gives another execution model that isolates the solution at site collection level and allows deployment of the solution to be handled by the site collection administrator. This takes the burden of managing these solutions off the IT team and can be managed through the site collection UI instead of central admin.

Isolation.

Most IT teams wouldn’t be happy with allowing end users to deploy custom code to their nice shiny server farm so sandbox solutions have a few restrictions that give the IT team some comfort. Firstly the sandboxed code is run in an isolated process that is run under the identity of a low privilege account. Secondly the code is subject to a special default user code CAS policy that can be located in the 14/CONFIG folder. This CAS policy defines exactly what code the sandboxed code can all out to.

When a request comes into IIS a component called the Execution Manager handles the request. The execution manager runs in the same application pool as the web application that received the request. The execution manager then routes the call to the SharePoint User Code Service (SPUCHostService.exe). The user code service can be running on the same server or can be load balanced across multiple servers for increased scalability.

The user code service will then create a new sandbox worker process (SPUCWorkerProcess.exe) or route the request to an existing worker process, this is where your custom code will actually run.

As you can see your code is isolated into the user code service so it can’t bring the web application down if something manages to crash the user code service.

Calling the SharePoint object model.

The CAS policy associated with the sandbox worker process defines which part of the SharePoint API the user code can access (specifically a subset of the Microsoft.SharePoint namespace), when you call into this subset of the SharePoint API, the sandbox worker process calls into a proxy process (SPUCWorkerProcessProxy.exe) which is a full trust environment that actually executes the SharePoint API code.

This worker process is governed by the web.config file located in the 14/UserCode folder, this sets the CAS policies and the trust level of the execution environment for all sandbox solutions.

If you attempt to use a method that is not available to sandbox solutions you will receive a MissingMethod exeption at runtime.

Execution identity

The sandbox worker process executes under a configured low level account and this cannot be changed at runtime within your sandbox code, this mean no SPSecurity.RunWithElevatedPrivileges.

In fact you cannot access the security token of the user executing the code at all but you can get an instance of the SPUser object that represents the user executing the code within the SharePoint context.

Site collection boundaries

Sandbox solutions are deployed to a site collection and are stored in the site collection solution gallery (_catalog/solutions). As a result sandbox solutions cannot access anything outside the hosting site collection.

File system restrictions.

Sandbox solutions do not have access to the file system so you cannot deploy any code into the SharePoint root such as User Controls or application pages. Also bear in mind when a file is deployed using a sandboxed solution and the type attribute is set to Ghostable or GhostableInLibrary then the file is still deployed but it is never deployed to the file system. Instead SharePoint will put the file straight into the content database and the file will always be served from the database.

Monitoring

Sandbox solutions are monitored by SharePoint itself and IT teams can configure through Central Administration the boundaries in which sandbox solutions can execute. If a sandbox solution hits any of the limits imposed then SharePoint will automatically terminate the sandbox process. There is a lot more to sandbox solution monitoring but I’ll try to cover this in another blog post.

So how do I deploy my solution as a sandboxed solution?

So if we take the solution we had from parts 1 and 2 all we need to do is select the project file in VS and change its Sandboxed Solution property to true.

One thing to notice is that the deployment target is set to GlobalAssemblyCache meaning the sandboxed assembly is stored in the GAC. We can see this in the manifest below.

<?xml version=“1.0“ encoding=“utf-8“?>

<Solution xmlns=“http://schemas.microsoft.com/sharepoint/“ SolutionId=“a12ef36a-3f79-4d8f-801f-b9ef56e6247f“ SharePointProductVersion=“14.0“>

  <Assemblies>

    <Assembly Location=“EventReceiverDeploymentExample.dll“ DeploymentTarget=“GlobalAssemblyCache“ />

  </Assemblies>

  <FeatureManifests>

    <FeatureManifest Location=“EventReceiverDeploymentExample_Feature1\Feature.xml“ />

  </FeatureManifests>

</Solution>

Summary

Sandbox solutions are now the recommended way of deploying secure custom code but they do have their restrictions so there is a trade-off. You may want to look at a hybrid approach which uses a full trust proxy to execute code outside the sandboxed environment, this allows you to still deploy code in a sandboxed solution but also call out to other resources using a proxy. I will cover hybrid solutions in part 4.

For more information see these links below:

http://msdn.microsoft.com/en-us/magazine/ee335711.aspx

http://technet.microsoft.com/en-us/library/ee721992.aspx

http://blah.winsmarts.com/2009-12-SharePoint_2010_Sandbox_solutions__Architecture_and_Restrictions.aspx

So what does bin/CAS mean?

The bin/CAS model basically means that your solution assemblies are deployed to the bin folder in the root of your web application folder structure. There are two main advantages to this approach, the first is that the assembly is isolated from any other web applications on your server by virtue of the fact that it resides in the bin folder.

The other is that the assembly is now subject to the Code Access Security policies defined in the web applications web.config file.

So overall this is a much secure option that the full trust model described in part 1.

So what’s the catch?

Well the main catch is that because your assembly resides in the bin folder it can only be loaded by the web applications IIS worker process which means that any SharePoint component that isn’t run within the IIS worker process like timer jobs for instance cannot be deployed in this way.

Another downfall is that because the assembly is restricted by the CAS policies of the web application if your assembly needs to do anything outside of the default wss_minimal and wss_medium trust policies you either need to elevate the whole web application to full trust by changing the trust level in web.config which is not recommended or define your own custom policy file which can be a pain to get right.

Example of default policy files defined in web.config:

<securityPolicy>

      <trustLevel name=“WSS_Medium“ policyFile=“C:\Program Files\Common Files\Microsoft Shared\Web
Server Extensions\14\config\wss_mediumtrust.config“ />

      <trustLevel name=“WSS_Minimal“ policyFile=“C:\Program Files\Common Files\Microsoft Shared\Web
Server Extensions\14\config\wss_minimaltrust.config“ />

</securityPolicy>

Example of default setting for which policy file to use. Remember that this setting only applies to assemblies deployed to the bin folder not to the GAC. All assemblies in the GAC will run in full trust.

<trust level=“WSS_Minimal“ originUrl=“” />

Example of elevating whole application to full trust (not recommended).

<trust level=“Full” originUrl=“” />

Take a look at the wss_minimaltrust.config policy file located in the 14/CONFIG folder of your SharePoint implementation for an example of what a policy file looks like.

So how do we deploy to the bin?

In part 1 we create an event receiver project to deploy the assembly to the bin folder instead of the GAC we simply select the project file in Visual Studio and change its Assembly Deployment Target property to WebApplication as shown below:

Now when we package our solution and take a look at the manifest.xml file we see the following:

<?xml version=“1.0“ encoding=“utf-8“?>
<Solution xmlns=“http://schemas.microsoft.com/sharepoint/“ SolutionId=“a12ef36a-3f79-4d8f-801f-
b9ef56e6247f“ SharePointProductVersion=“14.0“>
<Assemblies>
<Assembly Location=“EventReceiverDeploymentExample.dll“ DeploymentTarget=“WebApplication“ />
</Assemblies>
<FeatureManifests>
<FeatureManifest Location=“EventReceiverDeploymentExample_Feature1\Feature.xml“ />
</FeatureManifests>
</Solution>

When we deploy this solution the assembly will now be deployed to the bin folder and be subject to the CAS policies defined in the web.config file.

So what does this mean for our custom code?

The bin/CAS model is only suitable for code that will run within the IIS worker process meaning that timer jobs, service applications and workflows cannot be deployed using the bin/CAS model. It also means that you only have access to a subset of the SharePoint API that is defined in the CAS policy selected in the web.config.

The bin/CAS model is no longer a recommended approach in SharePoint 2010 as the Sandboxed and hybrid approaches offer a better tradeoff between security and ease of deployment.

If you want to extend the default policy files and deploy a custom CAS policy with your solution then you have to do a couple of things:

1. Define your custom policy file and package it up for deployment in your custom solution. There is a good blog post on how to do this and a helpful template to use in this blog post here http://blog.mastykarz.nl/working-easier-custom-cas-policies/
2. Reference your custom policy file in the web.config of your web application

<securityPolicy> 

    <trustLevel name=“WSS_Minimal_Custom“ policyFile=“C:\Program Files\Common Files\Microsoft Shared\Web
Server Extensions\14\config\wss_mediumtrust.config“ />

      <trustLevel name=“WSS_Medium“ policyFile=“C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\14\config\wss_mediumtrust.config“ />

      <trustLevel name=“WSS_Minimal“ policyFile=“C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\14\config\wss_minimaltrust.config“ />

</securityPolicy>

<trust level=“WSS_Minimal_Custom“ originUrl=“” />

In part 3 I will discuss the recommended approach for secure deployment of custom code using the Sandbox solution feature in SharePoint 2010.

In the days of MOSS 2007 and WSS 3.0 you had a couple of choices when deploying code to your server farm, Full Trust GAC deployment or bin/CAS deployment. With SharePoint 2010 you have another two options.

The two new options in SharePoint 2010 are Sandboxed solutions and a hybrid approach that gives you the ability to develop Sandboxed solutions that can call out to full trusted proxies.

For more reading to get an understanding of the execution models in SharePoint 2010 check out this MSDN article http://msdn.microsoft.com/en-us/library/ff798421.aspx

In part one I will discuss Full Trust deployment which is the easiest and most straightforward was of deploying solutions mainly because of the added complexity of getting the Code Access Security policies right in the bin/CAS model.

Most .Net developers will be familiar with deploying their assemblies to the GAC, we will all know that the assemblies have to be strongly named and we all know as SharePoint developers how to deploy our solution assemblies into the GAC but below I will outline exactly how to do this with SharePoint 2010.

We will create a basic event receiver and deploy this as a Full Trust solution to the farm then I will outline exactly how deploying our solution as Full Trust affects what the event receiver can do and what it can access.

1. Create a new Event Receiver project in Visual Studio
2. When you click ok you will be prompted to either deploy the solution as a Sandboxed solution or as a Farm Solution. We want to choose a farm solution which is basically saying we want to create a Full Trust solution that will be deployed to the server farms solution store. That also means that the assembly will be deployed to the GAC on every web server in the farm.
3. VS will now ask you what type of event receiver you want to create, it doesn’t matter at this point because we are deploying a Full Trust solution which means that we can create any type of SharePoint component we like.
4. VS will now create your project structure and give you some default code for your event receiver. We won’t create any functionality as our goal is just to show how to deploy the solution as full trust and what that actually means.
5. Right click on the project file and select “Package” this will create our solution file (.wsp) in the bin folder of our project.
6. When we open up the manifest.xml file within the solution file we can see that our assembly is being deployed to the global assembly cache (GAC)<?xml version=“1.0“ encoding=“utf-8“?>
   <Solution xmlns=“http://schemas.microsoft.com/sharepoint/“ SolutionId=“a12ef36a-3f79-4d8f-801f-
   b9ef56e6247f“ SharePointProductVersion=“14.0“>
   <Assemblies>
   <Assembly Location=“EventReceiverDeploymentExample.dll“ DeploymentTarget=“GlobalAssemblyCache“ />
   </Assemblies>
   <FeatureManifests>
   <FeatureManifest Location=“EventReceiverDeploymentExample_Feature1\Feature.xml“ />
   </FeatureManifests>
   </Solution>
   

Great our assembly is in the GAC but what does this mean?

Well it means that any process can now load and use this assembly, only being restricted by the identity the process is running under. For example this means that it can be loaded by the, IIS worker process (w3wp.exe), the timer job process (owstimer.exe) and the workflow engine process. It also means that the code has no restrictions on what it can access outside of the assembly i.e. WCF web services and databases etc. Most importantly though it means it can access the full SharePoint object model and the full .Net framework class library.

Assemblies in the GAC will not be subject to the CAS policies defined in the web applications web.config file

That’s all good so why isn’t every solution a full trust solution?

Well in my experience nearly all MOSS 2007 solutions were deployed to the GAC as full trust solutions. This is mainly because the bin/CAS approach was hard to get right and most of the time offered little benefit over a GAC solution, bear in mind though that for security conscious applications like shared web applications and public facing internet sites that you may want to put in the effort to isolate your custom code at the web application level and deploy your solutions to the applications bin folder. I will cover this further in part 2.

In SharePoint 2010 however we get the option of a Sandbox solution and hybrid approaches which could offer you the best of both worlds.

In summary full trust solutions are often the easiest and straightforward solutions to deploy, however you must make sure that you fully trust the code being deployed as it can have farm wide performance and stability issues if the code crashes or causes memory leaks. The other issue is of course a potential security flaw in your code can compromised your whole server farm.

Another downside to full trust solutions is that I.T policies may be in place that mean full trust solutions are prohibited or may be subject to a full code review before being deployed.

For further reading on full trust solutions you can check out the MSDN article here which gives you some nice diagrams on exactly how SharePoint handles loading full trust assemblies. http://msdn.microsoft.com/en-us/library/ff798425.aspx

I created a new feature for my new ListTemplate with specified the Elements file and the location of the schema.xml file which is used when the list instance is provisioned. One thing to note with the schema.xml file is that it has to be in a folder that has the same name as the ListTemplate being defined. There is a good blog post that goes into a lot more detail about how to structure your ListTemplate feature here http://blogit.create.pt/blogs/andrevala/archive/2008/05/17/SharePoint-2007-Deployment_3A00_-List-Template-Features.aspx

My feature file looked like this:

<?xmlversion=“1.0“encoding=“utf-8“ ?>
<Feature
xmlns=“http://schemas.microsoft.com/sharepoint/“
Id=“1ED7C1B9-4FF3-4987-A773-612EB378C92F“
Title=“Moderated Wiki List Template Feature“
Description=“Creates a moderated Wiki list template in the site.“
Scope=“Web“
Version=“1.0.0.0“
ActivateOnDefault=“TRUE“>
<ElementManifests>
<ElementManifest Location=“Elements.xml“ />
<ElementFile Location=“ModeratedWikiTemplate\schema.xml“ />
</ElementManifests>
</Feature>

My Elements file looked like this:

<?xml version=“1.0“ encoding=“utf-8“ ?>
<Elements
xmlns=“http://schemas.microsoft.com/sharepoint/“>
<ListTemplate
FeatureId=“1ED7C1B9-4FF3-4987-A773-612EB378C92F“
BaseType=“1“
Category=“Libraries“
Name=“ModeratedWikiTemplate“
DisplayName=“Moderated Wiki Page Library“
Description=“A moderated Wiki page library.“
DisableAttachments=“True“
DisallowContentTypes=“True“
Default=“True“
EnableModeration=“True“
FolderCreation=“False“
Hidden=“False“
HiddenList=“False“
OnQuickLaunch=“True“
SecurityBits=“11“
Sequence=“500“
Type=“119“
VersioningEnabled=“True“
ForceCheckout=”TRUE”>
</ListTemplate>
</Elements>

I was struggling to get this working once provisioned; I looked in the MSDN documentation for the ListTemplate element and saw that there are attributes called VersioningEnabled and EnableModeration. I set these both to TRUE and instantly found that there was an issue with the EnableModeration value. Basically the docs say that you need to set it to TRUE when in fact the value has to be True (yes it’s case sensitive). You can see the correct way of setting the attribute above.

After re-deploying the feature I found that this time the list template appeared on the site and I was able to create list instances from it but when I looked that the list settings I found that content approval wasn’t switched on. Further digging around led me to the schema.xml file.

In the schema.xml file there is a root element called List, looking at the MSDN documentation for this showed me that there were a couple of properties I could set on this element to do with versioning and content approval, namely ModerationType, ModeratedList and VersioningEnabled. I set these three attributes to true and re-deployed the feature.

<List xmlns:ows=“Microsoft SharePoint“
Title=“$Resources:core,webpagelibList;“
Direction=“$Resources:Direction;“
Url=“Wiki Library“
BaseType=“1“
ModeratedList=“TRUE“
ModerationType=“TRUE“
VersioningEnabled=“TRUE“
DraftVersionVisibility=“2“>

This time when I created a list instance from the list template I had content approval and versioning enabled. You can also set the DraftVersionVisibility attribute to control who can see draft versions of the list items.

So basically you may need a combination of settings in both the ListTemplate and List elements to achieve was you need with list definitions.

NOTE: This was for a MOSS 2007 project but I’m guessing the same works for SharePoint 2010 but haven’t tried it.

http://blogs.msdn.com/b/sharepoint/archive/2010/11/18/connecting-lync-to-sharepoint.aspx

Yesterday I treated myself to an early Christmas present a Samsung Galaxy Tab.

I liked the look of this tablet as soon as I saw it. I have been contemplating an iPad for a while but I didnt see much compelling use for it, it was just a bit too big.

The Galaxy Tab to me is a perfect size for a tablet, combining a screen size large enough for a great browsing, reading and watching video.experience with a form factor that is small enough to fit in a coat pocket.

The Android 2.2 OS is a joy to use and the marketplace is filled with thousands of useful apps.

Im currenty working on an application for the Windows Mobile 7 platform but as soon as Im done I will be porting it over to Android.

Overall Im glad I opted for a Galaxy Tab over anything else and I can definately recommend this for a Christmas present.

(Oh and this post was also written using the WordPress app on the device)

The latest project I worked on was a public facing SharePoint (MOSS 2007) web content management system. The goal of the site was to provide a content management platform for editorial to use, which would allow them to quickly create multimedia driven websites focused on a particular subject such as frontier markets in the first instance.

Thomson Reuters released a new website called Reuters Insider which the Special Report site we built is designed to complement but more focused on a particular subject. The site employs some standard functionality seen on most websites nowadays like tagging/tag clouds, comments, search, RSS feeds etc.

Take a look and would welcome any feedback:

http://frontiermarkets.thomsonreuters.com/

The site contains some good material to get you started developing with SharePoint 2010 and also contains material for the IT Pro guys. The training comes in the form of videos, hands on labs and some assessments to help you learn along the way it’s definitely worth checking out the site if you’re interested in the upcoming release of SharePoint.

I had a couple of criterion; it had to have a solid state drive, the biggest I could afford and it had to have at least 8GB RAM. I also wanted something that looked nice not just a grey plastic slab that looked as interesting as day out at Charlton (I’m looking at you Thinkpads).

After a few hours of searching I kept coming back to the Dell XPS Studio 16. It allowed me a high spec machine and it also looked the part with a very good RGBLED screen and nice backlit keyboard. The only problem was the price which came to around £2300 for the highest spec I could get:

Processor: Intel i7 820QM 8MB Cache 1.73Ghz with turbo up to 3.06Ghz
RAM: 8GB DDR3 1333MHz SDRAM
Storage: 256GB SSD
Graphics 1GB ATI Radeon 4670 HD
Screen: 16″ Truelife 1080p RGBLED

Anyway I bit the bullet and ordered. Much to my surprise I got a delivery date of 6 weeks! Obviously I couldn’t wait 6 weeks for my shiny new laptop so I complained but I was told that it’s shouldn’t take that long so I thought I would wait it out as I couldn’t find any other laptop that matched the Dell.

The next day I was looking at the Dell website again when I noticed that the processor that I had upgraded for the price of another £250-£300 was now included free in the price of the laptop. I felt cheated by this as I was already ordering a £2300 laptop at least they could do was give me the new price. I phoned Dell sales team and was told that I wouldn’t get the price of the processor refunded; this coupled with the 6 week delivery date prompted me to cancel the order with the lady on the phone.

I was annoyed with Dell so I decided to have another look around safe in the knowledge that my order was cancelled and the money was still in my bank. But a few days later after visiting the Dell order tracking site I noticed the order was still in progress so I sent an email to make sure the order was cancelled from which I had no reply. The next day I receive an email telling me my order had been shipped and the money taken from my account!

I phoned Dell who told me they were very sorry they don’t know why the laptop was sent out. In the end I decided to keep the laptop as I still couldn’t find anything else that matched it and I was excited now the laptop was on its way but annoyed at the same time that Dell took my money after I cancelled the order. So beware when dealing with Dell sales because I wouldn’t trust anything they say.

So the laptop arrives and I was very impressed, it was a big heavy lump of a machine compared to the MacBook Pro but still portable enough to carry around to work and back. The screen is very nice indeed and the speed is more than I expected it to be. Solid State Drives are definitely the way forward. I installed VMWare Workstation 7 and got to work setting up my development environment, 16 hours later I was ready to get working on it. The speed is phenomenal and in a different league to the MacBook Pro, I can even run Windows Server 2008 R2 in a virtual machine with full Aero enabled and it doesn’t even blink.

As a SharePoint development laptop I would definitely recommend it. There is only one issue in which you need to install a BIOS update and get Dell to send you a 130watt power supply to replace the rather feeble 90watt one that’s shipped. This is to remedy a CPU throttling issue with the machine (basically the power supply isn’t powerful enough to run the CPU and Graphics card at high intensity) the BIOS update fixes the throttling from the motherboard.

I ran the Windows Experience Index before I fixed the throttling issue so it may get a better result but it scored 6.7 initially.

I’m overall very impressed with this laptop and it outperforms anything I have every used. If you want a powerful machine and don’t mind spending a few bob then definitely take a look at this machine.