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.
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.
We have a SharePoint farm with multiple WFEs. A new application requires us to write some custom code to the web.config during deployment. What is the best way modify the the web.config file during deployment, ensuring that each WFE in the farm get updated?
I'm assuming you'll be deploying your code via a WSP; if not, using a tool like WSPBuilder is a great starting place that allows you to get rolling without forcing you to learn all of the intricate details of solution package construction.
You should leverage the SPWebConfigModification type from within a custom SPFeatureReceiver. Normally, the FeatureActivated method of the SPFeatureReceiver would be coded to write the changes out to the web.config files impacted by your activation. Those same changes would then be retracted in the FeatureDeactivating method.
The nice thing about the SPWebConfigModification type is that SharePoint takes care of determining which web.config files should be modified -- across servers and across extended web apps.
I hope this helps!
As part of your deployment, use the SPWebConfigModification class to add/remove entries from web.config. SharePoint will manage updating the WFEs for you if you use this.
A blog post entitled, Modify the web.config file in SharePoint using SPWebConfigModification, is a great summation of the gotchas involved and contains links to other helpful resources.
Using the SharePoint API, how can I modify an extended webapp web.config file?
I have to do some changes in this file to specify the connection string, membershipprovider, etc... for using Forms Authentication.
Currently, I can change the "master" webapplication web.config file, but not the extended one.
Edited
I'm using Sp 2007. I'm already using SPWebConfigModification class to modify the parent webapp. Thoses modifications are propagated to the extended webapp. I have to change ONLY the extended one. But I don't find the way to do it.
What I'm trying to achieve, is to program a little wizard that:
Shows a WebApp list so the user can select one
Extend that selected webapp to a different zone
Configure that extended zone to use Forms Authentication
Thanks
I got an answer form a blog.
In your case , you need to write a Web Application scoped feature which after you provision your site using your C# app, it is deployed to the newly-provisioned site and in the receiver of the feature you inject the required web.config settings because in that context configuration API is obtainable , but again bear the following in mind:
If you don’t use SPWebConfigModification class and either use ASP.NET 2.0 configuration API or your own mechanism , propagating changes across the farm is YOUR RESPONSIBILITY. If this happens on an standalone installation then you don;t need to be worried about this.
So it cannot be done externally. We have to do a feature in order to acheve this.
Thanks
Quick answer: look into the SPWebConfigModification class. I am assuming you're using SharePoint 2007. The best way to learn about this is to dig into open source projects:
Google code search: http://www.google.com/codesearch?q=spwebconfigmodification&hl=en&btnG=Search+Code
This project on CodePlex looks like it's one big SPWebConfigModification: http://www.codeplex.com/ajaxifymoss/Release/ProjectReleases.aspx?ReleaseId=13360
I am developing publishing site. I have some layouts that are pre-populated with web parts and have a problem when I need to make some change on the layout.
Deployment succeeds but I still see old version. If make I change in SP Designer it is reflected OK but not if the change is done by the feature that is being deployed.
It looks like after I deploy particular layout any site collection in that web application will have the first version.
I have tried deleting complete site, all the pages, layouts and nothing happens, after deployment I still see old layout.
Current solution for this problem was that I take new virtual image and start with clean machine.
Real problem is how to solve this on clients installation without reverting to clean machine. There will be some bug fixes and I will have to send new WSP file with some changes in layout.
Is there any way to force SharePoint to use newly deployed layout and not some old Unghosted version?
If the layouts are without web parts I don't have this problem.
Update
I am using default "Publishing Portal" and deploying layouts using features. For development I am using VSeWSS 1.3.
tried in SharePoint designer to detach page from layout and attach it again but still no results.
Since you are using VSeWSS, you can execute your own code upon feature activation. So try writing an SPFeatureReceiver that will call SPWeb.RevertAllDocumentContentStreams() to reghost directly after feature activation on the web(s) in question.
If this doesn't work, then the problem isn't about ghosting, maybe it's about Orphans then. But try this first.
If it's a feature that you are deploying you have do deactivate the feature and activate it after deployment again. And don't forget to do an IISRESET or an AppPool recycle.
If your new site collection has the first version of the layout make sure that it is really your new feature version that you are activating.
Try to reject your solution first and add the new one after that.
Are you using Site Definitons or Site Templates? If you are using either of these it may not update after initial provisioning.
Try completely retracting and deleting the solution from central admin, resetting AppPools and then redeploying the solution.
Make sure your element manifest for your feature specifies that existing files should be overwritten.
Looks like some folks have had problems with layouts too...
See http://msdn.microsoft.com/en-us/library/ms459213.aspx
If you are developing new sitedefinition, you can attach your new layout in the onet.xml file by using the property, i hope it will help you
-->