3

I know that when we deploy farm solutions then they are available under Central Admin --> System Settings --> Manage farm solutions.

In this list of solutions, there are 3 columns. Name, Status and Deployed to. I have noticed that the Deployed to value is dependent upon the powershell you use to deploy the farm solution.

Example:-

  1. This deploys to GAC and Globally: install-spsolution -Identity $solution -GACDeployment -Confirm:$false. The solution dll will go and sit under GAC.

  2. This deployed to GAC and to the web url: install-spsolution -Identity $solution -WebApplication $oUrl -GACDeployment . The solution dll will go and sit under GAC.

  3. If we used the foll. powershell: install-spsolution -Identity $solution -WebApplication $oUrl . The solution dll will go and sit under inetpub/weburlport.

I would like to know specifically, when do you choose option 1 or 2 or 3? Ideally, I would like to know the impact that each of the above example will have when the feature is scoped to Farm/WebApp/SiteCollection/Site respectively...

  • What is your question? It is a very open ended one right now! – Robert Lindgren Mar 1 '14 at 11:02
  • I would like to know specifically, when do you choose option 1 or 2 or 3? Ideally, I would like to know the impact that each of the above example will have when the feature is scoped to Farm/WebApp/SiteCollection/Site respectively... – variable Mar 3 '14 at 4:43
3

I can't find a resource on this atm, but the main differences are:

  • if your solutions contains dll's it will ask to deploy them to the gac. I've personally not deployed them to a specific web app's bin folder yet.
  • if your solution contains webparts or other resources that require modifying the web app's web.config file, it will ask you what web application to deploy it to (or maybe all of them, but this is not the same as "globally deployed")
  • globally deployed indicates the solution did not have web app specific resources.

The gac is the central location for deploying dll's and the most common way for accessing 'external' dll's in sharepoint. For example, you can use dll's in one solution, but they may actually have been deployed by a different solution.

I believe there are other resources that are web app specific but the most common example are webparts because they need to be added to the safe control list and these are in turn added in the web.config file. I believe this is only the case when you usd custom webparts with custom code, because they call a custom dll. You will see a descriptive error on your webpart when they weren't added to the safe control list.

You should note that whatever web app you deploy your web app specific solution to, your features will still be available to all web apps, they will just be missing some needed resources or configuration should you enable them somewhere where you haven't deployed the solution.

EDIT:

To answer on your comment to your question (when do you choose what option to take), you really don't. This is a fault of the SharePoint API I believe, as it really does not matter to me (the SP Admin) what kind of Solution it is, I just wish to get it deployed. All this info is on the SPSolution object and it can be dynamically decided what action needs to be taken. The only exception being, if you do not wish to deploy the solution (should it contain web app specific configuration) to all web apps but just some or the "one".

In any other case, there really is no difference and you cannot even make a choice, since it either does or does not deploy dll's to gac, and it either has or hasn't got web app specific configuration.

EDIT2: Seems like I missed a part of your question there:

What's the impact of Farm/WebApplication/SPSite/SPWeb scope of a feature ?

Well, the answer's in the question really, the scope of the feature. You kind of have to think about what you're changes are applied to.

  • Content Types / Site Columns
    • Very good idea to have the feature that deploys these SPSite scoped, since you'll want them available in the whole Site Collection.
  • Application Pages
    • I don't know by heart what the best practice is for these, but I would make them Farm Scoped (since essentially, they'll be available through the _layouts/_admin virtual folders, which is accessed from across the whole farm.
  • Web Application Configuration
    • This one seems obvious ;)

Here's another article that sums it up nicely: http://www.pritambaldota.com/index.php/understanding-features-and-feature-scope-in-sharepoint-2010/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.