SharePoint 2007 Local vs. Global deployments

Technorati Tags: Sharepoint,Development,Deployment

Solutions are deployed in one of two ways: either locally or by using a timer service.
This applies both to new deployments, as well as to deployments of solution upgrades.
Both local and timer-based deployments can be triggered either by using command-line instructions or programmatically by using the object model.

Local deployments that are initiated from the command line by a user with administrator privileges run in the context of the administrator. If initiated by using the timer service, however, the deployment runs in the context of the timer job itself, which uses administrator pool account credentials. Either set of credentials should be sufficient to read and write to the configuration store.

Local Deployment

In a local deployment, solution files are deployed only to the computer from which the deployment operation was initiated. Under this scenario, the solution is not marked as "deployed" in the configuration database until the solution files are deployed to all applicable servers in the server farm. Then, in the case of new solution deployments, solution features are registered, and schema and definition files are committed to the configuration store.

Timer Service Deployments

In deployments that use the timer service, the deployment creates a timer job. This timer job is picked up by the timer service on each Web server in the server farm. The timer job uses the Windows SharePoint Services Administrative Web service to access appropriate privileges to deploy solution files to each computer.

Initially, manifest and feature manifests are parsed to find assembly and _layouts files, which are copied to the appropriate locations. All other files contained within a feature directory are copied to the feature directory. After solution files are copied to the target computers, a configuration reset is scheduled for all front-end Web servers; the reset then deploys the files and restarts Microsoft Internet Information Services (IIS).

For upgrades, the deployment has no impact to the end user experience. The new versions of the solution files do not overwrite the old files; therefore, if a computer is restarted, or the upgrade process is aborted, the servers are synchronized with their other data files.

Finally, for new solution deployments, solution features are registered, and schema and definition files are committed to the configuration store.

I recently cam acroos the following issue:

stsadm -o deploysolution -name "my_solution.wsp" –url "https://server.somedom.net" -local –allowGacDeployment

This command fails, the following message is displayed:

This solution contains no resources scoped for a Web application and cannot be deployed to a particular Web application.

While this command completes successfully

stsadm -o deploysolution -name "my_solution.wsp" -local –allowGacDeployment

When looking at the manifest.xml and feature.xml files for this package, we can figure out this package has no “resources”, which means no content has to be copied to a particular web application virtual directory.

The bottom line is that if your solution specifies elements (a.k.a. "resources") that need to be merged into a Web.config file (i.e. "for a Web application") then you must specify the url parameter. If your solution does not have an assembly or if your solution contains workflows, then you cannot specify the url parameter.

The same goes for packages that would not contain an assembly.