Tag Info

Hot answers tagged

20

Feature stapling is a tecnique that allows for a feature to be stapled to a site definition by using a support "stapler" feature that defines which features are attacched to which site definition. This allows for a feature to be automatically activated on a site created from a site definition without the need to modify the definition files (onet.xml). This ...


5

What is your feature doing? Depending on the modifications it makes in code it could touch either config and /or content databases.


5

The perfect site definition is empty. The built-in templates are useless in anything but the simplest solutions. Even if the customer wants exactly what is in the team site template, I still rebuild that as a WSP solution and deply using code. Code is the way to go, because it gives a mix of what the administrators want and what the devs need. the latter ...


5

rjcup, Your client is likely not the right entity to ask what solution is best. If you're the developer, then you should know best and if your client doesn't trust your judgement, then your client has a problem much greater than how to get something done. If that client knows more about SharePoint than you do, then you have a quite different problem as ...


5

Is your production a multi server farm? I think you are facing the following issue: http://blogs.msdn.com/b/calvarro/archive/2011/11/06/sharepoint-2010-amp-visual-studio-2010-error-ocurred-activate-features-feature-with-id-installed-in-this-farm-cannot-be-added-to-this-scope.aspx It turns out that VS 2010 internally implements a call to the method ...


4

Currently i prefer working with the "minimal site def" just to get an Id, and then use receivers to add the cool stuff. This is mostly due to the fact that I think I get the job done faster and that you can upgrade the solution easier (and in a supported way). I wrote a piece on this a couple of days ago Avoiding Xml Based SharePoint Features - Use The API ...


4

First of all, Start with a new feature to ensure everything is clean. Also, Please note that the configuration for Blank sites is configured(like below) to ignore any features stapled to the Global site definition.The same is true for some other site definitions as well. <Configuration AllowGlobalFeatureAssociations = "FALSE"...</Configuration> ...


4

Don't think it is possible (anyone, fell free to correct me). But you can always do the opposite - staple a custom feature and deactivate the target features from the custom feature event receiver.


4

As each my "mysite" is a new site collection using a Microsoft Site Definition, there is no no-code solution for automatically adding web parts to a page. (Well there is one no-code solution: Someone could sit in central administration add refresh the list of "mysites" and when he sees a new one he could log in and add the web parts, but I think that after a ...


3

You need to staple to SPSPERS#0 template. See this technet post.


3

By design ListAdded can be hosted by SPWeb or SPSite only as documented here. So Feature Stapling cannot be avoided if you want to enforce that across the farm. UPDATE: As per MSDN Documentation, If the Receivers tag has no ListTemplateId or ListUrl attribute, the event receiver is registered at the same scope as the Feature. Which means you should not use ...


3

It depends. Normally you can just set the ActivateOnDefault=False in the feauture. Otherwise you can add an EventReceiver containing code to "turn off" the feature(s) you want. You do this by opening your solution in Visual Studio > right click on the solutions top-level > Add new item > Event Receiver <-- By this stage a dialog will open in which you ...


3

Add these lines (inside the Elements tag) to an 'Empty Element' project item, then add that Project Item to a Feature (Scoped to Web Application, for example) in the solution.


3

I like to use both Site Definitions and Features to deliver content. I just have to weigh what is needed for the job. If I know the requirements for the web are going to be contained on a few lists, I'd go with one feature and use the OTB site def. If the web is completely customized or needs many features, I'd start with a site def that closely matches ...


3

The issue here is that you are modifying the web parts collection at the same time as iterating through it. You need to build a separate collection and then use that for the deletion e.g.: SPFile page = web.RootFolder.Files["default.aspx"]; SPLimitedWebPartManager wpmShared = page.GetLimitedWebPartManager(PersonalizationScope.Shared); List<WebPart> ...


3

When doing publishing sites (WCM) I think you really need to use a Site Def, if for nothing else to get an ID, but otherwise I like to keep it empty and use features for everything else, usually coding feature receivers to do the bulk of the work. Over the summer though, I was starting to get convinced by some very smart SharePoint designers that there may ...


3

Ok so in SharePoint 2010 there is a new player on the field: Custom Web Templates. I am now using them almost exclusively, instead of custom site definitions. Web Templates offer a few benefits over custom site definitions: Pros manifests can be upgraded (this is not supported on site defs!) can run within the sandbox and hence be used for SharePoint ...


3

I recommend using a Web Event Receiver to do this, and handle the 'WebProvisioned' method. This can be created as a Site collection scoped feature that will trigger for every sub website that's provisioned.


3

The issue is the lists get created after the feature stapling is called in the Site Collection creation process. The My Site is a new Site Collection, not a new subsite, that's why the event receivers don't fire and the manual activation works. I have used a thread pool solution like the one in the link below to delay the execution until the lists have been ...


3

Feature stappling simply means having a list of features to activate everytime a certain site definition is used (or in natural language stating "Do activate these features when any of the Site definition ID is created"). Basically there is always a Stappler (the actual feature linking one or more site definion ID with the actual features) and a Staplee ...


2

I developed my own little framework (too big word) to achieve complete upgradability of my solutions. This was major issue for most of my clients. In short: I am feeding my framework on feature (de)activation with some very simplified CAML definitions and I have covered in code most of the commonly needed stuff (adding/upgrading lists, receivers, content ...


2

One reason I use Site Templates (and I echo the details above to keep them clean and link features) is that I like the end user experience of selecting My Custom template from the Create Sites page. Adding new WEBTEMP files is easy, copying a blank site template and modifing it is easy. It allows the project (if it needs a custom template) to get up and ...


2

I'm using SPWebProvisioningProvider all the time to have control what features to activate when and in the order I want. Is more easy I think to devel and debug site and lists provisioning then using ONET.XAML and CAML.


2

Personally, I prefer going with a lean Site Template and then using Feature Stapling. I usually create one parent feature which has activation depedencies on several child features. I then staple that parent feature onto whatever site definition. The reason I like this is that I can deactivate and reactivate the feature to update the existing site. It ...


2

If you mean is it possible to have "per activation dependency Feature properties", then unfortunately the answer is no. You can, of course, have declarative properties on the Feature but I guess that's not what you're asking?


2

I would say that, if your site is a custom one, go with the site definition, it is easier to set, to manage and to deploy. If your feature needs to be attached to built-in site definitions, go with the site stapling, if your feature is not changing the base nature of that site definition. The big problem with the feature stapling, is that it gets confusing ...


2

You can remove the feature reference in onet.xml


2

To elaborate some more about the stapling solution. As Microsof says for SharePoint 2007 (but the same is valid for the 2010 version) "Feature stapling is a concept that allows you to attach (or staple) a SharePoint Feature to a SharePoint site definition without modifying the original site definition files in any way". In that sense, stapling is a valid ...


2

You should dispose of the SPWeb reference after each feature receiver has executed. public override void FeatureActivated(SPFeatureReceiverProperties properties) { using (SPWeb web = properties.Feature.Parent as SPWeb) { } } Admittedly, feature receivers such as this are one of the few places where you don't "have to" dispose of your SPWeb ...



Only top voted, non community-wiki answers of a minimum length are eligible