Advantages and Disadvantages of using SPPersistedObject over Web.Config files

Well, only a few days back I had a chance to look at SPPersistedObject when I was looking at a source code of a solution in Codeplex. Since then I started feeling that I should have known about it a long time back so that I could have used it in all my previous projects.

If you have not used or even heard about SPPersistedObject kindly have a look at this here which describes on how to use it.

In my previous and current SharePoint projects we always used to store the configuration entries in the Web.Config file of the SharePoint web applications hereafter. And, once the application goes for production we lose our access on the web.config file to the support team which has been giving me a headache all these days because of which I have decided to use SPPersistedObject in my applications. So, I have decided to list out the advantages and disadvantages of using SPPersistedObject.

Let’s go for the advantages first.


  1.  Whenever you change any value in the Web.Config file of the SharePoint application, you need to change it both in both the WFE’s(if at all you have more than one :D) of your farm. Whereas, while using SPPersistedObject this is not the case as the value is going to be stored in the Configuration database.
  2. Whenever you change any value in the Web.Config file of the SharePoint application the App pool of the SharePoint application gets recycled which is not the case while using SPPersistedObject as the changes in the Configuration database is not going to affect the App pool of the application.
  3. When applications using web.config file entries are removed from SharePoint, the web.config file entries of the application remain as such until they are deleted manually. Whereas, a SPPersistedObject can be deleted using SPPersistedObject.Delete() method.
  4. Moreover, so many people might develop applications with respect to your SharePoint site and store their configuration entries in the web.config file which sometimes can become misery when someone else is also using the same configuration entries as you are.
  5. Suppose your SharePoint application has been deactivated and no longer used, the web.config file entries used by that application will always be present unnecessarily unless and until they are deleted manually. Whereas, in the case of SPPersistedObject we can delete the SPPersistedObject object from the configuration database as shown here in the feature deactivation event receiver.
  1. When you are going to use SPPersistedObject, then you need to write a separate custom class in order to add and retrieve the config entries. Whereas when you are using web.config, the entries can easily be accessed using Configuration.Appsettings property in System.Configuration namespace.
  2. The custom class written in order to add and retrieve the config entries cannot be reused for all the applications that you are going to develop. You need to write a separate custom class for each application.
  3. This class is not available in Client Object Model. SPPropertyBag can be used in that case.
So, these are the advantages and disadvantages that I have in mind right now. Will update whenever I face something new while I use it and explore SPPersistedObject more.

Do you get “The Web application at http://sharepointsite could not be found. Verify that you have typed the URL…” exception when you host an ASP.NET web application in a SharePoint site

Writing a blog after not quite a long time :D. Well, these days I went back in to working in MOSS 2007 :/ that to working in an ASP.NET application for the first time.

After finishing the development of the application in the development server, I was able to successfully host in the QA server too with the help of my support team. But, when I hosted it in the Production server after having a huge argument with one of my support team members about the deployment process, I was getting this exception saying “The Web application at could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application“.  Exception Message: FileNotFoundException.

I know that this error comes in a SharePoint 2010 environment when you execute a console application accessing a SharePoint site is in 32 bit instead of 64 bit mode. But, I was wondering how could this exception come in MOSS 2007 environment that too in a console application, that too when you are trying to host an ASP.NET application.

Was getting perplexed like anything even after googling where few blog posts tell to try with a different URL of SharePoint site sing Alternate Access Mapping.

After lots of debugging and redeployment, we found that by selecting the properties of the virtual directory created for the web application was running under the Default App Pool instead of the SharePoint Application’s App Pool as shown below.


So, whenever you get an exception like this in your web application, make sure that your application is running under the correct App Pool. I was finally able to make the application up and running by changing the App Pool as shown below.