Partilhar via

Getting Ready for Office "12"

  • Artigo

If you are a CMS or SharePoint customer and you're already starting to think about the next version, then that's great. The next version is coming out second half of CY 2006... with a public beta in Spring 2006. While there's been a whole lot of information (PDC, IT Forum, MVP Summit, Blogs) on the features and functionality of the next versions, there's been less talk about how to get ready. So here are a few things to keep in mind:

SharePoint Products and Technologies solutions
First thing you need to do is read the reusability whitepaper at https://msdn.microsoft.com/sharepoint. Above and beyond that, the design goal for VNext is to have backward OM compatibility => what you develop today will work with the next version. A few things may change with the API, but for the most part, you're looking at a smooth upgrade. What you really need to keep in mind is what you are developing and how you are developing it. A couple are some examples of what you should be planning/keeping in mind:

1. Don't touch the database. Modifying is a big no-no... reading it -- there's no guarantee that the schema will be the same. If you want to ensure a smooth upgrade, don't touch it or use partner technologies that modify the database.

2. Don't modify out of the box files/directories/stylesheets, et cetera. Whenever possible, you should be creating copies and then modifying vs. modifying the out of the box files. Service Packs or future versions can overwrite files and you can lose your customizations. Net/net: follow customization guidelines!

3. Get on the latest Service Pack = Service Pack 2! A lot of people I speak to say "but we don't want to move to SQL Server 2005"... and that's fine. You don't have to. SP2 supports Yukon but has a lot of other fixes.

4. Planning custom development. There's a lot of good stuff coming in the next version, such as the recycle bin, single item security, RSS enabled lists, workflow, et cetera. With the next version 1 year away, you need to ask yourself whether or not you want to invest the time in developing functionality that doesn't exist today but will exist tomorrow. Some places, it will make sense; others, it may not. Just something to keep in mind... make a plan, figure out what's business critical.

5. Partner technologies. This is something that requires planning on your side and something that requires a conversation with the partner. There are many partners that are part of our partner TAP programs and Beta 1 program so they are very well aware of what's happening and already preparing. There's no white and black answer - depends on your business need and what the partner is planning to do. Many of the strategic partners are working with us already. :-)

Content Management Server (CMS) solutions
Read the reusability whitepaper at https://msdn.microsoft.com/cmserver. Here are things you need to keep in mind for getting ready for the next version. I have already blogged a little, and will blog in detail later, what the next version looks like... here is what you should be thinking about:

1. Don't touch the database. The O12 CMS schema changes significantly. I am aware of several customers who touch the database b/c of API completeness in CMS 2002 in the area of user permissions... but don't do it. There are work-arounds... and I know Stefan has blogged about quite a few. They may not be ideal, but you don't want to have problems moving the data to the next version b/c you changed the database. BTW, if I haven't said it before, we will address the API incompleteness areas in the next version. :-) Also, while this isn't the case for MOST partners, there is at least one partner that I know modifies the database... IT Hit. So if you are using their product, double check... last I heard, they were modifying the database. If that's the case and you are their customer, my recommendation is to disable the feature that modifies the DB.

2. Install the latest Service Pack - SP2. And, if you are doing new development on CMS, consider using some of the new supported ASP.NET 2.0 ("Whidbey") features supported by SP2. In particular, master pages... in the next version, we really take advantage of master pages... so you want to start now. Again, even if you don't move to Whidbey or SQL Server 2005 ("Yukon"), you still want to install it for other fixes. Again, Stefan has done an excellent job with writing several super useful articles on CMS SP2.

3. Modular code. The Reusability whitepaper does a good job walking through the different concepts... write modular code. The API for next generation capabilities will change so you want to keep your code well-factored. Again, at msdn.microsoft.com/cmserver under the Technical whitepaper for CMS 2002 node.

4. Keep using it! We are going to provide out of the box data migration tools... so all the postings, custom properties, security groups, channels, et cetera, will move over to the O12 CMS schema.

5. Check out Office "12" Public Beta @ Spring 2006. We will have a lot of detail on what the migration process looks like along with tools and guidance well in advance of Office "12" release.

6. FAQs: What about the Telerik edit control? What about CMS Rapid by Artemis?
   Telerik: I will defer future plans for Telerik to Telerik. :-) As for migrating from the current CMS 2002 solution w/ a telerik control to VNext, it should be straightforward. Telerik's implementation doesn't touch the database, uses the underlying CMS placeholder architecture and is simply a server control that can be replaced... So shouldn't be an issue moving to VNext. I suspect, but can't confirm, that Telerik will develop similar components in the Office "12" timeframe. On a related note, you may want to consider taking a look at Telerik's Navigation controls that build on the Whidbey nav provider model...again, we are supporting the nav provider model in VNext as well as in the current version with CMS SP2. One option worth exploring, if you are doing new development, is to use the nav provider Stefan has developed for CMS and some of telerik's rich nav controls. :-)

  CMS Rapid: To my knowledge, CMS Rapid doesn't touch the DB directly. This means the out of the box data migration to the new schema should work just fine. I can't speak to the other aspects of the CMS Rapid solution and defer the details to Artemis. I know that Mark Harrison and Angus Logan are frequent bloggers of rapid and might have more information and links from their blogs.

Comments