For example, a SharePoint Web Part might display information contained within a database or allow users to access their email directly through the portal site. In any case, Web Parts are typically server-side components that render HTML code that a user's Web browser can display.
I recommend testing all of your custom Web Parts with ASP.NET 2.0 before you think about performing an upgrade to SharePoint Server 2007. Once you're convinced that all custom Web Parts are working, you can begin planning the upgrade.
Although SharePoint comes with several built-in Web Parts, many organizations develop custom Web Parts for specific business processes within a portal site. This can be a problem. Although built-in Web Parts typically work after an upgrade from SharePoint Portal Server 2003 to MOSS 2007, custom Web Parts will cause problems and you may need to recode them. Fortunately, there are guidelines you can use to determine how much work is needed to upgrade from SharePoint Portal Server 2003 to MOSS 2007.
Because SharePoint Server 2007 is based on ASP.NET 2.0, using the ASP.NET 1.1 obfuscation tool requires that you rebuild your custom Web Parts using ASP.NET 2.0. To determine if you're going to rebuild your Web Parts, test them in ASP.NET 2.0 before migrating. Doing so will tell you which ones you must rebuild. Even if you don't need to rebuild individual Web Parts, you will likely have to redeploy all custom ones.
Custom Web Parts can be included in either virtual server-specific \BIN folders or the server's global assembly cache. It's important to know where they are located, because their location affects the MOSS 2007 upgrade, especially if you're performing a gradual upgrade.
For a gradual MOSS 2007 upgrade (instead of an in-place upgrade), custom Web Parts stored in \BIN folders won't be included. You must redeploy your custom Web Parts after the upgrade is complete. Web Parts stored in the global assembly cache are upgraded, but lose their registration during the upgrade and must be re-registered.
It might be tempting to perform an in-place MOSS 2007 upgrade. Any time you perform one, Web parts are upgraded automatically; associated Web part registrations are retained.
Another situation that requires re-deploying custom Web Parts is moving to a new SharePoint server farm and using the database migration path for the upgrade. In such a case, you must re-deploy your custom Web Parts into the new server farm.
About the author: Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit his personal Website at www.brienposey.com.
Do you have comments on this tip? Let us know.
This was first published in April 2008