Skip to content

Unable to add selected web part(s). … : Cannot import … Web Part.

August 9, 2012

When adding a custom webpart to a page, we received the following error:

Message from webpage
Unable to add selected web part(s).

webpart name: Cannot import webpart name Web Part.

This is a quite common error messages and very uninformative. We started troubleshooting using the tips we found by google, but non of them seemed to be related to our problem. The most interesting part of the story was that the same webpart had no problem until a couple of days ago. And there were no changes in the webpart definition or any other part of the code, that could have caused such problem.
Some instances of the same webpart were already on some pages and they were working without any problem. We just could not add a new instance of the webpart to the page.

In the ULS logs we found the following related error:

Error importing WebPart. Assembly xx.xx, Version=, Culture=neutral, PublicKeyToken=4f6f772418ff3333, TypeName. xx.xx.xx
Failed to add webpart http://server/_catalogs/wp/webpart name.webpart;webpart name.
Exception Microsoft.SharePoint.WebPartPages.WebPartPageUserException: Cannot import Web Part.
at Microsoft.SharePoint.WebPartPages.WebPartImporter.CreateWebPart(Boolean clearConnections)
at Microsoft.SharePoint.WebPartPages.WebPartImporter.Import(SPWebPartManager manager, XmlReader reader, Boolean clearConnections, Uri webPartPageUri, SPWeb spWeb)
at Microsoft.SharePoint.WebPartPages.WebPartImporter.Import(SPWebPartManager manager, XmlReader reader, Boolean clearConnections, SPWeb spWeb)
at Microsoft.SharePoint.WebPartPages.WebPartQuickAdd.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument)

We doublechecked and triplechecked the assebly definition, PublicKeyTokens, the assemblies in the GAC – everything was ok.

We had a last known good version in source control, so we had no better idea than rolling back the changes to find the point where things got broken.

And we found this line of code added to one of the underlying logging components that was used by the webpart:

Assembly a = Assembly.GetExecutingAssembly();

When we removed this line, the webpart problem was resolved. Great!

After further testing we found that this line threw the following exception:

[4928] System.Security.SecurityException: Request for the permission of type ‘System.Security.Permissions.FileIOPermission, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089’ failed.
[4928] at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
[4928] at System.Security.CodeAccessPermission.Demand()
[4928] at System.Reflection.Assembly.get_Location()

I’m still not sure why this error came up only when adding a webpart to a page. And how is it possible that it caused no problem in the other 99.9999% of the site.

But I don’t care now. Happy to have it resolved…

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: