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.
Related
Programs used
SSRS 2008 R2
Sharepoint 2007
So here's the issue my co-worker and I are facing. We have subscription for a report going to a Sharepoint library. We're currently using "Windows File Share" as the delivery method, as we have no other options available.
What we're finding is that the file is being pushed successfully, but it's not being "checked in" so that it's available to viewing by all people in the library.
Barring doing what's suggested here: SSRS in Sharepoint Integrated mode
Is there anyway to make this work? One idea that cropped up was putting the subscription to a share on the SSRS server, then pushing via a batch file.
Probably the easiest way, assuming you have access to customize your SharePoint system, would be to add an event receiver on the ItemAdded event of the document library. This will fire whenever a document is added to the library. Within the event receiver check that the item is being added by the account used by your Reporting Services system and check it in (because you don't want to automatically check in everyone's documents when they are added, just the reports).
Alternatively, you could do the same thing using a workflow.
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 need a way to execute code when a new Site Collection is created. I've looked at creating a web-scoped FeatureReceiver that gets executed when a new Web is created. Then stapling this feature to all the site definitions, however Visual Studio 2010 isn't letting me deploy the module that contains the FeatureSiteTemplateAssociation directive. It complains that the feature can't be deployed farm level (because it contains a Module).
Any ideas?
It sounds like you might want to use an Event Receiver instead of a Feature Receiver. There is only an event for determining if a site collection is deleting/deleted. There is an event for Web Adding/Provisioned however. If you are creating a site immediately after creating the site collection one of those 2 events could be used to simply check the count of webs in the collection (0 or 1 depending on which web event receiver you use). This would essential run your code on the creation of the first site within the site collection and should accomplish what you are looking for.
I've a farm scoped feature which has an event handler. The feature is activated by default on installation. After I installed the feature I found that the FeatureActivated event has been raised mutiple times (I've three web apps in total excluding central admin and it is called three times).
Because of this the feature deployment is extremely slow (as I'm doing some webconfig modifications for each web application).
Any ideas?
I have had a similar problem in the past. I created a static flag in the FeatureReceiver that indicates if it has triggered before.
Dirty, but effective.
If you make it a farm scoped feature, then the first install we be easier, sure, but then in 6 months when you create another web application, the settings wont be applied automatically and likely forgotten.
If though, you make it a web application scoped feature with the property ActivateOnDefault="TRUE" in your feature definition, then the feature will be activated in all new web applications when they are created.
http://msdn.microsoft.com/en-us/library/ms436075.aspx
And i hope you are using SPWebConfigModification to make the web.config changes, otherwise if you add new servers to the farm, then the web.config mods wont be applied either.
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx
Do you need these web.config changes for all the web apps ? Including central admin ?
The first change I would do is to make it a Web Application scoped feature and selectively activate on required web application.
Also, do not make it Activate by default on installation. If you are deploying through script, have a separate command for activation. That way, you can easily debug if the bottleneck is in deployment or activation.
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.