Deploying solutions to a specific Web Application

SharePoint solutions (non-sandboxed) can be deployed at two scopes;

• Globally
• Web Application

SharePoint has the annoying habit of forcing you to deploy globally whenever possible. When you try to deploy a global solution to a specific url you get the following message:
- This solution contains no resources scoped for a Web application and cannot be deployed to a particular Web application.

In almost all cases I want to deploy my solution to a single web application. This makes creating reusable deployment scripts much easier. It also adds logic to your deployment scenario's and farm solution overview in Central Administration.

Update
Another important reason to deploy to a single web application is that upon deployment, retraction or updating of your solution you can avoid restarting all application pools. This limits downtime, especially when you are not alone in your farm:

Avoid creating a lot of global SharePoint Packages and try instead to provision as much as you can to specific Web Applications. Every time you touch a global SharePoint Package all Applications Pools will be stopped/recycled. Although there are some scenarios when you can’t avoid creating global SharePoint Packages, you should try to avoid them

An interesting post by Waldek on the subject.
/Update

The trick is fooling SharePoint into registering your solution as a web application scoped solution. SharePoint checks wether there are items which have to be deployed to a specific web application when your solution is added to the solution gallery. One of the elements that SharePoint checks for are safe control entries. These have to be merged into a web.config for a specific web application. The easiest way to force deployment to a specific web application is adding a dummy safe control entry to your package.

Here is how you do that:



1. Double click the package
2. Open the manifest
3. Edit the options
4. Add you dummy data. In my solution I added the following:

<Solution xmlns="http://schemas.microsoft.com/sharepoint/"> 
 <Assemblies>   
  <Assembly Location="SharePointProject1.dll" DeploymentTarget="GlobalAssemblyCache">     
   <SafeControls>       
   <SafeControl Assembly="SharePointProject1,Version=1.0.0.0, Culture=neutral, PublicKeyToken=****************" Namespace="SharePointProject1" TypeName="*" />     
   </SafeControls>   
  </Assembly> 
 </Assemblies>
</Solution>

That's all there is to it. This solution will now only deploy at the web application scope!


Note: For MOSS this works the same. How to add the entry is a bit different depending on your wsp packaging tool. With STSDEV you can add the entry to the SolutionConfig.xml.

Exceptions when creating site columns based on local term sets

This blog is about a little known bug in SharePoint 2010. The bug manifests as follows:

When creating a new site column of the managed meta data type, and you select "customize your term set", you are presented with one of the following errors:
- This operation cannot be completed. The term store may be unavailable.
- Failed to read from or write to database. Refresh and try again. If the problem persists, please contact the administrator






Reason

When you create a site column, the first field is the title. This field is required, but you can start filling out the rest of the form before entering the title. When you choose "Managed Meta data", and then "Customize your term set", an empty term set is directly created for you. This term set is titled "Untitled". This term set is stored in the managed meta data service. Even when you rename the term set afterward, and give the site column a proper name, a reference to this "Untitled" site column is kept, linked to the url of your site collection. You can see this when you create a new column, and again don't specify a title. The suggested title for your term set will be "Untitled_1".

As long as you keep your site collection, this is not a problem. However, when you delete this site collection and create a new site collection at the same url, this reference causes problems. Because it was stored in the service application, it was not deleted.

It is always in the way when you try to create new site columns with customized term sets.


Solution
The only solution I found is creating a new Managed Meta data Service instance. You might want to delete the old one, with the corrupt data, but based on business needs this may not be an option. Remember to configure the new Managed Meta data Service instance with "This service application is the default storage location for column specific term sets" set to true:





If you don't, you'll get the following error:
"The default term store for this site cannot be identified"

Update: The first service pack for SharePoint contains a fix for the following problem:
- If a user creates a site collection, deletes it, and then re-creates the site collection by using the same name, the site collection group is not re-created in the term store.
If I'm not mistaken, this is a fix for the bug described here.