Apparently, this is not a good idea. If we need rebuild the site from scratch, that means you have to repeat step 1-4 again. So, put on developer’s hat:

My first thought is to add Sharepoint default Scheduling Start Date and Scheduling End Date site column to the base content type. I have my content type xml already, so I added the following

    <FieldRef Name=”SchedulingStartDate”
    DisplayName=”Scheduling Start Date”
    ID=”{51d39414-03dc-4bd0-b777-d3e20cb350f7}”
    />

   <FieldRef Name=”SchedulingEndDate”
    DisplayName=”Scheduling End Date”
    ID=”{a990e64f-faa3-49c1-aafa-885fda79de62}”
    />

The only trick is how to find the default guid. Go to site setting->content type->click any of the site content type include above fields (for example: Generic Content->Scheduling Start Date). The browser address bar ends like Fid=%7B51d39414%2D03dc%2D4bd0%2Db777%2Dd3e20cb350f7%7D, replace %7B with “{“, %2D with “-”, %7D with “}”, the guid is {51d39414-03dc-4bd0-b777-d3e20cb350f7}.

Well, build and deploy, those 2 fields successfully added to my base content type. But wait….this does not solve my problem yet. Oops, those 44 document/list library does not change at all because they are there ALREADY….my changing of base content type only work for those NEW document/lists, not for the existing one. Rather than write your own code, Sharepoint actually has a option to let you update all inherited content types when you add/delete site column from its parent content type. You could go to site setting->modify site setting -> content type -> select the base content type -> add fields from existing site column. Make sure “update inheritate content type” check box is checked. Also, do this manual step before you install the solution. Ok, the 2 extra fields were added to all the document library after this…(in my case, all content library inheriated from the base content type). But, to enable scheduling, you have to enable versioning and scheduling. Instead of do it manually, I decide create a feature to loop through all document library and enable scheduling.

To be continue…

      <PageParserPaths>
        <PageParserPath VirtualPath=”/en-ca/pages/*” CompilationMode=”Always” AllowServerSideScript=”true” />
      </PageParserPaths>

I found this is very useful during development if you are using in-line script for your aspx pages. Let’s say you have a SP project including some customrized aspx pages. You’ve created feature and a wsp file to install in your Sharepoint. Now you noticed you have to do some change to the in-line script of the aspx file. Of course, you could re-deploy the entire wsp again, but as a developer, you don’t want do this because most likely you have to modify the aspx again and again …Following is the steps I am using

1. Load aspx pages from Sharepoint UI and publish it
2. Reset IIS
3. Load this aspx page from your browser

Sharepoint will give you error message saying server script is not allowed. OK, that’s fine, modify web.config add <PageParserPaths> and reload the page. Yeah, everything is working and you can see your changes.

Someting you should also know

1. It is better using code behind for the aspx pages in your SP project. By using code behind, when you change any logic of your aspx pages, you only rep-deploy dlls, not the page itself. You don’t need modify web.config.
2. Why this does not happen before you change and load the aspx page to the SP? That page also contains script, but SP did not give any error at that time. I will explain this in my next post “Sharepoint ghost”

If you using Visual Studio to design/develop Sharepoint solution, keep in mind you suppose using only ONE solution for your entire Sharepoint project, that is, only ONE .wsp file will be created for your Sharepoint deployment later. By doing this, usually more work for your team is required but will make your deployment much easier and you could also automate your Sharepoint deployment in the future. This article is about how to organize your Sharepoint solution based on my experience.

Organize your Sharepoint solution

Sharepoint solution usually include

A: Sharepoint “base project”
Your Sharepoint soluiotn is based on this project. This project will handle all the Sharepoint envirnoment. For example: Site column, content type, page layout, master page, list, document library, event handler, managed property, search scope, site definition. Be patient and be careful because this is the backbone your application will establish on.

B: Sharepoint “UI project”
This should include web parts, ASP.NET controls, AJAX controls, delegate controls, css and resource files. I would also include any third party controls into this project if there is any.

C: Sharepoint “BI project”
This is business interface and logic project, including your business UI, logic and all your .aspx pages. In visual studio, you probably need seperate this into several project. For example: a database layer project, a business logic layer project, a user interface layer project, a workflow layer project

C: Sharepoint “support project”
This project is to support your solution. This maybe vary depend on what you need. For example, you may need
a feature/function to import some data to the Sharepoint list
a function to help you manage users.
a page to allow your client upload XML files to the server
a function to allow you import/export your Sharepoint keywords
a unit testing project to test your custom build function

1. Backup your sharepoint content database from sql server
2. Go to Sharepoint Centre Admin->Application Management->Content databases. Locate your sharepoint application and remove the content database. This will basically break the link between your sharepoint application and your content database. If you don’t do this, the link always exists and you will not be able to restore the content database later because sql server thinks the content database is still in use, and you will find you can’t kill that process in the sql server.
3. Delete and recreate you local sharepoint content database ( what? r u crazy? )
4. Restore the content database you did in step 1
5. Go to same place as step 2 and attach the content database. Note, you might get a error message saying the sql database collation is not correct, it is because your sql server default collation is different than what sharepoint required. Go to step 3 and create the database as request by choosing collation Latin1_General_CI_AS_KS_WS.
6. Reset IIS
7. It’s better re-deploy your sharepoint solution but this may not necessary
8. Don’t forget reset sharepoint site collection administrator

Few problems you might notice when you access your sharepoint application.

1. Make sure disgard checked out files, otherwise site collection adm will get error when visiting those pages.
2. Any search settings such as scope, managed property, keywords will not restore
3. I don’t have a chance to try this on multiple content database scenario, it might not work properly if that is the case.

That’s it, this is just an alternative way to backup/restore your sharepoint content.