Dienstag, 4. Oktober 2011

Error occurs while trying to upgrade installed features of an upgraded solution

It’s way back since my last post, but at last I found something very useful to post.

During the process of developing on a SharePoint 2010 solution, to have clean presuppositions for testing and avoid phantom mistakes I very often create new site collections and delete them afterwards. A part of this process is also removing and adding newer versions of the solutions to the solution-store. So from time to time I was confronted with strange error messages when I tried to upgrade features to new versions.

I concretely tried to do it the Microsoft recommended way and used a modified version of the program, you can find here: http://msdn.microsoft.com/en-us/library/ff798298.aspx

The program that iterates over the SPWebApplication to find upgradable features sometimes fails with an error message that says that it can’t find a special SiteCollection: The site with the id D0D529C1-DC06-4DB0-A8A3-81466E1E75DB could not be found.
This is true because it has been previously deleted by me and is no longer available in Central Administration or anywhere else. It seems, there are still some SiteCollection-related artifacts in the content database stored that prevent a clean upgrading of the new versioned features.

Have a look at the Default TimerJobs,  the promisingly entry “Gradual Site Delete”, we perhaps can use to solve this issue with tools out of the box. By default it’s executed daily but we can change the cycle to earlier executions or even start it manually.

This blog described its functionality as “Deletes all the data from the host content database for all deleted site collections”. What a pitty, in my case, it doesn’t. The error remains.

Now it’s time to have a look at the content database. The name of this table looks encouraging: dbo.SiteDeletion

After opening the table, an entry appears that includes the evil SiteId, which seems to be the crux of the matter:


Luckily Microsoft gave us the method ForceDeleteSite on the SPContentDatabase-class.

If you write a really short program, for e.g. a console application that takes the Uri to get the SPWebApplication-object and the Guid of the corrupted SiteCollection, you can create a new entry to the database-table with a datetime of 1900-01-01.


Simply, there are only those two lines needed:

SPWebApplication spWebApplication = SPWebApplication.Lookup(new Uri("http://mywebapplication")); // insert the webapplication

spWebApplication.ContentDatabases[0].ForceDeleteSite(new Guid("D0D529C1-DC06-4DB0-A8A3-81466E1E75DB"), true, false); // insert the ID from the errormessage


After that, retry running the “Gradual Site Delete”-timerjob and – surprise – both entries are deleted.


If you retry upgrading your feature, no more annoying error message occurs.

Dienstag, 12. Juli 2011

Anonymous access prompted for login after click in web part area on publishing portal

Currently I'm experimenting with publishing portal and the ability to use it for publicfacing internet sites where anonymous access is allowed. In the site permissions I gave the anonymous users access to the entire website.
Afterwards I created a custom list named 'Test' and entered three simple items with just the title-field filled.

On the default.aspx of the publishing portal I added a ListVievWebPart to the 'Test'-list and published it.

Now if the anonymous user loggs in, he sees the default publishing page with that LVWP and three items in it.But if he clicked on an item, the login-popup appeared. Also if I tried to break the list-permission-inheritance from the web, the list items would open but the first click in the webpart resulted in that nasty login-popup.

So what to do? A lot of pages, blogs and forums on the internet suggest to deactivate a hidden feature called 'ViewFormPagesLockDown' to allow anonymous users to have access to list-items.
Another approach I found on several pages was to remove the coupling to the code-behind in the file wpribbon.aspx on the _layouts-folder directly to workaround the other problem.

I didn't like neither the first nor the second way. The one kills the security concept, the other transgesses the rules of Microsoft by changing files directly on the server.

So I grabbed good old SharePoint Manager 2010 and examined the 'Test'-List where I detected the AnonymousPermMask64-Attribute that had this string set by default: ViewListItems, ViewVersions, Open, ViewPages, UseClientIntegration.

This had to be the key to solve the problem... I went to the MSDN-Article describing all SPBasePermissions-enum-values and found... ViewFormPages (View forms, views, and application pages, and enumerate lists).

Okay, rest was easy... If there is a feature activated on publishing-portal called ViewFormPagesLockDown that prevents the anonymous user from entering formpages, then the basepermission ViewFormPages perhaps grants access for the element.

So I programmatically broke the inheritance of the list-permissions and reset the spbasepermissions to the AnonymousPermMask64-Attribute as you can see in the following code-segment and everything worked as I imagined:



SPList spList = spWeb.GetList("/Lists/Test");

spList.BreakRoleInheritance(false);
spList.AnonymousPermMask64 =
 SPBasePermissions.ViewListItems |
 SPBasePermissions.ViewVersions |
 SPBasePermissions.Open |
 SPBasePermissions.ViewPages |
 SPBasePermissions.UseClientIntegration |
 SPBasePermissions.ViewFormPages;

