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.
Related
Seemingly simple requirement. We have two SharePoint web applications hosted on the same server. Site A is used internally and is thought of as hosting the source documents. Site B is accessed by external suppliers.
I would like to have SharePoint automagically copy new documents from a doc library in Site A to a doc library on Site B. It would need to preserve metadata. The process would need to "fire" each time a new document was uploaded into the document library in Site A.
Why are you looking for workflow solution in this case?
Go for Item Added event receiver for that document library.
Use managed client object to copy the document to library in another farm.
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 made a change to my v4 master at the application level to hide a certain piece of HTML code (the developer dashboard to be specific). I assumed I could edit it at the application level and then all site collections created within that application would inherit the changed v4 master and hide the element.
This is not the case though... in addition, I tried to edit the master in 14\TEMPLATES\LAYOUTS with no success either.
The only thing I have gotten to work is editing the v4 in SP designer at the site level (which is unaccepable to me as I want to provision a new site collection and not have to manually change this every time).
Any suggestions / known fixes for the issue I am encountering?
Try to hide what do you want thru style sheet CSS or don't update the default v4 mater page not recommended, create a new copy of V4 and do you updates then create Staplers features and on every site collection created change it's master page to the new one yo have created and for the old created site collection run thru code and activate the Staplee feature on each site collection to do the same.
I have been adding lists and sites to sites when they have been created with feature stapling. Now I want to add a web part when a site is created but it seems like it is to early to do that in FeatureActivated() when I am using feature stapling.
It is working when I activate a feature for an already created site but when I try to do it with feature stapling a get an exception that the object is not created.
Do you know any why to accomplish this when the site is created?
Make sure you use the SPLimitedWebPartManager to perform this work, or you will have trouble.
I've been looking at Microsoft's own early example of how to build solutions - the GroupBoard Workspace solution (http://technet.microsoft.com/en-us/windowsserver/sharepoint/bb848080.aspx)
In this case they actually have two solutions - one which creates the site and another which "updates" the site afterwards. The webparts are added by the second one.
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