I’ve seen this come up a few times in the forums so I thought I would post up the links to the forum threads at least for my own personal reference.

http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/552e69f8-4fb8-4019-96e4-1109e305732b/

http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/76c765cf-f3ce-4930-8b44-e7a75db6f405

As I mentioned in the first forum posting, in the past on a few projects I’ve used the filtering cascading dropdown that is up on codeplex.

I was writing a custom SharePoint feature the other day and probably killed a few hours on this error and still don’t have an answer to it just yet. 

using (SPWeb web = (SPWeb)properties.Feature.Parent) //since SPWeb is unmanaged code

{

    //check to see if our list exists already

    SPList storageList;

    try

    {

        //storageList = web.Lists[PAGE_VIEW_LIST_VALUE];

        storageList = web.GetList(web.ServerRelativeUrl + "/Lists/MyCustomList");

    }

    catch (Exception ex)

    {

        storageList = null;

    }

}

As you can see in the above code, I am merely trying to get a reference to my custom list using the SPWeb.GetList method.  Everything I have read says that the GetList method is the most efficient means of getting a reference to a SPList object as opposed to SPWeb.Lists[“MyCustomList"].  The problem was that everytime this code ran, it would NOT get a reference to my list and would instead throw an error.  I verified the URL countless times and tried everything, but still got an error whenever the feature was activated and this code ran.  I  then decided to write a quick win app with the same code and BAM!…it worked fine! 

So…..I still don’t have an answer at the moment (when I get time, I’ll revist this) but for the time being I switched over to the SPWeb.Lists[“MyCustomList”].

To all the SharePoint dev’s out there writing custom features…look out for this error.

*** Short answer to the error is to check “Upgrade.log” in your 12 hive and look for the REAL error behind this message and fix that error, then run config wizard again.

SharePoint 2007 SP2 came out at the end of April as we all know and naturally my client wanted to install it the second it came out.  I managed to be the voice of reason and convinced them to hold off installing it for awhile so that we could do testing of it in their environment, as well as to monitor the SharePoint blogs/forums to see what errors we might be in store for as well as hopefully fixes for those errors.

I finally got around to installing SharePoint 2007 SP2 on the client environment and all went smooth until when I ran the config wizard after the install, the SP2 upgrade died on step 8 of 9 and I got the following error: “The B2B upgrader timer job failed”.  The screen told me to take a look a the upgrade log in the 12 hive.  I opened the log it told me too and got the following error:

05/21/2009 18:49:13  6  ERR                    Failed to upgrade SharePoint Products and Technologies.
Failed to upgrade SharePoint Products and Technologies.  Further information regarding this failure can be found at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\Upgrade.log.
An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown.  Additional exception information: Failed to upgrade SharePoint Products and Technologies.
Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException: Exception of type 'Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException' was thrown.
   at Microsoft.SharePoint.PostSetupConfiguration.UpgradeTask.Run()
   at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()

At first glance I thought that the error really doesn’t tell me anything other than what I obviously already know….I have a F’n error!.  Once I composed myself I read the message again and saw that it was telling me to look at “Upgrade.log” for the real error.  After digging in the file I saw this:

   at Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.Upgrade(Boolean recursively)
   at Microsoft.SharePoint.Upgrade.SPManager.ReflexiveUpgrade(Object o, Boolean bRecurse)
[SPManager] [INFO] [5/21/2009 6:49:01 PM]: Resetting the status of PersistedUpgradableObject: SPWebService Parent=SPFarm Name={DBNAME} to Online.
[SPManager] [ERROR] [5/21/2009 6:49:01 PM]: ReflexiveUpgrade [SPWebService Parent=SPFarm Name={DBNAME}] failed.
[SPManager] [ERROR] [5/21/2009 6:49:01 PM]: Cannot open database "WSS_Content_MSSupport" requested by the login. The login failed.
Login failed for user '{AD}\{USER NAME}'.
[SPManager] [ERROR] [5/21/2009 6:49:01 PM]:    at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
   at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
   at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
   at System.Data.SqlClient.SqlConnection.Open()

etc. etc.

Turns out that the error was pretty easy to fix.  The error was telling me that it couldn’t open one of my content databases.  Luckily the farm involved was small and really only had 1 production site, therefore I knew all the content db names and this was one of the content DB’s I had created when working with MS support on an unrelated issue.  The database wasn’t needed anymore and since the client had some pretty tight DB standards in place they had deleted the unneeded DB but I never deleted the web app/site collection that referenced this DB, therefore I got the above error.  So the fix was easy…go into Central Admin, delete the problem web app/site collection referencing the content DB, then run the config wizard again.  After running it this time, it ran through to completion and I was a happy man.  All in all it was about a 45min set back after all the digging and running config wizard.

For some reason when I read those first words I throw my hands up and think of the movie Highlander

Yet another pain in the arse error message I hit…[Microsoft.SharePoint.SPException] = {"There can only be one instance of this list type in a web.\n\nAn instance already exists."}

Awhile back when doing some custom list development, I recalled that you could set property to basically say that one and only one instance of your custom list type could exist within a site (Unique=”True”).  See Below for what I am talking about. 

<ListTemplate Name="MyNetworkMembershipList" DisplayName="My 

Network Membership List Template" Type="100" Description="Template 

for My Network Membership Lists" BaseType="0" 

OnQuickLaunch="True" SecurityBits="14" Sequence="410" 

Image="/_layouts/images/itgen.gif" Unique="True" 

DisableAttachments="True" Hidden="False" HiddenList="False" 

FeatureId="{GUID}" />

Apparently with blog sites you can’t have both content approval and versioning turned on for a Post list.  Of course the client wanted both turned on, so I turned to writing an event receiver to handle the add/update/delete events so that I could basically create a “version” list that would live behind the scenes for legal purposes.

I started out by writing the event receiver to handle the added/updated/deleted events and to basically take the Post listitem and “copy” a version of it to my version posts list…easy enough.  I then obviously had to add code in my feature event receiver to create the versioned post list if it was already created.  I tried to do the following:

Guid newListId = web.Lists.Add("BlogPostVersioningList", "Blog Posting Version 

List", SPListTemplateType.Post);

Turns out that the list type “Post” is one of those lists in a blog site that is set to be Unique.  I deceided to take a look at the blog site definition and see if I could verify this.  I dug into the 12 Hiv, 12\TEMPLATE\SiteTemplates\Blog\Xml  and opened “onet.xml”.  A few lines down I noticed this line:

<ListTemplate 

Name="posts" 

EnableModeration="True" 

DisplayName="$Resources:core,posts_schema_blg_title;" 

Type="301" 

BaseType="0" 

OnQuickLaunch="TRUE" 

FolderCreation="FALSE" 

AllowDeletion="FALSE" 

Unique="TRUE" 

DisallowContentTypes="TRUE" 

SecurityBits="11" 

Description="$Resources:core,posts_schema_blg_description" 

Image="/_layouts/images/itposts.gif"></ListTemplate>

BOOM! Tough Acting Tenactin! As you can see above, “Unique=’TRUE’”, hence the error message I got.

So..now that I know I can have only 1 list of type Post….what the hell am I supposed to do?  Since the columns in the Post list were information that I wanted to keep, I decided to basically create a generic list and then “synch” up the fields between the Post list and my new generic list, resulting in a version list that I could then move my posts to from the SPItemEventReceiver

Guid newListId = web.Lists.Add("BlogPostVersioningList", "Blog Posting 

Version List", SPListTemplateType.GenericList);

At the end of the day, I now have a feature that creates a “Versioned” Post list and attaches an Item event receiver to move blog posts on add/update/delete over to my “Versioned” Post list for legal purposes.

So I set off to write a custom SharePoint feature for a recent client project to adhere to best practices of course.  I wanted to make sure that my custom feature was easy for the average joe with notepad skills to modify, so I made sure to add some app settings keys to the web.config so that my feature could read from them and be easily changed.  For some reason, and I’ll chalk this up to a bad example I found when I was first learning about using the SPWebModifications, but in my code I called the “SPWebApplication.WebConfigModifications.Clear()” method.

Originally I started this feature off from another feature where I used this.  The other feature had been deployed on a site with no other customizations, so the repercussions were not felt until now.  Turns out that by calling the Clear() method, you end up clearing ALL web.config changes, whether you made them or not.  According to MSDN the web.config changes are stored in the content db and this call will clear out ALL of those since it is a collection at heart.  This happened when I installed a feature on a site that already had CKS:EBE installed (CKS:EBE  is a feature itself), I got error messages and the CKS:EBE no longer seemed to be working although it was activated.

I figured it out by taking a clean site, activating CKS:EBE and then taking its web.config and backed it up.  I then activated my feature and took a copy of the web.config.   I then used a diff tool on the 2 web.config and noticed that the web.config AFTER my feature no longer had the CKS:EBE web.config changes.  I then look at the “WebConfigModifications.Clear();” and commented it out and noticed that it no longer took out the CKS:EBE changes.

Moral of the story is to make sure you know what your doing when calling the WebConfigModifications.Clear() method, chances are you REALLY don’t need to call it.

FYI…Looks like I am not the only one who goofed this up http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/thread/864dd894-c4cb-4815-a3de-8717d38da5ae/