Package and Deploy
<moan>
Package and deploy
How would you do it?
Imagine you've just created a new website and want it to be pluggable for others. In a way that others could add new features to your solution. How would you do it?
Files
As with every feature for this web application you'll probably have some files to deploy. Can be images, can be .ascx and .aspx files etc. With this files come the need to specify which files to copy and where these files should be copied to. So we need some sort of settings file. I can imagine a user interface where my application asks for the filecopy.xml and after reading this filecopy.xml automatically copies the nececary files to the nececary directories.
Assemblies
It's basically the same with assemblies. What we do need to take care of though is that assemblies should be registered in the GAC or copied to the 'bin' directory. So maybe we need to have some other settings file. Let's call this file assemblyinstall.xml.
Visibility
So far so good, but how about visibility? Nice that we have copied some webforms and some dll's but where to place a link to that newly added pages? Maybe we need some settings for that als well. You know what? Let's call this feature.xml.
Refactor
We've already decided what we need, but this can be refactored a little bit. Let's start by combining these 3 settings files into just 1. And let's call it our manifest. So we have a file called manifest.xml that contains settings for where to deploy the assemblies, where to deploy the files and where we can find featue settings files.
Happy?
Nice but I'm not really happy. What if my web application spans multiple frontend servers? I do not really want to copy this folder to all frontend servers and execute the installation manually. So maybe we can zip our solution and place it in a central database? That would be very easy. Another good thing about this is that an installed solution can be uninstalled again because all the files, including the settings files, are in my database. So we can install and uninstall the solutions without being afraid of leftovers in the system!
Problems that can rise
If you do not deliver any good documentation on how to create your solution package developers will fall back to the things they know that will work. They'll start to copy all these files manualy and they'll blog about it. They'll write tutorials on how to copydeploy a solution to your web application. Once a few people decided to do it this way others will follow. Not because they are bad developers, but because they don't know any better.
SharePoint
If we take a look at SharePoint you'll see that the SharePoint Team probably followed the exact same path, unfortunately the copydeployment problem included. Windows SharePoint Solution Pack is nothing more than a cabinet file(some sort of archive) that contains all files to deploy. The assemblies, webforms images etc. plus the manifest.xml file and feature.xml files. It's not always an easy job to create such a Solution Package but there are tools that do help you a lot such as the famous WSP Builder.
Conclusion
If you have read this post you now know that there's a good way for deploying solutions to your SharePoint environment. You now know that handcopying files is absolutely not necesary and definately not a smart thing to do because you'll loose your rollback scenario and it's very error prone. You now know that handcopying files is just for those that do not want to evolve or learn something new aka 'the unprofessional developers'. Keep that in mind when you write your next turorial or deliver your copydeployment script.
</moan>
Cheers,
Wes