The reason for this behaviour lies in the way SP2010 works post SP1. The feature is called sitecollection recycle bin. Sitecollections when deleted from the GUI or powershell are marked as deleted but are kept in the DB.

You can see which sitecollections have been deleted by running the Get-SPDeletedSite powershell cmdlet.

To delete these sites from the DB, you need to remove them using the Remove-SPDeletedSite cmdlet. After you have run this, you will need to manually start the Gradual site delete job that will actually delete the content from the DB.

Well, I can definitely say that it has been the most intense three weeks of my technical life. Not only was the content very well built and wide-spread, but the pace of the training was also very fast. Listening to the introductions on the first day I immediately noticed that my fellow master candidates are all very experienced and quite knowledgeable on SharePoint. People attending the course had a very good general knowledge but also contributed with unique areas of expertise that came in very handy later during team exercises.

Time management played a critical role throughout the duration of the master rotation. Starting from the first day, the candidates had to have a perfect knowledge on how much they can handle, what are their strengths and weaknesses, and how to process an awful lot of information while keeping a healthy balance between learning and relaxation. When you are surrounded with a technical topic for more than 10 days for 12+ hours a day, it is critical to find a way to maintain your concentration and keep some reserves for the qualification lab and knowledge exam.

Speaking of exams, both the qual lab and the knowledge exams were very demanding. And again, time management, time management, time management…

Summing it all up, I think it was a well invested effort, I met my calculation and not only learned a lot on SharePoint 2010 and myself, but also met a lot of very bright, fun people!

Oh yes, I almost forgot. I am now certified as a SharePoint 2010 Master!

Here’s the answer:

The claim i:0#.w|europe\andrasg translates into:

i: This is an identity claim. Other claims would have the character c here.

:: Colon separator

0: Reserved for later use

#: Claim type = SPClaimTypes.UserLogonName

.: Claim value type = Microsoft.IdentityModel.Claims.ClaimValueTypes.String

You can find the full list of values at:

https://msdn.microsoft.com/en-us/library/gg481769.aspx

These unified encoding values ensure that different farms can understand each others claims. Be aware though that if you use a custom claim type, the encoded string can differ from farm to farm.

Retracting the OfficeToolbox wsp solved the problem.

<AddContentTypeField ContentTypeId="averylongidhere"
FieldId="{133865E2-17C6-4c42-B98A-D4D09BA43714}" PushDown="TRUE"/>

Digging deeper I found no errors when upgrading the feature so I was about to give up when I tried to manually add the field to the contenttype from the UI. I was greeted with a nice exception when clicking “Add from existing site columns”. This error showed up in the ULS log with a trace and callstack. The error message was rather misleading, telling that there is a column that has multiple choice values with the same ID.

Examining my solution I found a few fields that had a StaticName that already existed. This resulted in site columns with the same staticname but a different ID. Cleaning these up made the error disappear.

It’s been a happy SharePoint day.

To solve this problem, a very easy workaround is to create a class in a separate assembly that inherits from the version-controlled webpart .cs file and implements the actual webpart. This way the non-version controlled part of the code is very thin and SharePoint is still happy with it. Problem of this solution is that it requires and additional assembly file and also generates quite some overhead (SPWebConfigModification class) when packaging your solution.

Come SharePoint 2010, a lot nicer solution is available:

<Assemblies>
  <Assembly Location="assemblyname.dll" DeploymentTarget="GlobalAssemblyCache">
    <BindingRedirects>
      <BindingRedirect OldVersion="0.0.0.0-1.0.0.0" NewVersion="2.0.0.0" />
    </BindingRedirects>
  </Assembly>
</Assemblies>

You could even omit the NewVersion tag and have a wide OldVersion range.

One thing to be careful of is keeping old SafeControl entries. If you remove them, assembly redirection will not work as the original assembly will not be loaded. This results in SharePoint also not updating its references to the old assembly version. Also keep in mind that SharePoint updates assembly references page-by-page when they webparts on the page are loaded, so all pages need to be “touched” in order to get rid of old references.

To get around the bug with leading zeros in the public key token’s bytes make sure you are at least on the June 2011 CU.

More info on the issue:
https://www.bluedoglimited.com/SharePointThoughts/Lists/Posts/Post.aspx?ID=313

And the resolution:
https://blogs.msdn.com/b/mcsnoiwb/archive/2011/07/18/assembly-binding-redirection-bug-fixed-in-june-cu.aspx

Recently I faced a strange ArgumentNullException when creating a Content by Query Webpart in C# code. A feature activated event handler was supposed to add a new webpart to a page. Wiring everything up, testing the feature activation through the UI, everything was smooth. As a last step I made the feature hidden and tried to activate the feature through stsadm. And this is where I was left out of luck. STSADM only gave me a very helpful “Value cannot be null”. Digging deeper in the ULS log I caught a callstack which showed that there is some problem getting the SPContext.

To go around this problem, the easiest way is to create a fake SPContext. Waldek and Keith have some great suggestions. The idea is pretty simple:

   1: if (HttpContext.Current == null)

   2: {

   3:   HttpRequest request = new HttpRequest("", web.Url, "");

   4:   HttpContext.Current = new HttpContext(request,

   5:     new HttpResponse(new StringWriter()));

   6:   HttpContext.Current.Items["HttpHandlerSPWeb"] = web;

   7: }

   8: // your code goes here

Be aware that this trick only works when you are working with an SPWeb level object. When dealing with SPList or lower hierarchy items you need to go an other way.

An interesting anomaly I have faced recently (and the source of this discovery) was that when using custom field controls to values of some custom fields and trying to access the values of PublishStartDate or PublishEndDate, these fields contain the values that were present on the ListItem when the pagelayout used to edit the publishing page has loaded.

So imagine the following flow of user actions:

1. Open page for editing
2. Use the Schedule button in the ribbon
3. Set some scheduling dates and click ok
4. The modal dialog disappears (and your page loads some info through JavaScript from the server)
5. Save the page
6. Field controls are asked to provide values of their controls so these can be saved to the appropriate field

At this point I would expect that the following code would return the dates set in step 3:

   1: public override object Value

   2: {

   3:     get

   4:     {

   5:         SPFieldDateTime pubStart = base.Fields.GetFieldByInternalName("PublishStartDate") as SPFieldDateTime;

   6:         return ListItem[pubStart.Id];

   7:     }

   8:     set

   9:     {

  10:         base.Value = value;

  11:     }

  12: }

Interestingly this is not the case, the values set in step 3 are not retained. My logic would tell me that the ListItem object would be built from scratch at step 5 resulting in the query of properties (changed in step 3). Any ideas what’s happening here?