spList.Update();


Donnerstag, 7. Juli 2011

Add customaction to ribbonbar in sharepoint 2010 wiki page

Just a simple copy & paste of a custom action that adds a button to the ribbonbar in a publishingpage in the pageslist of a wiki-site:

<CustomAction Id="WikiDocumentExportCustomizationPageView" Rights="Contribute" Location="CommandUI.Ribbon" Sequence="30" Title="Wiki-Document-Export"> 
 <CommandUIExtension> 
  <CommandUIDefinitions> 
   <CommandUIDefinition Location="Ribbon.WikiPageTab.Share.Controls._children"> 
    <Button Id="WikiDocumentExportCustomizationPageView.Button" Command="ExportCurrentWikiDocumentFile2" CommandType="General" Description="Export Wiki-Document" TemplateAlias="o1" Sequence="30" Image32by32="/_layouts/images/wiki/pdf_export.png" LabelText="Export Wiki-Document"/> 
   </CommandUIDefinition> 
  </CommandUIDefinitions> 
  <CommandUIHandlers> 
   <CommandUIHandler Command="ExportCurrentWikiDocumentFile2" CommandAction="javascript:ExportCurrentWikiDocumentFile('{SiteUrl}');"/>
  </CommandUIHandlers> 
 </CommandUIExtension> 
</CustomAction>

Pay attention that this button is only visible to users with contribute-rights on the list.
ExportCurrentWikiDocumentFile is a custom external javascript-function that implements the code behind the button. You must define your own function here...

Freitag, 24. Juni 2011

Good example for a custom service application

Check out chapter 9 of the book Microsoft SharePoint 2010 Web Applications: The Complete Reference, there is a really good example how to create a custom service application. The described scenario creates a translation service and a webpart that's using it.

But be aware of a little error on page 199, change this line

public string AlternativeLanguage { get; set; }

to 
[Persisted] private string _alternativeLanguage;

public string AlternativeLanguage
{
   get { return _alternativeLanguage; }
   set { _alternativeLanguage = value; }
}

or otherwise no change of the Alternative Language would be stored.

Freitag, 17. Juni 2011

Free alternative for .net Reflector: ILSpy

Because of the fact that the most valueable tool in the SharePoint-World beside SharePoint Manager (I mean our beloved .net Reflector) is no longer free and becomes unsusable after a few weeks until it looks for updates, some resourceful developers started writing an open source equivalent, which can be found at:

http://wiki.sharpdevelop.net/ILSpy.ashx

I downloaded and tested it already and I think, it's really advanced for the short time elapsed since its development started in february 2011. The look and feel is very similar to .net Reflector and you definitely should give it a try.

Montag, 2. Mai 2011

CustomAction in ribbonbar doesn't appear for contenttype

Recently I wanted to add a contenttype-specific custom action to the ribbonbar of a document-library. But the button didn't appear. After a short time of verifying and comparing IDs with SharePoint manager, I found the issue:

GuidGen in Visual Studio created me this GUID: 717EE0C46890438e8E245E7D4B4B7438 which I used for the sitecontenttype inheriting from document (0x010100). Then the list instance creates a listcontenttype from this and appends its own GUID. But the ID from the listcontenttype is 0x010100717EE0C46890438E8E245E7D4B4B743800E57C8E7D4D7D024C9A357907E925F14B.

So what's the difference between the root? Its the lower case character 'e'. It seems as if SharePoint would have a problem with case-sensitivity. Since I changed the lower 'e' to an upper 'E' in my sitecontenttype and customaction, the button is visible now.

So please pay attention for lower case characters and replace them when generating Guids with VisualStudio GuidGen.

Montag, 28. März 2011

Dienstag, 22. März 2011

Exam 070-573 passed!

I successfully finished this exam yesterday and may entitle myself TS: Microsoft SharePoint 2010, Application Development. Hooray!

Although it's commonly said, 070-576 is the more complex exam, I personally felt the TS-exam the harder one.

Now I'm awaiting for the MCPD: SharePoint Developer 2010 status set by Microsoft...

Mittwoch, 16. März 2011

No two choices should have the same ID

In any case avoid create different fields with the same Guid OR - and this is important - the same internal name.

This is never checked by the solution packaging mechanism or while adding or installing the solution to the solution store. The errormessage "No two choices should have the same ID" occurs, if you for e.g. try to add an existing field to a sharepoint list.

Be sure to check this from time to time during development-process and before setup your solution to the production server. If the system is up and running, it's very difficult to do changes here...

Freitag, 14. Januar 2011