Corey Roth [MVP]

So you become a pro SharePoint developer, you’re great at making solution packages, but now you’re feeling lazy and want to cut out a few steps when you’re just making some changes during development.  This post is for you.  In reality, the best way to deploy your web parts and other custom code is using a solution package with a feature.  Deploying solution packages can take quite a bit of time.  If you’re just changing one line of code, do you really need to go through the hassle of deploying a solution package every time?  The answer is in fact no as long as you are careful and are willing to deal with the consequences should anything go wrong.  Most of the scenarios we are talking about today assume you have a solution package built and you have deployed it at least once.  We’re just talking about how you can make development faster on subsequent code changes.

One thing I will point out before we start is that if you are in a farm environment, your changes must be deployed to all front end servers.

Web Parts

Updating a web part is pretty simple.  All you need to do is copy the assembly to wherever you deployed it to (GAC or bin folder).  Your .webpart file does not need to be updated unless you have made changes to it.

Web Parts Deployed to the GAC

Although, I try to put as little in the GAC as possible, some things just have to go there.  If you have made a change to your web part’s code, you can easily just copy the assembly out of your project and put it straight in the GAC via the C:\Windows\Assembly folder.  Don’t forget that SharePoint caches assemblies in the Global Assembly Cache, so you need to recycle your application pool of any web application that is using your web part on each front end server.  You can just do an iisreset, but an application pool reset is a bit faster.

Web Parts Deployed to the bin folder

If you are deploying to the bin folder, ghetto deployment is even easier.  Just copy out the DLL to the bin folder of your web application and you are good to go.  No application pool reset is necessary.  If you do make significant changes and your code requires different permissions, then you will need to deploy with your solution package so that you can specify an updated CAS policy.

Pages and User Controls

If your code behind changes, then the rules above for web parts apply.  Just copy out the binary to the deployment location.  If you made changes to a .aspx or .ascx file, these files can simply be copied out to the 12 hive (LAYOUTS folder for pages and CONTROLTEMPLATES folder for controls).

Event Receivers

The binaries for your event receivers can also be copied out directly to the GAC.  Just like with web parts, remember to reset your application pool to avoid caching issues.

Workflow

Workflow can also be deployed directly to the GAC.  If you have any changes to what forms are registered or anything else you will need to deploy it regularly though.

Some of this may have seemed obvious, but I have had a few developers ask me questions like this when starting out.  Of course if anyone goes wrong, just start open, retract your solution and redeploy it the correct way.  Hopefully, though you can use some of these tips to speed up development when you are making lots of changes.  No one likes to sit there and wait for a solution to deploy.  Have any other tips?  Leave a comment.