Disclaimer: This post is based on notes taken while watching a conference session. For that reason, it may contain incorrect information or data that I might have misunderstood. Also, the product it refers to was not available yet at the time of the writing, thus, not allowing me to validate the present information.
This was the fourth session I attended on the second day of the SharePoint Conference 2009, and it was given by Venky Veeraraghavan from Microsoft.
Venky started by pointing us to the twitter account of the SharePoint Social team (@SPSocial). Follow it to get updated information on this, or mention it to get their attention.
My Site Personal Portal
For SharePoint 2010, Microsoft has made a few changes to the components of the My Site, namely to the page structure of the portal. Now, a newly created My Site has three pages:
- My Network (the homepage, shows the Activity Feed for all users in your network)
- My Profile (shows the profile data)
- My Content (the entry page for the personal site). Additionally, you can create any pages you want on your personal site.
The My Profile page has a new layout and includes areas like:
- Overview (shows the activity feed in Published mode)
- Organization (shows the new Silverlight-based Organizational Chart which allows you to navigate in the organizational structure)
- Content (shows the latest content created by the user)
- Tags and Notes (shows tags used and notes written by the user)
- Colleagues (shows and manages the list of colleagues the user follows)
- Memberships (shows and manages the list of site memberships)
As in the previous version, these pages are located in two different places:
- My Network and My Profile pages are shared by all users and, for that reason, are located in the My Site Host site collection.
- My Content and any custom pages you create will be placed on your personal site collection.
Also, as seen in SharePoint 2007, both the My Site Host site collection and the users’ personal site collections belong to the same Web Application. This Web Application is associated with three Service Applications:
- Enterprise Managed Metadata Service Application
- User Profile Application
- Search Service Application
The New Activity Feed
One of the greatest additions to the My Site is the new Activity Feed. The Activity Feed is an extensible component which exposes tracked data through a Web Part and an Atom 2.0 feed. The Activity Feed has two modes:
- Consolidated – Lists the activities of everything a user tracks. This mode is used on the My Network page.
- Published – Lists my activities. This mode is used on the My Profile Page.
The architecture that supports the Activity Feed can be briefly described as:
- Everything starts with a Gatherer Timer Job which periodically analyzes the Social Database (which stores all the tagging, rating and comment data) and the change log of the User Profile Database.
- Using a new API called Injection Object Model, the gatherer injects the relevant information into the Activity Feed structure in the User Profile Database.
- This data is then exposed via a Web Part, the Object Model or the Atom feed.
The main extensibility point is the possibility to create Custom Gatherers, which collect information from other data sources and inject them in the feed using the Injection Object Model.
Regarding the consumption of the Atom 2.0 feed, the URLs for:
- Consolidated Feed:
http://<mysitehost>/_layouts/activityfeed.aspx?consolidated=true
- Published Feed:
http://<mysitehost>/_layouts/activityfeed.aspx?publisher=<accountname>
Since consuming a feed is a very common and easy way to retrieve live information, it’s expected that SharePoint will have to handle a large number of requests. Currently, at it’s beta version, SharePoint 2010 can handle 500-700 requests per second (RPS) with full activity detail, or 2100 RPS without it. However, the RTM is aiming at 2000 RPS.
Profile Pictures
The way profile pictures are stored has also been changed. Instead of storing the profile picture inside each user’s personal site, SharePoint 2010 will store all profile pictures in a central picture library which will be accessed through the URL:
- http://<mysitehost>/UserPhotos
When a picture is uploaded, SharePoint will automatically create the resized versions of it:
- 32x32 (for general use in SharePoint)
- 48x48 (for AD and client applications)
- 96x96 (for the Profile Page)
The Picture Picker control used by SharePoint can be customized and even replaced to support any policies and picture stores.
The profile pictures will be synchronized with Active Directory, allowing the profiles to be bootstrapped if the pictures are already in Active Directory when the profiles are created, or writing back to Active Directory, if SharePoint is configured to do so. Client applications such as Outlook and OCS can use pictures stored in AD.
Microsoft also thought about the upgrading process from SharePoint 2007 to SharePoint 2010, and there is a PowerShell cmdlet (Upgrade-SPProfilePhotoStore) that migrates all profile pictures from the previous structure to the new store.
Social Feedback
Another of the biggest additions is the Social Feedback mechanism which is everywhere in SharePoint 2010. It’s a new mechanism that allows users to tag, rate and comment on any URL, either inside or outside of SharePoint (through bookmarklets). Feedback is the primary mechanism for promoting documents and web pages to the newsfeed and it also helps categorize, annotate, promote and in the retrieval of relevant links.
The user doesn’t need write permissions on a specific item to be able to give feedback on it(read permissions are obviously required), since this data is stored on a separate database. At a very basic level, each feedback item is has only three fields: Person, URI and Feedback.
Tags
- Also known as keyword bookmarking
- There is no web part for tagging
- Can be applied to web pages, list items and documents
- Can be used to sort and filter lists and document libraries, but only by document authors and requires the enterprise keywords field
- Tags are indexed by search
- Can be applied to external or non-SharePoint pages via bookmarklets
- Can be used with Enterprise taxonomy management
- Can be used in Office 2010 Client (but only document authors and requires enterprise keywords field) and Office Web Apps
Notes
- Short comments (less than 3000 characters)
- There is a specific web part for comments
- Can be applied to web pages, list items and documents
- Cannot be used for sorting and filtering in lists
- Notes are not indexed by search
- Can be applied to external or non-SharePoint pages via bookmarklets
- Can be used in Office 2010 Client and Office Web Apps
Ratings
- 5-star ratings
- There is a specific web part for ratings
- Can be applied to web pages, list items and documents
- Can be used for sorting and filtering in lists and document libraries
- Ratings are indexed by search
- Cannot be applied to external or non-SharePoint pages
- Cannot be used in Office 2010 Client nor Office Web Apps
The concept of My Links from SharePoint 2007 will be replaced by social tags, and there will be a mechanism to migrate each user’s links to tags.
The social feedback mechanism is supported on three services:
- Search Service, which indexes tags and ratings and performs all the security trimming
- User Profiles and Synchronization
- Enterprise Metadata Management, for tagging and profile properties
The use of social feedback mechanisms will bring a new set of challenges to the organizations. Planning will be a key step to make it work, and it has to occur at various levels:
- Planning for scale – social feedback generates very large amounts of data.
- Planning for privacy – organizations have to make decisions about who can give feedback and how security trimming is applied to this feedback.
- Planning for adoption – organizations have to start with a small number of committed users and gather support from all departments for this to succeed.
Expertise Search
The last of the additions I’ll be pointing out is the Expertise Search mechanism which allows:
- Users to search for other users by their expertise tags
- SharePoint 2010 to suggest expertise tags for each user
While the first is pretty straightforward, the second is much more interesting. So, how does SharePoint 2010 know what expertise tags to suggest?
Well, Outlook 2010 can analyze your e-mail (your sent items, in particular) looking for the people to whom you send e-mails the most and also extracting the most common keywords. This information is then sent to SharePoint to be included in the user’s profile, if he agrees to it, where it can be indexed and searched normally.
Don’t worry, the analysis can be configured to be:
- Turned off. No analysis will be done on your e-mail.
- Analyze and upload automatically to the profile (user consent at the client).
- Analyze but only suggest when editing the profile (user consent on the server).
Disclaimer: This post is based on notes taken while watching a conference session. For that reason, it may contain incorrect information or data that I might have misunderstood. Also, the product it refers to was not available yet at the time of the writing, thus, not allowing me to validate the present information.
This was the third session I attended on the second day of the SharePoint Conference 2009, and it was given by Pej Javaheri and Steve Tullis, both from Microsoft.
The first cool thing about this session was that the slide deck was presented using PowerPoint Web App. Talk about eating your own dog food :)
Most of the session was one big demo showing off an overview of some of the top new features on Excel 2010 and Excel Services 2010, which I will describe below.
Power Pivot
Power Pivot is the new name of what was previously known as project “Gemini”. It’s a new capability that the SQL Server team has worked on and brought to Excel, which allows deeper analytics on very large data sets. One other nice thing is that it can be made available through SharePoint 2010.
You can find more information about this on: http://www.powerpivot.com.
Business Intelligence Center
SharePoint 2010 includes an new site template called Business Intelligence Center which is an improvement over the previous Reports Center site template. This new template contains extensive guidance to help you start using the new BI components offered by SharePoint 2010.
Excel 2010: Pivot Charts and Pivot Tables
Excel 2010 introduces Pivot Charts. Pivot Charts are like normal charts connected to the same source data as the Pivot Table, however now you can drill down on hierarchies and select which members you want to see, right on the chart object, instead of having to do that on the associated Pivot Table, and your selections will affect both the Pivot Chart and the Pivot Table.
Both on Pivot Charts and Pivot tables, on the field selection popup menu, when drilling down a hierarchy to select a member, you will now find a search box to help you search an item instead of having to browse through all the hierarchy to find it.
Another new thing is the ability to define named field sets and use them in Pivot Tables and Pivot Charts. These named sets are stored inside the workbook and can be reused by other users.
In a Pivot Table, you can perform a series of calculations by using a new feature called Show Value As. This new feature allows you change the way you view a field by selecting from a list of predefined calculations, such as:
- % of Grand Total
- % of Row Total
- % of Column Total
- % of Parent Row Total
Before you either had to perform the calculations outside the Pivot Table or put these as cube formulas.
Excel 2010: Conditional Formatting
A few improvements were made to the conditional formatting capabilities of Excel, and now Data Bars support positive and negative values. Also, new Icon Sets have been introduced.
Excel 2010: Slicers
Visual Slicers are a new Excel object that allows users to filter the data on Pivot Charts and Pivot Tables with a single click. Slicers show you a set of members of a hierarchy as buttons which you can press to filter data. Additionally, members that have no available data will be grayed out, giving you a quick visual understanding of which members have data and which have not.
Excel 2010: Sparkline
Also an addition to Excel are the Sparklines. A Sparkline is like a mini chart that illustrates a trend in a set of data. Excel comes with three types of Sparklines:
The Sparkline object is treated like any other cell content (such as a formula) which means it can be copied, pasted and expanded.
Excel 2010: What-If Analysis
When accessing external data (a SSAS cube) to build a Pivot Table, you can now use What-If Analysis to write back to the data source.
Excel Services 2010: More Workbooks and Client Fidelity
Excel Services (Excel Web App) will now try to open all workbooks in View Mode even if they contain unsupported features. In the previous version, Excel Services wouldn’t even open the workbook showing an error message which wasn’t much help to solve the problem.
In Edit Mode, however, it’s a different story but the list of unsupported features was not shown. I can tell you what I saw from the demos, but this is not an extensive list:
- Images are supported
- Charts, Sparklines and Slicers are supported
- Pivot tables are supported
- Grouping is supported
Don’t misunderstand me. I’m not saying you can add sparklines and slicers while editing the workbook. I’m saying you can edit a workbook that contains these objects and even interact with them, but that’s it.
As a final remark, all of this works very well on Safari and FireFox (besides Internet Explorer, of course).
Excel Services 2010: Edit and Collaboration
The big news here is that you can edit a workbook using the Excel Web App. You have a limited set of operations you can perform but I can tell you it’s still quite impressive. The Edit Mode support co-editing, which means more than one user can edit the document simultaneously and Excel Web App will warn you of who is also collaborating with you.
Edit Mode has a reduced version of the Excel Ribbon but has a fairly impressive set of features (for a web app):
- Supports undo and redo
- Supports live preview (when selecting colors or formats)
- Supports auto-complete when entering a formula
- Supports grouping of rows and columns
It probably supports a lot more cool features, but this is what I saw in the session.
The new Excel Web Access Web Part allows you to turn interactivity on and off, which means the users can now type in the cells. In the previous version, if you wanted the users to interact with your Excel workbook through the Excel Web Access Web Part, you had to define parameters which would be shown on the side of the web part.
Just one note: interactivity is not the same as editing. You can interact, and see changes in charts and calculations, but the original workbook remains unchanged.
Excel Services 2010: JSOM (JavaScript Object Model)
Another addition to Excel Services 2010, is the JavaScript Object Model (JSOM) which allows developers to handle events in Excel Web Access Web Parts (like mouse clicks) and react to them.
Steve demonstrated the JSOM in a SharePoint Dashboard with two different Excel Web Access Web Parts. The first one had an Excel grid and the second one had two charts. Whenever he clicked a row in the first one, the charts showed data that was related to the selected row.
Excel Services 2010: REST API
One of the coolest new features (in my perspective) is the REST API exposed by Excel Services 2010 which can be used to retrieve data on:
- Ranges
- Charts
- Tables
- PivotTables
The data is retrieved as an Atom feed (which you can syndicate to) or in HTML format allowing it to be embedded wherever you wish. When retrieving a Chart, Excel Services will return a PNG image of the chart.
One of the demos regarding the REST API was creating a quick part in Word, of type field, and setting the source of that field to be the REST URL for a Chart. By doing this, Word inserts the chart image in a document, but allows you to update it like any other field.
Disclaimer: This post is based on notes taken while watching a conference session. For that reason, it may contain incorrect information or data that I might have misunderstood. Also, the product it refers to was not available yet at the time of the writing, thus, not allowing me to validate the present information.
This was the second session I attended on the second day of the SharePoint Conference 2009 and it was given by Rolando Jimenez from Microsoft.
Business Connectivity Services
According to Rolando, Business Connectivity Services (BCS) are “a set of out-of-the-box features, services and tools that enhance SharePoint to streamline solutions of deep integration of external data and services.”
In the SharePoint Pie, Business Connectivity Services belongs to the Composite slice. It’s the new and much improved version of the old Business Data Catalog, introduced in SharePoint 2007.
Regarding BCS, Microsoft has invested in three main areas:
- Presentation: extend Office and SharePoint’s user experience and capabilities to external data and processes.
- Connectivity: read-write capable connectivity from client and server to databases, WCF/Web Services and .NET sources.
- Tooling: integrated tooling experience scales from simple solutions to advanced applications with rich client packaging and deployment.
Core Concepts
The main building block for BCS is the new concept of External Content Type (ECT), which is the new name for what was previously known as BDC Entity. An ECT describes:
- How to connect to the data
- Schema of the data
- Behavior within Office and SharePoint
This definition will then be used by the BCS Runtime, both in SharePoint (thin client) and in Office Client applications (rich client) to access the external data.
The other important concept is the External List. This is a new type of list in SharePoint 2010 that allows you to surface data retrieved by BCS as defined by the External Content Type associated to it.
BCS Tools Overview
There are three types of solutions that use BCS:
- Simple No Code solutions, which can be built by Power Users using SharePoint Designer
- Surface data in SharePoint using External Lists
- Connect those lists to Outlook and SharePoint Workspace and take them offline
- Intermediate No Code solutions, which can be built by developers using SharePoint SDK (and eventually also SharePoint Designer)
- Customized InfoPath forms
- Customized Office Ribbon and TaskPanes
- Customized QuickParts in Word
- Customized Workflows
- Customized Web Part Pages
- Advanced Solutions, built by Advanced Developers using Visual Studio (and SharePoint SDK and SharePoint Designer).
- Custom connectivity for data aggregation, transformation, security, …
- Using custom code to integrate data into any Office application (even the ones that don’t support BCS directly)
- Business logic in forms
- Create reusable components (UI parts, ECTs, actions) to be included in simpler solutions
Regarding solution creation, there are mainly two approaches:
- Client-Server Environment - PowerUsers use a live connection to the server and directly build simple no code solutions on the server or rich client.
- Single Machine Development Environment - Developers use a combination of SharePoint Designer, SharePoint SDK and Visual Studio to produce advanced solutions, packaged in WSP files that can then be deployed to any SharePoint farm.
Demos
After the overviews, Rolando demonstrated a few Advanced Solution scenarios. Here are the notes I gathered from the demos.
Demo 1: BCS Hello World
- There is a new project type in Visual Studio 2010 called Business Data Connectivity Model Project which can contain a collection of ECTs
- The graphical designer makes it very easy to build ECTs
- An ECT is a class with at least:
- One property called ID
- A method called ReadList
- A method called ReadItem
- Visual Studio 2010 includes a BCS Explorer tool which graphically shows the structure of the XML-behind generated when designing the ECTs
- Visual Studio 2010 can package and deploy the ECT directly to SharePoint
Demo 2: Author Custom Connectivity in Visual Studio
- If you want to retrieve data from multiple tables and aggregate it in a single ECTs you have to develop the code yourself (for each ECT class method).
- If you want to allow writes on ECTs, you must add an Update method to the ECT class.
- SharePoint automatically generates and Edit Form for External Lists that support writes.
Demo 3: Discover and Configure ECT for Outlook Offlining in SharePoint Designer
- Using SharePoint Designer you can define a mapping between ECT properties and Outlook objects, allowing you to connect an external list to Outlook (really neat stuff).
- When packaging the solution, Visual Studio will generate a WSP for SharePoint deployment and a Click-Once package for Office Client deployment (similar to Office Add-Ins).
- The same code (ECT assembly) is executed by the BCS Runtime on the Office Client and on SharePoint.
Demo 4: Custom Rich Client Integration (Excel) with VSTO
- Using the BCS API, a developer can built an Excel Add-In, using VSTO, that loads the data using the ECT and inserts into a spreadsheet.
- The developer can specify if it allows BCS to cache the data or if the data always has to be live.
Disclaimer: This post is based on notes taken while watching a conference session. For that reason, it may contain incorrect information or data that I might have misunderstood. Also, the product it refers to was not available yet at the time of the writing, thus, not allowing me to validate the present information.
This was the first session I attended on the second day of the SharePoint Conference 2009 and it was lectured by Umesh Unnikrishnan from Microsoft.
Core Concepts
- Service is a middle tier feature that performs the useful function of providing data or processing resources to SharePoint features. For instance, Search is a Service.
- Service Applications is a configured logical instance of a Service, which provides data or computer resources and exposes administrative interfaces.
- Service Instance is a running physical instance of a Service (in the sense of a process).
Web Applications are associated with Service Applications by means of a Service Application Proxy, which connects the two allowing the Web Application to use the Service Application. The associations between a Web Application and a Service Application can be changed at any time by administrators, and can be managed in groups (Service Application Proxy Groups).
Evolution of Shared Services Provider
In SharePoint 2010, the Shared Services Provider is replaced by separate Service Applications:
- User Profiles Service Application
- Search Service Application
- Excel Service Application
- Business Connectivity Application
- And all the new Service Applications in SharePoint 2010
This means that:
- Services are now independent, and don’t exist under the umbrella of the Shared Services Provider
- There is no more Shared Services Provider administration site, all the administration is integrated in the Central Administration site
- You can develop Service Applications and integrate them in SharePoint 2010
- When SharePoint 2007 is upgraded to SharePoint 2010, the services provided by the SSP are directly mapped to their respective Service Applications
Service Framework
SharePoint 2010 ships with around 20 out-of-the-box Services, and other products like Office Web Apps, Project Server and SQL Power Pivot also include Services. All these services are built using the same framework that is provided to extend this model, which is incorporated into SharePoint Foundation:
- Built-in support for scaling via multi-server support and load balancer
- Includes mechanism to host and deploy WCF-based Service Applications
- Includes Administration UI and PowerShell integration
- Includes Timer Job support
- Can be multi-tenant aware
Service Administration
Regarding Service Administration in SharePoint 2010:
- All the administration is performed in Central Administration or through PowerShell scripting. Each service plugs its management UI into the Service Management Page.
- The new association model is much more flexible than before, and allows each Web Application to use only the Services it really needs.
- The Service Application model incorporates software-based fault tolerant round-robin load balancing. There is, however, support for hardware-based load balancing and extensibility points for 3rd party components.
- Service Applications support cross-farm federation adding even more flexibility to its configuration. This allows a farm to provide services to other farms.
Farm Administrators can configure Delegated Administrators, which are users with Central Administration access that manage one or more Service Applications. Central Administration UI is security trimmed allowing Delegated Administrator to interact only with their managed Service Applications.
There are four pages dedicated to Service Application administration:
- Manage Service Applications page
- Create/Delete Services Applications
- Manage Service Application metadata
- Connect to remote Service Applications
- Publish and Secure Service Applications
- Service-specific management UI page
- Service Application specific settings
- Dashboard showing Service Application status (search crawl status, profile import status, etc)
- Manage Service Associations page
- Add/remove associations between Web Applications and Service Applications
- Manage Services on Server page
- Start/stop Service Instances on specific servers
Service Security
The security model was improved:
- Inside the farm, services use claims-based authorization
- Between farms, services communicate via WCF-based web services
- There is support for SSL/Transport Security
The Service Applications can be isolated:
- Each Service Application uses a separate database and, optionally, a separate application pool
- Different Service Applications for a single Service can run under different accounts and use different databases
Security is managed per Service Application. There are two types of security:
- Admin Security
- Specifies who has admin rights over a Service Application
- Used for security trimming
- By default, all Farm Administrators are included
- Access Security
- Specifies claims that have access to the service
- By default, the farm claim has access
- Some services might require more granular access rights
Service Application Deployment
The configuration of the Service Applications can be performed:
- Automatically, via Farm Configuration Wizard, which creates all Service Applications with their default settings.
- Manually, using the Central Administration UI (New Button in the Manage Service Applications page). This allows you to:
- Specify custom application pool, database location, service account
- Create Service Applications and their Service Application Proxies
Service Application Associations
By default, all Service Applications in a farm are associated with all Web Applications (through Service Application Proxies). This default association scheme can be changed so that associations are managed separately for each Web Application and Service Application.
Service Application Publishing
Publishing a Service Application makes it available outside the farm, where it can be discovered and consumed by remote farms. However, you still have to perform associations to give Web Applications access to the Services Application and cross-farm trust is required via certificate exchange.
Sample Topologies
Single Farm
- Simplest one
- All Web Applications are associated with all Service Applications
Isolated Hosting
- Single farm
- Each Web Application is associated with only the needed Service Applications
- Some Service Applications are shared between different Web Applications
- There can be multiple Service Applications for a single Service, associated with different Web Applications, to ensure isolation
Shared Resource Farm
- Multiple farms
- One farm contains all the Service Applications and publishes them to be consumed by Web Applications in other farms
- The other farms contain only the Web Applications which consume the published Service Applications of the first farm
Disclaimer: This post is based on notes taken while watching a conference session. For that reason, it may contain incorrect information or data that I might have misunderstood. Also, the product it refers to was not available yet at the time of the writing, thus, not allowing me to validate the present information.
This session was an introduction to applications based on InfoPath 2010 and Forms Services 2010, and it was given by Peter Allenspach and Bojana Duke, from Microsoft. It was split in three parts, consisting of a demo each:
- Demo 1: Customizing SharePoint List Forms
- Demo 2: Creating Mashups with Forms Web Part
- Demo 3: Office Business Application
Here are the news about developing applications with InfoPath 2010:
- With SharePoint 2010 and InfoPath 2010 you have the possibility to customize a list’s forms with a single click. This allows you to create a new list form with InfoPath very easily, and you can even mix data from several lists and show it on the form.
- When designing a new InfoPath form for a list, you can add or remove fields from the list just by adding or removing them from the InfoPath form.
- Customized InfoPath List Forms are made available offline when you synchronize your list with SharePoint Workspace 2010.
- Forms Services in SharePoint 2010 supports FireFox and Safari browsers, besides IE.
- Forms Services in SharePoint 2010 supports WCAG 2.0 accessibility standard.
- InfoPath Forms with code-behind no longer requires an administrator to deploy them. They can be deployed with a one-click process and run as a Sandbox Solution without any security concerns.
- The InfoPath Form Web Part is now available to be placed anywhere, allowing any InfoPath form to be rendered. This Web Part also accepts connections from other Web Parts, allowing it to be used to create mashups easily.
Disclaimer: This post is based on notes taken while watching a conference session. For that reason, it may contain incorrect information or data that I might have misunderstood.
This session was given by Mike Morton, from Microsoft, and it focused on an overview of the new Visual Studio 2010 features for SharePoint Development. It was a demo intensive session, but very effective in showing how much easier SharePoint development will become with these new tools.
Debugging got a lot easier with the new SharePoint project templates of Visual Studio 2010 which all automatically create Packages (WSP files, previously called SharePoint Solutions) and associated Features, and allow one-click deployment to SharePoint.
Mike introduced the concept of SharePoint Project Item (SPI), which represents every possible artifact you might want to develop for SharePoint, from SharePoint Workflows to List Event Receivers, and from Web Parts to List Templates.
Using Visual Studio 2010, you can add an SPI to the SharePoint project when you want to create one of those artifacts. Visual Studio will automatically create the necessary files to package that artifact (which can be Feature Manifests, Resource Files, Element Manifests or Class Files) and updates the Package Manifest.
In addition to automatically creating all the XML files for Features and Packages, Visual Studio includes the Package Designer and the Feature Designer which allow you to graphically edit the contents of a package and the elements included in a feature, respectively. SharePoint deployment will never be the same again…
Other new concepts:
- Visual Web Part: an SPI that allows you to develop a Web Part using a Visual Designer, like if you were a creating an ASP.Net page. This was a really welcome addition :)
- SharePoint Root: previously called “Hive” or “12 Hive”, it should now be called SharePoint Root. You can use the token {SharePointRoot} to point to this folder which can be either a physical folder in the server’s hard drive (like the previous “Hive”) or some location on the SharePoint database (for Sandbox Solutions).
- Mapped Folders: SharePoint folders (inside the SharePoint Root Folder) that are mapped in your SharePoint Project as virtual folders. All files that you place inside these folders will then be placed inside the project package when Visual Studio generates it (e.g. Layouts folder, Images folder, …).
Visual Studio 2010 has a new project template which allows you to Import an Existing SharePoint Package (WSP file) and build a new deployment project with the components of that package that you select. This project template will also analyze dependencies between the components so that your new deployment package contains all the required components (and not only the ones you selected). The great thing is that, this WSP file you are importing could have been exported by SharePoint Designer or the result of a Save Site as Template action in the Web UI.
When you press the deploy button on Visual Studio (or press F5 to Debug a SharePoint project), it will perform the following actions, by default:
- Pre-deployment actions (scriptable actions)
- Recycle application pool
- Retract package
- Add package
- Activate features
- Post-deployment actions (scriptable actions)
You can, however, customize the deployment steps to include less steps or even develop you own steps by extending Visual Studio.
Disclaimer: This post is based on notes taken while watching a conference session. For that reason, it may contain incorrect information or data that I might have misunderstood.
SharePoint Conference 2009 is full of really interesting sessions which makes it very hard to choose which ones to attend. The first one I attended, after the keynotes, was Arpan Shah’s SharePoint 2010 Overview, and here are my notes.
The new name of the product is Microsoft SharePoint 2010 (no longer has the Office stamp) and it has a new tag line: “The Business Collaboration Platform for the Enterprise and the Web”.
The new SharePoint Pie (the value proposition chart presented by Microsoft since SharePoint 2007) has a new set of slices:
- Sites
- Communities
- Content
- Search
- Insight
- Composites
Sites
- New User Experience
- The new Ribbon UI makes the interaction easier
- The wiki syntax is used all over the place
- The new SharePoint Workspace 2010 (previously know as Office Groove) is a complete rich client for SharePoint and allows users to take contents offline
- Anywhere Access
- SharePoint can be accessed through mobile devices either using a specific Windows Mobile client or any browser available with the device
- The Office Web Apps allow users to view and edit office documents using only the browser, and supporting real-time simultaneous multiple user collaboration
- SharePoint is cross-browser compatible which means you will have the same experience using Internet Explorer, Firefox or Safari.
- Accessibility has been improved and SharePoint now supports the WCAG 2.0 standard
Communities
- Focus on capturing informal knowledge
- Enterprise wiki, a new and improved wiki site template, is at the center of this concept. It supports page templates and approval workflows but contents are edited with simple wiki functionality.
- SharePoint supports definition of taxonomies, either folksonomies (defined by users) or corporate-defined taxonomies.
- Everything in SharePoint can be tagged and rated using special columns.
- Every item has a noteboard where each user can leave notes and comments
- Social connections
- The user profile has been enhanced
- The new activity feed allows you to see everything your colleagues are doing
- The organization viewer is a Silverlight-based application that shows where each user is in the organization chart
- The profile also shows all the content you have created in SharePoint and all the tags you have used (using a tag cloud)
- Blogging has been improved
- The new template looks a lot better
- Supports rich clients such as Live Writer and Microsoft Word
- You can use REST to retrieve live contents (such as Excel Charts) and post them on the blog
Content
- Content is user-centric.
- There is a new feature called Content Organizer that allows rule-based routing of documents (something similar to what existed for records management, but now more powerful and available for all document libraries).
- Copying from Word maintains all formatting.
- Support for video streaming, including look ahead and bit throttling.
Search
- Improved relevance and search results interface
- Support for wildcards in search queries
- Support for phonetic search in people search queries
- Use of navigators allow you to search with ever typing a search query (really cool stuff)
Insight
- Data interaction is now much easier and powerful
- Excel Services with REST API
- Business Connectivity Services (BCS) allow read and write operations over external data sources, using a typical list interface
- SharePoint Designer or Visual Studio 2010 can be used to graphically create the BCS entities in SharePoint (no more XML editing)
- Access Services allows you to publish an Access Database to SharePoint and interact with it using only the browser
- Decision making is the central part of Business Intelligence
- PerformancePoint Services bring powerful dashboards and analytic controls to SharePoint
- The new Chart Web Part (based on Dundas Charts) is very flexible and a great addition to the out-of-the-box web parts.
Composites
- Composites are no-code user-driven solutions
- Automation and data validation with Forms Services
- Visio Services can be used for diagram interaction
- Access Services add support for database interaction through the browser
- Business Connectivity Services allow access to LOB data
- Sandbox solution deployment allows code to be executed in a controlled environment
- InfoPath forms with code-behind can be deployed with a single click without requiring administrator deployment
IT Pro Investments
- More scalability and governance tools
- Deployment flexibility with more tool support
- Improved IT productivity
Developer Investments
- Increased developer productivity with Visual Studio 2010 integration
- Visual Studio 2010 has great features that really help with deployment
- SharePoint 2010 can be hosted on Windows Vista and Windows 7 for development purposes
Links
Here are a few links that Arpan Shah gave us at the end of the session:
Disclaimer: This post is based on notes taken while watching a conference session. For that reason, it may contain incorrect information or data that I might have misunderstood.
I just came out of the opening keynotes of SharePoint Conference 2009 by Steve Ballmer and Jeff Teper. The keynotes were public, so you might have watched them live on the conference’s web site. If you didn’t, read on…
They were brief overviews about what’s new on the SharePoint world and I can tell you there are lots of new stuff to explore in SharePoint 2010! One of the first important announcements was that SharePoint will be in Public Beta in November 2009 along with SharePoint Designer 2010 and Office 2010. The RTM version is expected to be available in the first half of 2010.
Here’s a list of stuff that caught my interest during these sessions.
Regarding Administration…
- SharePoint Foundation 2010 is the new name for Windows SharePoint Services 4.0
- Usage reporting has been greatly improved,
- Central Administration has been redesigned to be easier to use.
- PowerShell is now used for scriptable administrative tasks, and it feature more than 500 cmdlets.
Regarding Search…
- Search indexes can now be constructed in parallel
- Search relevance has been greatly improved
- Phonetic search is available for person’s names
Regarding Insights (or Business Intelligence)…
- PerformancePoint Services bring really cool dashboard capabilities to SharePoint
- Excel Services allow REST access to workbooks (and workbook objects)
- Visio Services allow users to interact with diagrams through the browser
- Business Connectivity Services (the new version of Business Data Catalog) is a really powerful way to access LOB applications a data storages and now supports read and write operations (and much more…)
- The new SQL Power Pivot technology allows for very fast filtering and sorting operations over very large sets of data (millions of rows in Excel and SharePoint lists)
Regarding the UI…
- Everything gets the Ribbon now, and it really makes things easier to use
- AJAX is everywhere making SharePoint a lot more usable and responsive
- Editing pages is easier and there is support for wiki syntax all over the place
- SharePoint now has a MUI (Multi-language User Interface) allowing you to install language packs and change the site’s language on-the-fly!
- SharePoint now supports WCAG 2.0 accessibility standards.
- SharePoint now supports all major browsers.
Regarding Contents…
- There is a new concept called Document Sets which allow you to define a set of documents that must be managed in a bundle
- The new Silverlight Web Part allows you to host Silverlight applications in SharePoint with no effort.
- Lists (and folders) can now hold 1 million items, document libraries can store 10 millions documents and records repositories can archive tens of millions of documents, without performance hits.
- SharePoint now supports video streaming using Silverlight.
Regarding Social Networking…
- Every item on SharePoint can now be tagged and rated and the taxonomies and content types are consistent across farms in the organization
- There is an out-of-the-box tag cloud control which can be applied to anything you want
- The user profile has been enhanced with a lot of social features, such as a Facebook-like wall and status message, and a user activity feed with much more information regarding its actions on the system
Here’s Jeff Teper’s blog post with the contents of his session: http://blogs.msdn.com/sharepoint/archive/2009/10/19/sharepoint-2010.aspx
I’ll be posting more news on SharePoint 2010 as I attend more sessions.
All of you who, like me, live and breathe SharePoint are probably aware of the most important event this year: SharePoint Conference 2009. Microsoft will unveil the new SharePoint 2010 in four very well planned and intensive days of sessions and meetings.
Luckily, I’ll be present and eager to learn every bit of “What’s New” and “Deep Dive” that will be provided during the event. Let me know if you’ll also be around next week :)
If you want to know more, head out to http://www.mssharepointconference.com.
This series of posts about SharePoint deployment would not be complete if I didn’t write one about using resources in Features to allow localization. After all, SharePoint’s out-of-the-box features use resources all the time. Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index.
Why should I use Resources?
In my opinion, you should always use resource files for your features. Why?
- First, because it’s easy to do even if you only have one language.
- Second, because if you do, all the objects you are provisioning in SharePoint will be localized and will be displayed in the correct language of the website (provided you have deployed the resource file for that language).
Examples of things that should be placed in resource files:
- Title and Description of you feature, so that they will be displayed in the language of the website;
- Site column display name and description;
- Content type name and description;
- List template name and description;
- List instance title and description;
- Custom action title and description.
How do I use it?
There are three steps to use resources in a feature:
- Build the resource (
.resx) files; - Place the resource files in the correct folder;
- Use the resource strings in the feature manifest and element manifests.
Note: The next sections show how to use feature-specific resources. I’ll briefly discuss shared resources in the end of the post.
Building the resource (.resx) files
The best way to build the resource files is using Visual Studio 2008, but you can do it manually on any text editor since they’re just XML text files.
<?xml version="1.0" encoding="utf-8"?>
<root>
<resheader name="resmimetype">
<value>text/microsoft-resx</value>
</resheader>
<resheader name="version">
<value>2.0</value>
</resheader>
<resheader name="reader">
<value>
System.Resources.ResXResourceReader,
System.Windows.Forms,
Version=2.0.0.0,
Culture=neutral,
PublicKeyToken=b77a5c561934e089
</value>
</resheader>
<resheader name="writer">
<value>
System.Resources.ResXResourceWriter,
System.Windows.Forms,
Version=2.0.0.0,
Culture=neutral,
PublicKeyToken=b77a5c561934e089
</value>
</resheader>
<data name="MyFeatureName" xml:space="preserve">
<value>My Feature Name</value>
</data>
<data name="MyFieldDisplayName" xml:space="preserve">
<value>My Field Display Name</value>
</data>
<data name="MyFieldChoice1" xml:space="preserve">
<value>My Choice 1</value>
</data>
<data name="MyFieldChoice2" xml:space="preserve">
<value>My Choice 2</value>
</data>
</root>
See above an example of a resource (.resx) file. The <data> elements are the ones that hold the localized strings:
- The
name attribute is the key used to retrieve the localized string;
- The
<value> child element is the localized string itself.
Each language must have its own resource file which follows a specific naming convention:
- The main resource file must be called
Resources.resx. This is the culture neutral resource file (or fall back resource file) which will be used by SharePoint whenever there is no resource file for a specific culture.
- All culture specific resource files must be named
Resources.[culture].resx. Some examples:
Resources.en-US.resx (english – United States) Resources.pt-PT.resx (portuguese – Portugal) Resources.fr-FR.resx (french – France) Resources.pt-BR.resx (portuguese – Brazil)
Placing the resource files in the correct folder
These files must be placed in a Resources folder inside your feature’s folder. So, if your feature’s folder is C:\…\12\TEMPLATE\FEATURES\MyFeature, the resource files need to be placed in the folder C:\…\12\TEMPLATE\FEATURES\MyFeature\Resources.
Resources and the Feature Manifest
After you have created the resource files and placed the in the correct folder, you can now used them in your feature manifest (feature.xml).
<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
Title="$Resources:MyFeatureName"
Scope="Site"
Version="1.0.0.0">
<ElementManifests>
<ElementManifest Location="SiteColumns.xml"/>
<ElementFile Location="Resources\Resources.resx" />
<ElementFile Location="Resources\Resources.pt-PT.resx" />
<ElementFile Location="Resources\Resources.es-ES.resx" />
</ElementManifests>
</Feature>
The sample above, shows a feature manifest that uses resources to specify the feature title. As you can see, the value of the Title attribute is $Resources:MyFeatureName. This tells SharePoint that it should check the resource file for the current website’s culture and retrieve the string that has the key MyFeatureName.
Notice the use of <ElementFile> elements to reference the resource files in the feature. This is required if you are deploying this feature through a solution package (.wsp).
Important: because we are using feature-specific resource files (resource files that are only used for this specific feature), you cannot use the DefaultResourceFile attribute on the <Feature> element. If you do, SharePoint will not look for resource files in the local Resources folder for this feature.
Resources and the Element Manifest
Besides using localized strings to specify the feature title and description, you can (and should) use localized strings for most feature elements.
<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Field Type="Choice"
DisplayName="$Resources:MyFieldDisplayName"
Required="FALSE"
Format="Dropdown"
FillInChoice="FALSE"
ID="{485b2176-4cfc-4923-8085-c003b85dab36}"
StaticName="MyField"
Name="MyField">
<Default>$Resources:MyFieldChoice1</Default>
<CHOICES>
<CHOICE>$Resources:MyFieldChoice1</CHOICE>
<CHOICE>$Resources:MyFieldChoice2</CHOICE>
</CHOICES>
</Field>
</Elements>
The sample above specifies a choice field, and uses localized strings for:
- Field display name
- Each of the field’s choices
- The field’s default choice
The theory is exactly the same as it was used for the feature manifest: you use the expression $Resources:[key] whenever you want SharePoint to retrieve a localized string from the resource file of the current website’s culture.
Shared Resource Files
The method shown in the previous sections assumed that each feature has its own resource files. However, that is not always the case and SharePoint itself uses shared resource files. That is, resource files that can be shared by multiple features.
There are only two differences when using shared resource files:
- The folder where the resource files are placed;
- The way you reference the localized string in you feature manifest and element manifests.
Other than that, the file format and contents can be exactly the same.
Folder for Shared Resources
Shared resource files must be placed in the folder C:\…\12\Resources instead of the local Resources folder inside the feature folder.
Referencing Shared Resources
Because the shared resources files can have any name you want, you must reference the localized strings in a more specific way, so as to tell SharePoint which resource file holds a particular string.
<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
Title="$Resources:MyResources,MyFeatureName"
Scope="Site"
Version="1.0.0.0">
<ElementManifests>
<ElementManifest Location="SiteColumns.xml"/>
</ElementManifests>
</Feature>
As you can see in the above sample, instead of $Resources:MyFeatureName I’m referencing the localized string with $Resources:MyResources,MyFeatureName. This tells SharePoint to look for:
- A localized string whose key is
MyFeatureName
- In a resource file named
MyResources.[Culture].resx
- In the
C:\…\12\Resources folder
If all your strings are in the same shared resource file, then you can specify that file as the default resource file and reference the strings as shown in the first sample.
<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
Title="$Resources:MyFeatureName"
DefaultResourceFile="MyResources"
Scope="Site"
Version="1.0.0.0">
<ElementManifests>
<ElementManifest Location="SiteColumns.xml"/>
</ElementManifests>
</Feature>
The sample above does exactly the same as the previous one. The only difference is that it specifies MyResources.[culture].resx as the default resource file and, because of that, you don’t need to specify it on all references to the localized strings.
Additional Notes
So, how does SharePoint choose which resource file to use when loading the localized strings?
- Looks for the resource file of the exact culture of the website. If you have a website based on a portuguese (pt-PT) site template, it will look for the
Resources.pt-PT.resx. If it’s there, it loads all the strings from it.
- If it’s not there, it looks for any resource files of the same culture, even if it has a different location. So if your website’s language is pt-PT (Portuguese – Portugal) and you don’t have a
Resources.pt-PT.resx file, but you have a Resources.pt-BR.resx (Portuguese – Brazil) file, then SharePoint will use it.
- If there is no resource file for the website’s culture, SharePoint will use the fall back resource file (
Resources.resx).
Samples
You can download samples for:
These samples include:
- The solution manifest file (
manifest.xml).
- The solution cab structure file (
solution.ddf).
- The feature manifest file (
Feature.xml).
- The element manifest file (
SiteColumns.xml).
- The resource files (
.resx)
- A batch file (
build.bat) that creates the solution package
Warning: Do not install both solutions in the same farm, since some of the IDs are the same and the feature has the same name on both solutions. If you want to use it as is, test each solution separately, removing one before installing the other.
Notice: These samples are given for illustrative purposes only. Feel free to modify and use them as templates for your solutions and features.
Summary
This post is about developing features that associate other features to an existing site definition. This is one of the most powerful types of feature since it allows you to add new functionality to existing site definitions. Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index.
Package Structure
As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:
- The feature manifest file (which must be named
feature.xml) - One or more element manifest files
The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the feature stapling (feature site template association).
You can then place these two files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).
Feature Stapling
Feature stapling is the process of associating features to existing site definitions so that, when a new site is provisioned from that definition the associated features are automatically activated.
This means that you need, at least, two features to do this:
- The feature (or features) you wish to associate (that is, to staple) to a site definition;
- The feature that performs the association (the stapler).
The first one can be any feature with scope Site or Web. The second is the one I’m presenting in this post.
Allowed Scopes
The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with feature site template association elements can be deployed to Site Collection, Web Application or Farm scopes.
Feature Manifest
I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.
<?xml version="1.0" encoding="utf-8" ?>
<Feature
xmlns="http://schemas.microsoft.com/sharepoint/"
Id="{8213A053-46B0-43f9-B00C-B2A8CF7A3355}"
Title="My Feature Stapling"
Description="This feature staples other features to a
site definition."
Scope="Farm"
Creator="Create IT"
Version="1.0.0.0">
<ElementManifests>
<ElementManifest Location="Elements.xml"/>
</ElementManifests>
</Feature>
Notes about this feature manifest:
- The title of the feature is My Feature Stapling.
- It will be deployed as a Farm feature, since it's
Scope value is Farm. By default, SharePoint automatically activates features of this scope. You can, however, override this behaviour by setting the ActivateOnDefault attribute to false on the Feature element.
- It references a single element manifest file:
Elements.xml.
Element Manifest
The element manifest file can have any name you wish (in this example it's called Elements.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <FeatureSiteTemplateAssociation> element which is used to associate features to existing site definitions.
<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<!-- My Site Columns -->
<FeatureSiteTemplateAssociation
Id="{CC3144A5-E055-4474-928E-5D21CDE53D38}"
TemplateName="STS#0" />
<!-- My Content Types -->
<FeatureSiteTemplateAssociation
Id="{E739683D-ACB8-4187-A764-1323BE76D12D}"
TemplateName="STS#0" />
</Elements>
This example associates two features with the Team Site definition. The <FeatureSiteTemplateAssociation> element has no child elements and only two attributes:
Id - (required) The GUID of the feature that is to be stapled to the site definition. TemplateName - (required) The name of the site definition including the configuration Id. For SharePoint’s out-of-the-box site definitions, this attribute can be:
STS#0 (Team Site) STS#1 (Blank Site) STS#2 (Document Workspace) MPS#0 (Basic Meeting Workspace) MPS#1 (Blank Meeting Workspace) MPS#2 (Decision Meeting Workspace) MPS#3 (Social Meeting Workspace) MPS#4 (Multipage Meeting Workspace) CENTRALADMIN#0 (Central Administration) WIKI#0 (Wiki Site) BLOG#0 (Blog Site) BDR#0 (Document Center) OFFILE#1 (Records Center) SPSMSITEHOST#0 (My Site Host) SPSMSITE#0 (Personalization Site) CMSPUBLISHING#0 (Publishing Site) BLANKINTERNET#2 (Publishing Site with Workflow) BLANKINTERNETCONTAINER#0 (Publishing Portal) SPSPORTAL#0 (Collaboration Portal) SPSNHOME#0 (News Site) SPSITES#0 (Site Directory) SPSREPORTCENTER#0 (Report Center) SRCHCEN#0 (Search Center with Tabs) SRCHCENTERLITE#0 (Search Center)
There can be other site definitions depending on which site templates you have installed on your farm. The best way to check which ones you can use is to go to the folder C:\…\12\TEMPLATE\[LCID]\XML where [LCID] represent the Language ID of the site definition you are looking for, and open each webtemp*.xml file.
Each of these files will have the following structure:
<?xml version="1.0" encoding="utf-8"?>
<!-- _lcid="1033" _version="12.0.4518" _dal="1" -->
<!-- _LocalBinding -->
<Templates xmlns:ows="Microsoft SharePoint">
<Template Name="STS" ID="1">
<Configuration ID="0"
Title="Team Site"
Hidden="FALSE"
ImageUrl="/_layouts/images/stsprev.png"
Description="A site for teams to quickly […]
DisplayCategory="Collaboration" >
</Configuration>
<Configuration ID="1"
Title="Blank Site"
Hidden="FALSE"
ImageUrl="/_layouts/images/blankprev.png"
Description="A blank site for you to […]
DisplayCategory="Collaboration"
AllowGlobalFeatureAssociations="False" >
</Configuration>
<Configuration ID="2"
Title="Document Workspace"
Hidden="FALSE"
ImageUrl="/_layouts/images/dwsprev.png"
Description="A site for colleagues to work[…]
DisplayCategory="Collaboration" >
</Configuration>
[...]
</Template>
</Templates>
In the sample above you can see the description of the three configurations of the STS site template. To build the TemplateName required for the feature site template association, you get the template name (attribute Name of the element Template), which in this case is STS, add a hash sign (#) and complete the string with the configuration ID (attribute ID of the element Configuration), which in this case can be 0, 1 or 2, depending on the chosen configuration.
Sample
You can download this sample here. This sample includes:
- The solution manifest file (
manifest.xml).
- The solution cab structure file (
solution.ddf).
- The feature manifest file (
Feature.xml).
- The feature site template association element manifest file (
Elements.xml).
- A batch file (
build.bat) that creates the solution package (MyFeatureStapling.wsp).
Notice: This sample is given for illustrative purposes only. Feel free to modify and use it as a template for your solutions and features.
Summary
This post is about developing features to bind content types to lists that were provisioned through an onet.xml file. Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index.
Package Structure
As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:
- The feature manifest file (which must be named
feature.xml) - One or more element manifest files
The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the binding of content types.
You can then place these two files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).
Content Type Binding
When you provision a list through a feature, using the method explained in the post SharePoint 2007 Deployment: List Template Features, you can bind a content type to it only by editing the schema.xml file of the list template.
However, if the list was provisioned through a site definition (onet.xml file) and you had no access to its definition, you must do it using a Content Type Binding feature element. This can only be used to attach a content type to a list provisioned through a site definition.
Allowed Scopes
The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with content type binding elements can only be deployed to a Site Collection scope.
Attempting to install a feature of another scope that contains content type binding elements, will result in an error.
Feature Manifest
I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.
<?xml version="1.0" encoding="utf-8" ?>
<Feature
xmlns="http://schemas.microsoft.com/sharepoint/"
Id="{ACDECF85-BDF7-446c-AC1B-C5F133C83F15}"
Title="Content Type Binding"
Description="This feature binds a content type to the masterpage
gallery."
Scope="Site"
Creator="Create IT"
Version="1.0.0.0">
<ElementManifests>
<ElementManifest Location="ContentTypeBinding.xml"/>
</ElementManifests>
</Feature>Notes about this feature manifest:
- The title of the feature is Content Type Binding.
- It will be deployed as a Site Collection feature, since it's
Scope value is Site. - It references a single element manifest file:
ContentTypeBinding.xml.
Element Manifest
The element manifest file can have any name you wish (in this example it's called ContentTypeBinding.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <ContentTypeBinding> element which is used to binding Content Types to list definitions.
<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<ContentTypeBinding
ContentTypeId="0x010101"
ListUrl="_catalogs/masterpage" />
</Elements>This example binds the content type Form (which has the ID 0x010101) to the master page gallery (which has the URL _catalogs/masterpage). There <ContentTypeBinding> element has no child elements, and only two attributes:
ContentTypeId - (required) The ID of the content type that will be bound to a list. ListUrl – (required) The URL of the list to which the content type will be bound.
Additional Notes
The content type will be bound to the list definition as soon as the administrator activates this feature on a site collection. However, deactivating the feature will not remove the connection between the content type and the list. If you wish to remove it, you must do so manually.
Sample
You can download this sample here. This sample includes:
- The solution manifest file (
manifest.xml). - The solution cab structure file (
solution.ddf). - The feature manifest file (
feature.xml). - The content type binding element manifest file (
ContentTypeBinding.xml). - A batch file (
build.bat) that creates the solution package (ContentTypeBinding.wsp).
Notice: This sample is given for illustrative purposes only. Feel free to modify and use it as a template for your solutions and features.
Summary
This post is about developing features to register event receivers. Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index.
Package Structure
As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:
- The feature manifest file (which must be named
feature.xml) - One or more element manifest files
The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the registration of event receivers.
Additionally, you must include the assembly that contains the event receiver class in the solution package, so that it gets deployed to the Global Assembly Cache. Follow the instructions in the post SharePoint 2007 Deployment: Creating Solutions on how to package these three files (both manifests plus the assembly file) on a SharePoint Solution file.
Events Receivers
SharePoint allows you to handle several events that are fired according to actions performed on items, lists and web sites. Event are handled through event receivers, which are classes that implement a method for each event that is handled.
Once an event receiver is developed, compiled into an assembly and deployed to the GAC, it must be registered to a content type, a list or a web site in order to handle its events. That can be done through the API (or third-party tool such as Event Handler Explorer) or, concerning item and list event receivers, through this type of feature.
Allowed Scopes
The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with event registration elements can only be deployed to Web Site scopes.
Feature Manifest
I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.
<?xml version="1.0" encoding="utf-8" ?>
<Feature
xmlns="http://schemas.microsoft.com/sharepoint/"
Id="{282902FB-0369-4f98-93C5-7FD7121CE164}"
Title="My Event Receiver"
Description="This feature registers My Event Receiver."
Scope="Web"
Creator="Create IT"
Version="1.0.0.0">
<ElementManifests>
<ElementManifest Location="EventReceivers.xml"/>
</ElementManifests>
</Feature>Notes about this feature manifest:
- The title of the feature is My Event Receiver.
- It will be deployed as a Web Site feature, since it's
Scope value is Web. - It references a single element manifest file:
EventReceivers.xml.
Element Manifest
The element manifest file can have any name you wish (in this example it's called EventReceivers.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <Receivers> element which is used to register event receivers that will handle list events.
<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Receivers
ListTemplateId="3500"
ListTemplateOwner="{11663D54-6152-4532-ABF5-FC08FAC216A7}">
<Receiver>
<Assembly>
MyEventReceiver,
Version=1.0.0.0,
Culture=Neutral,
PublicKeyToken=6c0c7604915f786e
</Assembly>
<Class>MyEventReceiver.MyEventReceiver</Class>
<Name>My Event Receiver</Name>
<Type>ItemAdded</Type>
<SequenceNumber>10000</SequenceNumber>
</Receiver>
</Receivers>
</Elements>
The example above registers an event receiver to all lists based on list template with ID 3500 that was deployed by a feature with the ID {11663D54-6152-4532-ABF5-FC08FAC216A7}. The receiver is the MyEventReceiver.MyEventReceiver class included in the assembly MyEventReceiver.dll that is installed in the GAC, and it handles the ItemAdded event on these lists.
The Receivers Element
The <Receivers> element is used to specify the list template to which the event receiver will be registered. There can be any number of <Receivers> elements in a single element manifest file. Here is a summary of the possible attributes of this element:
ListTemplateId - (required) Specifies the ID of the list template to which the event receiver will be registered. If you wish to register an event receiver to one of SharePoint’s list templates, you can use one of the following values: - 100 – Generic List
- 101 – Document Library
- 102 – Survey
- 103 – Links List
- 104 – Announcements List
- 105 – Contacts List
- 106 – Events List
- 107 – Tasks List
- 108 – Discussion Board
- 109 – Picture Library
- 110 – Data Sources
- 111 – Site Template Gallery
- 112 – User Information List
- 113 – Web Part Gallery
- 114 – List Template Gallery
- 115 – XML Form Library
- 116 – Master Pages Gallery
- 117 – No-Code Workflows
- 118 – Custom Workflow Process
- 119 – Wiki Page Library
- 120 – Custom grid for a list
- 130 – Data Connection Library
- 140 – Workflow History
- 150 – Gantt Tasks List
- 200 – Meeting Workspace Series List
- 201 – Meeting Workspace Agenda List
- 202 – Meeting Workspace Attendees List
- 204 – Meeting Workspace Decisions List
- 207 – Meeting Workspace Objectives List
- 210 – Meeting Workspace text box
- 211 – Meeting Workspace Things To Bring List
- 212 – Meeting Workspace Pages List
- 301 – Blog Posts List
- 302 – Blog Comments List
- 303 – Blog Categories List
- 1100 – Issue Tracking
- 1200 – Administrator Tasks List
ListTemplateOwner - (optional) Specifies the GUID of the Feature where the list template is defined, or the name of the site definition that registered the list.
The Receiver Element
The <Receiver> element specifies which class implements the event receiver and which list event it handles. There can any number <Receiver> child elements inside a <Receivers> parent element. This element has no attributes, but has six child elements, which are listed below:
Assembly – The strong name of the assembly that contains the event receiver class. The strong name is composed of the name of the assembly (without the .dll extension), followed by a comma and the assembly version, followed by a comma and the assembly culture, followed by a comma and the assembly’s public key token. Class – The name of the class (including the namespace) that contains the implementation of the event receiver. Name – The name of the event receiver. This value is used to identify it if you wish to retrieve it through the API. Type – The event that the event receiver handles. Possible values are: ContextEvent – The list received a context event. EmailReceived – The list received an e-mail message. FieldAdded – A field was added to the list. FieldAdding – A field is being added to the list. FieldDeleted – A field was removed from the list. FieldDeleting – A field is being removed from the list. FieldUpdated – A field was updated in the list. FieldUpdating – A field is being updated in the list. ItemAdding – An item is being added to the list. ItemAdded – An item was added to the list. ItemAttachmentAdded – An attachment was added to an item. ItemAttachmentAdding – An attachment is being added to an item. ItemAttachmentDeleted – An attachment was removed from an item. ItemAttachmentDeleting – An attachment is being removed from an item. ItemCheckedIn – An item was checked-in in the list. ItemCheckingIn – An item is being checked-in in the list. ItemCheckedOut – An item was checked-out in the list. ItemCheckingOut – An item is being checked-out in the list. ItemDeleted – An item was removed from the list. ItemDeleting – An item is being removed from the list. ItemFileConverted – A file was converted. ItemFileMoved – A file was moved. ItemFileMoving – A file is being moved. ItemUncheckedOut – An item was unchecked-out in the list. ItemUncheckingOut – An item is being unchecked-out in the list. ItemUpdated – An item was updated in the list. ItemUpdating – An item is being updated in the list.
SequenceNumber – Specifies the order of the event receiver when more than one handler is associated with the same event. A high sequence number (10000 or higher) should be used to prevent problems with SharePoint’s own event handlers. Data – Specifies a string that will be passed as a parameter to the receiver method when handling the event.
Sample
You can download this sample here. This sample includes:
- The solution manifest file (
manifest.xml). - The solution cab structure file (
solution.ddf). - The feature manifest file (
feature.xml). - The event receiver element manifest file (
EventReceivers.xml). - A fake assembly (
MyEventReceiver.dll) that must be replaced by your own assembly. Important: this file is not a real assembly containing an event receiver class, hence it will not work if deployed as is to your Sharepoint environment. - A batch file (
build.bat) that creates the solution package (MyEventReceiver.wsp).
Notice: This sample is given for illustrative purposes only and it should not be used as is in your SharePoint environment. Feel free to modify and use it as a template for your solutions and features.
Terminou ontem o DevDays 2009, o evento anual da Microsoft Portugal destinado a juntar profissionais e curiosos em torno das tecnologias da casa. Este ano foi organizado no campus do Tagus Park do Instituto Superior Técnico, onde tive o privilégio de dar aulas há uns anos atrás. Foi, portanto, uma espécie de regresso ao passado :)
Pelas informações que tenho, estiveram cerca de 1000 pessoas no evento, o que é excelente. A abertura do Nuno Costa e do Pedro Rosa conseguiu cativar bem os presentes e dar-lhes um overview do que aí vem.
Tal como no ano passado, foi-me dada a oportunidade de fazer uma sessão em torno do SharePoint. Tratou-se da sessão com WUX207 – Deployment em SharePoint, que apresentei em conjunto com o Raúl Ribeiro. Podem fazer o download da apresentação aqui e de alguns dos exemplos aqui.
Além de nós, outros dois colegas da Create IT fizeram apresentações no DevDays este ano. Estou a falar do Jota, que já é veterano nestas andanças, e do Marco, que esteve muito bem na sua sessão sobre Serviços REST sobre WCF.
Among SharePoint 2007’s User Profile features, one of the most useful is the Profile Import. This feature allows you to import existing user accounts from Active Directory, an LDAP server or the Business Data Catalog, to the User Profile Store. Even better, it allows you to map the User Profile properties to user account properties (from Active Directory, for instance) so that they’re automatically imported. Additionally, you can schedule regular imports so that SharePoint’s User Profile is kept in sync with Active Directory’s user account.
Needless to say, this can save you a lot of time, especially if you already have a large base of users with a few populated properties on Active Directory. This is, however, a one way process, that is, only from the Directory to SharePoint, never the other way around.
One question you might be asking is: what if I update a User Profile on SharePoint, putting new data on a mapped property and then a Profile Import occurs?
The answer to this is not straightforward, because it depends on your answer to one or two questions.
Question 1: In Active Directory (or LDAP server), does the mapped property have a value?
If so, then the value in SharePoint’s User Profile property will get overwritten by the one in the directory’s user account property. No need to check Question 2.
If not, then check Question 2.
Question 2: Did you update the User Profile using SharePoint’s UI, or using the API?
If you used the SharePoint’s UI then the User Profile property will retain the value, since the mapped property in the directory service has no value to replace it.
If you used the API, the Profile Import will clear the value of the mapped property on SharePoint’s User Profile. I cannot explain why this difference exists, but I have seen it happen.
Conclusion: If you are updating User Profile properties by using SharePoint’ API, make sure you remove their mappings (to directory services’ properties) to prevent you from losing data when the Profile Import executes.