Discover an elegant technique for creating and deploying solutions that provide reusable processes for installing and uninstalling custom code.

WEBINAR:

On-Demand

f you've ever worked on more than the most trivial installation program, you realize that developing installers isn't for the faint of heart. After spending days or weeks learning about the MSI file format, how to assemble tables, and how to add dialogs, you're left with a collection of documentation that reaches from the floor to the ceiling, and you can feel just as lost as when you began. Further, the experience doesn't help much when you need to deliver the software in a silent or automated way. You need to acquire additional knowledge to handle automated setup files.

At first glance you might wonder why there's a feature in SharePoint Technologies called "Solutions." The Solutions framework seems to be a direct competitor with the Microsoft Windows Installer technology—and its MSI file format—but it isn't. Where the Windows installer is targeted toward client-side application installation, the SharePoint Solutions approach is targeted toward delivering complete solutions to SharePoint Servers.

This discussion will walk you through the deployment of a semifictional application, WFInspector, which is a workflow inspector tool. The tool itself is of marginal value because it doesn't add much functionality beyond what is available out of the box; however, it's very representative of the kinds of solutions that you may want or need to deploy.

Features, Web Parts, and Site Definitions It would be fair to ask why another "thing" is needed in SharePoint to deliver solutions. For instance, there's the now infamous SharePoint feature called "Features." Although Features is an immensely powerful technique for adding functionality to SharePoint, it isn't without its limitations. Features must be scoped at one level (farm, web application, site collection, or site), and sometimes creating a real solution requires more than one feature. In addition, it's sometimes necessary to deliver files for a feature outside of the Features' directory. If you need to deploy files into the _layouts directory tree, you've got files outside of the Featuresdirectory to track and deliver.

The setup just described is for delivering Features only. There are also two other items that people typically want to deliver, which aren't Features. Web Parts aren't deployed through Features, but they definitely have their own quirks concerning deployment, including code access security (CAS) policy, whether the assembly is delivered to the bin directory or to the global assembly cache (GAC), and the delivery of template Web Part files. Site definitions are a similarly complex item that require creating the site definition directory and adding the WebTemp*.xmlfile to the correct directory.

In short, there's no way to use Features to deliver complete functionality for a solution. There's more to it than that, and that's the reason why the Solutions mechanism was developed.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.

Thanks for your registration, follow us on our social networks to keep up-to-date