Upgrading SharePoint web parts

Question

I have several custom web parts that I'm in the process of deploying to production. During this process I've found a handful of minor things that need to be tweaked in the various parts. To deploy the new code I create a new solution package, deactivate then delete the features, retract then delete the solution, then do it all again in reverse order with the new package. Needless to say, this can be time consuming. Is it necessary to completely remove a web part in order to upgrade it, or can a web part/feature/solution be upgraded in place?

Answer 1

We have used Visual Studio 2008 extensions for Windows SharePoint Services 3.0, v1.3 - Mar 2009 CTP. It has given us some problems, but when you get used to it and make sure that you do things in the right order it works.

http://www.microsoft.com/downloads/details.aspx?FamilyID=FB9D4B85-DA2A-432E-91FB-D505199C49F6&displaylang=en

This tool automates the retact / delete / deploy / activate .... job.

Another thing that we try to do is to keep as little functionality in the web parts as possible. Move what can be moved to separate dll's, then it is often possible to upgrade just by coping in a new version of the dll.

Answer 2

It depends on what exactly is changing in your solution. There is an stsadm operation specifically for upgrading solutions, but it has some limitations as far as what it takes care of for, most notably the removing of old features and adding of new features. However, if all your new functionality exists in the webpart DLLs, running a solution upgrade will deploy your changes without need for you to do anything further.

http://msdn.microsoft.com/en-us/library/aa543659.aspx

Answer 3

If you are making minor changes to your web parts then you can just replace the DLL's if the assembly version remains the same.

Of course use some discretion here about what is a minor change and won't break anything.

See this topic for how to use FileVersion and AssemblyVersion correctly.

Basically you keep the AssemblyVersion the same for minor updates while the FileVersion changes with ever compile.

This is exactly how Microsoft do it with things like Microsoft.SharePoint.dll - the AssemblyVersion is fixed at 12.0.??? while the FileVersion changes with every hotfix/service pack.

Oh - I just read the "Production Part" of your answer this shortcut may be more appropriate for Dev/Test rather than QA/Production