If I deploy a solution at farm level, is there a way by which i can prevent the owners of the various site collections from activating the features present in that solution?
A simple way to prevent site collection users from activating a certain feature is to mark it as hidden. These features are then effectively only allowed to be activated by farm administrators through STSADM commands.
To hide a feature update the Hidden attribute of the Feature element to ‘TRUE’ as shown below:
<Feature
Id="AD2146D-62DA-4911-DBC1-AE177DE40084"
Title="Restricted Web Parts"
Hidden="TRUE"
.../>
Alternatively if you are using SharePoint 2010 you can use Feature Packs to solve this problem by targeting a set of features to a particular set of users.
Have a look at the Zevenseas feature blocker.
If an error occurs during feature activation, it will not activate the feature and will retract any effects which might have been deployed as part of the Elements Manifest.
So, through crafty usage of this, you can use the FeatureActivated portion of a feature receiver to check who is activating it, and throw an UnauthorizedAccessException with an appropriate error message detailing why the feature cannot be activated. This will show up as the standard SharePoint error page with the message you specify. If you already have a feature receiver on the feature, you need to append this at the start of the FeatureActivated portion, so that any programmatic actions don't occur (unlike elements manifest, these are not retracted on unsuccessful activation).
If you haven't used a Feature Receiver before, you just need two parts to establish it.
In the feature XML of your feature, add the following two attributes to the Feature node.
ReceiverAssembly=(four-part-assembly-string)
ReceiverClass=(full namespace.class name of receiver class)
Write a receiver class. This inherits from SPFeatureReceiver, and has 4 required overrides in FeatureActivated, FeatureDeactivating, FeatureInstalled, and FeatureUninstalling. You don't have to do anything for the last 3. You'll write your security check in the FeatureActivated method.
Related
I am trying to create a diagnostic area for logging needs of my application through feature receiver. I have 2 ways to do this. Create a farm feature and have the code in feature_activated and deactivated.
Second way is have a site collection scoped feature and have the code in feature_installed and uninstalled
My question is when this the feature is activated on one of the web front end servers, is it required to be activated on other WFE's also? I was thinking if it is activated in one WFE, it should suffice as it is farm configuration and need not be activated on each WFE. Please let me know.
Feature activation affects the feature object in the SharePoint database; config or content, depending on you feature scope. It doesn't matter against what server in the farm you performed it. After the feature was activated, the next feature status check performed on other server in the farm will yield the active status. Also, your feature receiver will be called just once; not on every WFE.
I'm just learning how to develop an application for Sharepoint.
As far as I can see there are three types of integration into Sharepoint possible:
Sandboxed Solution (limited resource access but easy to install etc)
Farm Solution (installation only available from administrator)
Standard application (maybe .net MVC) with referencing the Sharepoint assembly to access the SPS functionality
Is that correct and complete or am I missing something?
There are quite a few ways to develop for SharePoint depending on your scope, requirements, etc. My knowledge is more in the SP2007 realm than 2010 and my answer reflects that.
JavaScript
Using Content Editor Web Parts you can customize the look of SharePoint, interact with List Data and do some interesting UI effects just using jQuery and the SPServices Plugin. These solutions don't require package and deployment.
Custom Content Type
These can be created through the SharePoint UI or defined through custom XML documents and deployed via WSP. Essentially these are just a collection of field definitions that are related in some logical way. Content types can be added to a list to have all the fields automatically available. In addition, they provide a convenient way of mixing and matching data in the same list (think of roll-ups or backing up list data) though I've never used them in this way.
Event Receiver
Event Receivers can be created to respond to specific events in SharePoint. If you attach an Event Receiver to a list, you can listen for and respond to events like an item or attachment being added, updated, deleted in both a synchronous (-ing) fashion - so you can implement validation and cancel the operation - or asynchronously (-ed) - to do some post-processing once SharePoint is done processing the item. Event Receivers are processed by the Front-End SharePoint server which handled the request which triggered the event. This is different than Timer Jobs and Workflows which are executed by any server in the farm that happens to be available.
Further, Event Receivers can be attached to lists based on their type (apply to all lists of this ID type) or they can be associated with a Content Type and become associated with a list that way (when the content type is added to the list, so too is the event receiver added).
Feature Receivers are a special kind of Event Receiver in that they respond to a Feature
being activated or deactivated to do some additional work. Many people refer to this extra work as Feature Stapling since it lets you perform additional tasks on-demand that couldn't otherwise be done using just XML documents.
Timer Job
A Timer Job is a piece of code that is run on a schedule. It's not executed in the W3WP process like Event Receivers are but rather via the TimerService. Because of this, certain features or values are missing from the SPRequest object. Developing Timer Jobs is more difficult and, in practice, more error prone, more difficult to debug, etc. than Event Receivers.
Workflow
Workflows can be created using SharePoint Designer or Visual Studio. The major difference between these are features available to you at design time. SharePoint Designer Workflows are easier to create and get going but tend to be buggy in SharePoint 2007. Further they are not easily packaged and deployed across environments but rather are associated directly to the list in which you created them (in 2007; in 2010 there is extended capability to allow packaging or even migration into Visual Studio for more complicated customization).
Using Visual Studio gives you more depth and capability but like Timer Jobs they are often difficult to "get right" and they are also processed by the Timer Service process.
Web Part
A custom Web Part is very similar to a regular ASP.NET web part with some extended capability within the SharePoint context. You have access to the SPRequest object and thus all the contextual information (current user, current list/web/site, etc.) to do your work. You can access external databases, make use of most ASP.NET controls, etc.
Custom ASPX Page
If a Web Part isn't sufficient for your needs or you want control over the full page, you can create SharePoint-enabled web pages. These are standard ASP.NET pages decorated with the proper SharePoint master page and deployed into a subdirectory of the hive LAYOUTS directory. With this you have similar access to the current request state as with a Web Part but you have more control over the entire page render.
Custom Web Application
If you have need for a standalone application, you can still take advantage of SharePoint's authentication and authorization tools without running directly in its context. To do this, create an IIS Web Application and set the Application Pool Identity to the same as SharePoint. Alternatively you could make a virtual directory within your SharePoint application pool but this is generally not recommended. You will still be constrained to using the .NET Framework 2.0 runtime if you want to use the SharePoint Object Model at all. This setup seems rarely used in the field since most of the time you can accomplish your needs by just using custom ASPX pages or web parts.
Regarding your specific questions:
Sandboxed solutions are just a special type of solution that restricts the namespaces your web part, etc. have access to. For instance your code can't reach out to access lists outside of its permission area. It can't send email on your behalf. You can increase your rights by using custom permission sets but this is an advanced topic. I just wanted to point out "sandboxed solution" isn't a type in and of itself, it just describes a restriction where previously none existed (SP 2007 GAC-deployed solutions).
Regarding your question regarding an MVC application using the SharePoint Object Model, like I mentioned you are still restricted to running in .NET 2.0 runtime.
EDIT: I forgot (at least) one more option!
List Service / Other ASMX Services
SharePoint has a number of web services you can consume to interact with Lists among other things. In this case, your application can be developed using any technology (or runtime!) you wish as long as it knows how to consume the ASMX services. The functionality available isn't as rich as using the Object Model directly (which is why I often forget to consider it) but it does allow your code to be more decoupled from the SharePoint environment itself. In 2010 there are a lot more options for Client Services to provide even greater functionality.
For developing a solution in visual studio you can go for Sandbox solution and farm solution. If you are having SharePoint 2013, then you will have another better option which is App Part development.
Since Sandbox solution is depricated from SharePoint 2013 onwards, i suggest you should not go with Sandbox solutions. Better to go with App Part development.
I'm working on a SharePoint 2010 project. We have a usercontrol to include all of our custom javascript. I popped an alert in there whilst debugging something else, and lo and behold the alert was called twice. I checked and the file in question is included by only one Elements.xml file in one feature. So how can this be? I've tried searching the whole solution, and I only get one hit, so I must be missing something.
EDIT:
This is the code calling the User Control:
<Control Id="AdditionalPageHead" Sequence="10" ControlSrc="/_controltemplates/company/UCLoadJS.ascx" />
This code is found in the Elements.xml of the MasterPages folder, which deploys our custom master page.
Having searched the whole project for UCLoadJS, I cannot find another instance.
I think you have hidden WPs loading these Controls.
Try creating a new page and add the Visual WP once and try again
I know that this question is 9 years old but I just had the same problem, so in case someone stumble across this thread, maybe this will help you:
try to list all your delegate controls. you can slightly modify the script provided by Waldek Mastykarz : Checking which Delegate Controls are activated on your site
if you find duplicated controls (and that was the situation in my case) then its probably because you deployed your control using one feature scope (Site for example) and then redeployed with another one (Web). Follow the steps below to solve the problem:
1). switch to another feature scope (the one you no longer want to use)
2). deploy the feature
3). deactivate it
4). switch feature scope to the required one and redeploy it
Source: SharePoint delegate control is rendered twice
My customer wants to provide 2 themes for a SharePoint application. Is there a strategy to accomplish this in MOSS 2007?
We want to apply user profile-based theme selection, and maybe even a drop-down to switch modes.
I don't know how extensive you want your re-theming to be. However if it could be CSS-only you could use this approach:
Store the CSS files for the different themes in the Style Library.
Create a list that stores the user and their chosen theme.
Write a feature and custom application page to allow the user to change their theme.
Write a control that does a lookup on the list against the current user and obtains the a reference to the corresponding CSS file in the Style Library. The control would then output the CssRegistration and CssLink controls to the page for this file.
Add this control to the master page so it executes on every page (caching should be added).
I can't see why this wouldn't be supportable by Microsoft as you're only changing CSS.
If you need to do more than that then another option is to write an HTTP module that changes the HTML output. Or of course JavaScript. With these two options you may have supportability issues (it depends on how extensive your changes are).
There is also SPThemes now available on Codeplex from Bjørn Furuknap. Users can choose their own themes and they can be applied at different scopes.
Here are the options that I’ve come up with from research and feedback. Both of which seem mostly infeasible.
Implement major UI layout changes in JavaScript. This would lead to client slowdowns, would be difficult to code, and would be completely unsupported by Microsoft due to the need to reference SharePoint objects that may change with subsequent SharePoint patches.
Provide two parallel themed sites based on the same data, and provide a way to switch between them. This would require that we deploy each site to multiple locations, and would require retooling of any site creation mechanisms in code (since they'd need to target two sites instead of one).
One another thing you can try is to use the Theme Changer and ThemeChangerStaple from codeplex , That is implemented as feature you can use the same code logic to archive what you want with bit of modification, give it as an option for the user using CustomAction.
I've created a custom list & also added a column in the Announcement List. Question is, how can I include those newly created items when I create a fresh Web Application (like a script, feature or something)?
Additional Info: It's like when you're to deploy from your development machine to a staging or production server. I'd like to have a script or something to update my production server to have the new column i've added to the Announcement List. Just like SQL Server's ALTER TABLE command to update a SQL Server Table.
Is there an equivalent in Sharepoint Lists?
TIA!
Regarding the new custom list, this can be done using features. See How to: Create a Custom List Definition for more information. The Visual Studio Extensions for SharePoint (VS2005 / VS2008) will help you to extract the list definition if you've created it through the SharePoint UI. If you are fortunate enough to be using a custom site definition and don't have any webs created yet, you can set your site definition to create the custom list using feature stapling.
If you are attempting to apply these changes to webs that already exist, you can still use a feature to define your custom list. It will just appear as a type of list that can be created. Then to have the custom list automatically created for existing webs or to modify existing lists such as the Announcements list, you can use a feature receiver. This allows you to run any custom code when the feature is activated. See the MSDN article Feature Events for more information.
Alternatively, you could not use features at all as they can be difficult, time consuming and painful. In fact, this blog post has a good argument against the idea. You could try the tool mentioned on that page or other applications such as DocAve Content Manager and SharePoint Site Migration Manager.
Your question is not very clear but I think you may want to look at Application Templates.
Microsoft provide 40 pre-built templates in the link below and the same technology is available to you. Links from this page should lead you to information showing you how you can crate your own.
Application Templates for Windows SharePoint Services 3.0
http://technet.microsoft.com/en-us/windowsserver/sharepoint/bb407286.aspx