This time, I am not kidding - I have been really really busy. Either way, blogging is someting that I cannot ignore, it acts as my sounding board with the community, it validates what I know, and it gives me a place to reference for afterwards.
Here is the issue we are going to solve in this blogpost -
When deploying your site to production, or QA, or even development, you would typically use an install.bat, alongwith a feature.xml, alongwith other such peices. Okay, okay, you can also use a .wsp, but I am not going there yet.
In this blogpost, I am going to solve the specific issue of deploying a custom content type on production.
So here goes -
When you define a content type within sharepoint, it gives it an ID, that looks a bit like this - 0x01849100139somelongnumberhere9291. So here is tip #1
- You can get that content id from the query string on the ManageContentType.aspx page. You see this page when you are editing a content type.
Now, if you have defined such a custom content type, chances are that various things in your final site, such as document libraries, heck even custom URLs and actions will depend on that "ID". So you cannot "Point-Click" and create such a content ID in production, because that would break all your other twiddly XML files.
So, what do we do?
- Create a content type using point and click.
- Copy the ID, define the content type in XML this time around, using the schema mentioned here. (Okay here is a tip, all bullshit aside, it is easier to just go to c:\program files\common files\microsoft shared\web server extensions\12\templates\features\ctypes\ctypeswss.xml, and simply use that instead).
- Then create a feature.xml (you may include this in another feature.xml, but frankly I like to tie together feature.xml's using Activation dependencies). This feature.xml needs to look like this -
<Feature .. some crap here>
further reading on this
- Thats it. Go ahead and deploy the feature, and you're all set. You can now guarantee that appropriate content type ids are used wherever you go.