Feature activation through VS

Posted on 2013-09-14
Medium Priority
Last Modified: 2013-09-15
Just a theoretical question to confirm what I have seen. Easy question

I have been taking vid courses that do things, but don't explain what is really going on theoretically

I have created a feature that deploys a list instance.

I have a team site at the root, call it root site and another blank subsite under it, call it site 2

I am deploying an announcements list from VS

It is scoped to web

I am using the default deployment settings. When the deployment address is the root site, it adds the feature and activates it under site features (not site collection features). But when i go to the subsite, site 2, the feature is there under site features as well but not activated.

I thought that since it deploys it to every site, it would activate it as well since the deployment settings say so. Clearly it does not.

Changed the deployment address to point to the subsite and next deployed there.

It activates it at the subsite level. Creation date of list shows as just created

Creation date of same list on root site shows it as created in the past when I deployed to the root site and automatically activated it during previous deploy, and it still shows as activated

So when I scope a feature to web, does this mean the feature gets added to every web (subsite) but it only gets activated at the site I deployed to, even though the default deployment settings are for activate feature? Is that how this all works?

Also, does it mean that if I scope this feature to "site", it means that the feature will not only appear on all webs (sites) but also activate?

Besides the feature showing up in site collection features if I scope to site, and show up in site features if I scope it to web, does this also mean that it will activate on all sites if my deployment settings call for activation and my scope is site but not activate on all site if I scope to web?

It seems like the feature will show up on all sites either way, but is activation a key difference between site scope and web scope aside from whether it shows up under site collection features or site features?

I need to make sure i understand this.

Question by:BobHavertyComh
LVL 44

Accepted Solution

Rainer Jeschor earned 2000 total points
ID: 39493988
Hi Robert,

this feature is part of a SharePoint solution (WSP package)?
It is not required but for deploying features on multiple servers (frontend/app) it is recommended to use SharePoint solution packages. A feature only installation is scoped on the server (as there is no url parameter)
(see MSDN)

So lets start from the beginning:
Custom features are normally packaged into SharePoint solution files - if not then they are "deployed" by simply creating a folder with the feature name in the feature subfolder of the SharePoint hive (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\1x\Template) and placing the feature definition files there.
There are two types of solution starting with SharePoint 2010 - farm solutions and sandboxed solutions. Lets talk further on the farm solutions.
A SharePoint farm solution could be either deployed globally or to specific web applications.
Features can be scoped at  Farm (farm), WebApplication (Web application), Site (site collection), Web (Web site) level.
This only means that depending on the scope, you can activate/deactivate a feature through the browser UI (or Powershell) either in central admin (Farm and web app), site settings -> Site Collection Features (Site) or in the site settings -> Site features (Web).
You have to take care on what post-build / deployment steps/commands Visual Studio is executing.
In your case:
By default, Visual Studio runs a Deactivate, Retract, Remove, Install, Deploy and activate on SharePoint solutions and features.
You have a feature deployed into the feature subfolder. Then it will be available for activation/deactivation in every web app/site/web of your SharePoint farm/server (depending on your scope).
As you deployed and activated the feature first on the root web, then changed the url to the sub site, the next deployment tried to deactivate the feature on the sub web (which has not been activated there before), then VS deployed the feature files and then activated the feature on the sub site - hence you have the feature now activated both on the root web (with the initial timestamp) and the sub site (timestamp of last deployment). VS activates the features not on all sites/webs but just on the deployment target url. Therefore if you change the url, you should run a undeploy before - just to get the features deactivated (or do it manually).

So the scope of the feature just set where the feature is available/visible - VS settings set where the feature gets activated.


Author Closing Comment

ID: 39494104
Thank you for the extensive explanation. Sorry if my question wasn't a little more concise, but I wanted to make it as complete and clear as possible. Your last sentence was actually the answer to my question, and it is what I suspected and have seen for myself, but I wanted some expert confirmation of this as I need to have a really solid understanding of this.

So while scope involves where the feature will be visible for activation, the specific deployment address in VS is what determines where it will actually be activated, assuming activation is even part of the deployment settings.

If I am still incorrect, please correct me, but I think I get it.

Thanks again.

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

If you create your solutions on SharePoint sooner or later you will come upon a request to set  permissions of the item depending on some of the item's meta-data - the author, people assigned as approvers, divisions, categories etc. The most natu…
The vision: A MegaMenu for a SharePoint portal home page The mission: Make it easy to maintain. Allow rich content and sub headers as well as standard links. Factor in frequent changes without involving developers or a lengthy Dev/Test/Prod rel…
In this video I will demonstrate how to set up Nine, which I now consider the best alternative email app to Touchdown.
Watch the video of Kernel Migrator for SharePoint, which demonstrate the process easily of migration from SharePoint to SharePoint, OneDrive for Business & Google Drive servers, Public Folder to SharePoint, File Server to SharePoint. The tool has va…

597 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question