Wednesday 12 December 2012

Does SharePoint 2010 solution work on SharePoint 2013?





Answer : The solution gets deployed to the 14 hive, because of a setting in the manifest.xml file in the page. If you open up the package in Visual Studio, or you can open the manifest file directly to change this.
If you created your solution in SharePoint 2010 the <Solution> element in the manifest file will have a property that says "SharePointProductVersion="14.0". If you change this to 15.0 the solution should deploy to the 15 hive.
Posted by at No comments:

Wednesday 21 November 2012

Creating a WCF web service and calling JSON objects from JQUERY – SharePoint 2010 C#

WCF or ASMX?

First off, why create a WCF web service in SharePoint instead of the old ASMX web service? Did some reading on this and would recommend these blog posts on the subject:
http://dotnetarchitecthouston.com/post/WCF-versus-ASMX-services.aspx
http://www.bishoylabib.com/2009/08/comparing-asmx-and-wcf.html

Creating a WCF web service in Visual Studio 2010

1. Start off by creating a new SharePoint project in visual studio

2. Call it WCFService (or name of your choice)
3. Create a new “Mapped folder” by right clicking on the project and select “Add”
4. Point to the ISAPI folder (Usually: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI)
5. Create a folder called WCFService (or name of your choice)
6. Create a folder called “WCFObjects” (or name of your choice)
7. Add a class called “Staff” in the newly created folder
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace WCFService
{
public class Staff
{
public string name { get; set; }
public string country { get; set; }
}
}

8. Create an Interface class called “IService.cs” with following code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;
using System.ServiceModel.Web;

namespace WCFService
{
[ServiceContract(Namespace = "WCFService.Service")]
public interface IService
{
[WebInvoke(UriTemplate = "/returnStaff", Method = "POST", BodyStyle = WebMessageBodyStyle.WrappedRequest, ResponseFormat = WebMessageFormat.Json)]
[OperationContract]
List<Staff> returnStaff(string staffName, string staffCountry);
}
}
9. Now we need to create the /returnStaff method defined in the interface
10. Create a class called “Service.cs” with following code in it:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;
using System.ServiceModel.Activation;
namespace WCFService
{
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class Service:IService
{
public List returnStaff(string staffName, string staffCountry)
{
//create staff list
List staffList = new List();
Staff staff = new Staff();
staff.name = staffName;
staff.country = staffCountry;
//add staff to list
staffList.Add(staff);
//return list
return staffList;
}
}
}
11. Now that we have the logic for the web service, the actual Service.svc can be created
12. Add a “Service.svc” file in the ISAPI\WCFService folder with following code in it:

<%@ Assembly Name="$SharePoint.Project.AssemblyFullName$"%>
<%@ServiceHost Debug="true" Language="C#" CodeBehind="Service.cs" Service="WCFService.Service, WCFService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=KEY TOKEN"
Factory="Microsoft.SharePoint.Client.Services.MultipleBaseAddressWebServiceHostFactory, Microsoft.SharePoint.Client.ServerRuntime, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

13. Put your token id from the assembly instead of “KEY TOKEN”
14. Your solution should now look like this:

15. Deploy your solution
16. Try to go to “http://yourservername/_vti_bin/WCFService/Service.svc to check if your service is working
17. You will get “Endpoint not found” as a return message from your service

Calling web service from client side JQUERY (ASPX) in a Web Part

1. Create a new SharePoint project called “WebParts”
2.  Create a new visual web part called “StaffViewer” (http://weblogs.asp.net/sreejukg/archive/2011/03/26/create-a-visual-web-part-using-visual-studio-2010.aspx)
3. Add following code to the StaffViewerUserControl.ascx to create input boxes and tables to view data:
<table id="tblInput">
<tr>
<td>
Name:
</td>
<td>
<input type="text" id="name" />
</td>
</tr>
<tr>
<td>
Country:
</td>
<td>
<input type="text" id="country" />
</td>
<td>
<button id="btnCallService" type="button" onclick="getStaff()">
Call web service</button>
</td>
</tr>
</table>
<table id="tblStaff">
</table>
4. Add a JQUERY function called “getStaff” which calls the WCF web service

function getStaff() {
//input parameters
var name = $('#name').val();
var country = $('#country').val();
$.ajax({
type: "POST",
contentType: "application/json; charset=utf-8",
dataType: "json",
//url to web service
url: "/_vti_bin/WCFService/Service.svc/returnStaff",
//input parameters (JSON)
data: JSON.stringify({ staffName: name, staffCountry: country }),
success: function (data) {
var staff = data;
//iterate through data
$.each(staff, function (index, person) {
//view data
$('#tblStaff').append('
Name: ' + person.name + '| Country: ' + person.country + '
');
});
}
});
};
5. Note the  ”JSON.stringify({ staffName: name, staffCountry: country })” which passes through parameters as in JSON format
6. Add a .click event to the button

$(function () {
$("btnCallService").click(function () {
getStaff();
});
});
7. Your solution should now look like this:

8. Deploy the solution
9. Activate the “Web Part” feature
10. Add the Web Part to your page

11. Type a name and country, then click “Call web service”
12. The service is now called, JSON array returned to user control and the result is displayed on the page
Posted by at No comments:

Friday 28 September 2012

101 Code Samples SharePoint 2010

Posted by at No comments:

Data Querying Options (SharePoint 2010) – Server OM vs Client OM vs REST vs LINQ vs Search API


SharePoint 2010 allows various options to query SharePoint data within SharePoint and from outside of SharePoint.It allows both server side and client side data access technologies. This article will provide high level features, pros, and cons of each server side and client side data access technologies. Additionally, SharePoint allows developers to write custom WCF Services and write custom queries based on Enterprise Search API. Hopefully at the end of this article, it would allow you to make decision which option would work best for appropriate use cases.

Server Side Object Model -  SPSite, SPWeb, SPList, SPDocumentLibrary, SPListItem, SPView, SPField, SPContentType etc.
  • Major features
    • Implemented as Microsoft.SharePoint Namespace
    • Code must run on the SharePoint Servers
    • Programmatic approach to interact with SharePoint objects
    • APIs to provision and maintain building blocks like lists, site columns, content types, or pages
    • APIs to iterate through farm, web application, site, web, list, list item, fields, content types collections
  • Pros
    • Virtually any APIs or objects available to access SharePoint data
    • Easy to learn API, familiar concepts such as foreach() to loop through collections
    • Supported in Sandbox solutions. Site collection level APIs works great in Sandbox Solutions
  • Cons
    • Not available on the remote, Non-SharePoint servers
    • foreach(), GetItemById, GetListItems increase resource utilization and may affect performance
    • Requires IISREST while deploying farm level code on the server, Sandbox solutions doesn’t require IISReset
Server Side Object Model – SPQuery and SPSiteDataQuery
  • Major features
    • SPQuery available since SharePoint 2003 days and SPSiteDataQuery available since MOSS 2007 days
    • Implemented as Microsoft.SharePoint Namespace
    • Code must run on the SharePoint Servers
    • Programmatic approach to interact with SharePoint objects
    • SPQuery executes query against single list or performs join with CAML Predicate on multiple lists on lookup columns with in site collection
    • SPDataQuery executes query  against multiple lists to  aggregate results, scoped at site collection level.
    • SPDataQuery returns data as ADO.NET data table. It has potential performance issues for rollup views because it first loops through all the lists and then process the query – multiple round trips
    • Fastest query option but good only for small scopes
    • Developer must parse CAML fragments and access to columns is not strongly typed
    • SPQuery can query external list data within a site
  • Pros
    • CAML is very fast – compared to foreach, fastest way to data access
    • Supports complex queries, such as sorting, filtering, and joining on multiple sources, much better options compared to SPList.GetListItems
    • Supported in Sandbox solutions. Site collection level APIs works great in Sandbox Solutions
    • Query Throttling override is supported
      • You must use this option to execute queries that return large sets, by default more than 5000 records are blocked, these settings are web application level, defined in central admin, must adhere in Office 365
      • QueryThrottleMode = SPQueryThrottleOption.Override, Object Model Override = Yes, and Query Runs under Super Users (User with Full Read or Full Control Permission)
      • Use List Level Indexing in conjunction with SPQuery to avoid List Throttling limit
  • Cons
    • Not available on the remote, Non-SharePoint servers
    • Small scope, e.g. targeted to a particular list or library
    • Affected by List Throttling Limit (default List View Threshold is >5000)
    • CAML means low developer productivity – Hard coded column names, not strongly typed, quirky syntax, lack of tooling support, and difficult debugging
    • Requires IISREST while deploying farm level code on the server, Sandbox solutions doesn’t require IISReset
Server Side Object Model – LINQ to SharePoint
  • Major features
    • New in SharePoint 2010
    • Implemented as Microsoft.SharePoint.Linq Namespace
    • Executes query against single list or performs join on multiple lists on lookup columns with in site collection, You can’t aggregate multiple lists data without lookup column
    • Microsoft supplies spmetal.exe to generate LINQ to SharePoint entities
    • Strongly typed entities to perform CRUD operations against SharePoint data
    • Translates into CAML query during runtime
  • Pros
    • Not fastest as CAML but still very fast compare to foreach, Approx. 10% slower than SPQuery
    • Performs compile time errors against strongly typed objects from spmetal.exe
    • High productivity, IntelliSense, and less error-prone programming
    • Supported in Sandbox solutions.
  • Cons
    • Needs to regenerate the entities if List Schema changes
    • Query Throttling override is not supported
    • Small scope, e.g. targeted to a particular list or library
    • SPMetal can’t generate entity classes for more than one web
    • Although its minor, additional overhead occurs while converting query to CAML during runtime
    • Can’t query external list data within a site
    • Requires IISREST while deploying farm level code on the server, Sandbox solutions doesn’t require IISReset
Client Side Object Model
  • Major features
    • New in SharePoint 2010,  Subset of server OM functionality but similar APIs
    • Implemented as WCF Service – Client.svc, Adding Client.svc reference directly in Visual Studio is prohibited
    • Three different Models - .NET Managed, Silverlight, ECMAScript/JavaScript
      • For Javascript CSOM, reference SP.js is located under : %ProgramFiles%/Common Files/Microsoft Shared/Web Server Extensions/14/TEMPLATE/LAYOUTS
      • For Silverlight CSOM, Add the reference to Microsoft.SharePoint.Client.Silverlight.dll  and Microsoft.SharePoint.Client.Silverlight.Runtime.dll located under %ProgramFiles%/Common Files/Microsoft Shared/Web Server Extensions/14/TEMPLATE/LAYOUTS/ClientBin
      • For .NET Manage Client CSOM, Add reference to Microsoft.SharePoint.Client.dll and        Microsoft.SharePoint.Client.Runtime.dll located under %ProgramFiles%/Common Files/Microsoft Shared/web server extensions/14/ISAPI
    • CSOM executes query against single list or performs join with CAML Predicate on multiple lists on lookup columns with in site collection
    • Typically .NET Managed CSOM code will run outside of SharePoint in remote .NET or CRM applications, Silverlight CSOM is used only in Silverlight applications, and JavaScript CSOM  is must be used only in SharePoint Site, JCSOM can’t be used in a classic ASP.NET Site due to cross-scripting issue.
  • Pros
    • Ideal for accessing cross farm data when Search API is not an option or real-time remote data access is required
    • Allows submitting CAML queries directly from client side logic, making it fastest client side data access option
    • Supports Async processing, Request Throttling, and Batch object handling
    • CSOM can query external list data within a site
    • Supports Site Collection level SharePoint Object Model. It doesn’t provide administrative objects or objects that are scoped higher than site collection.
    • No IISREST is required while deploying a Silverlight or JavaScript CSOM based implementation. e.g. JavaScript CSOM can be implemented with just a Content Editor Web part.
  • Cons
    • Can’t access data outside of current site collection
    • Query Throttling override is not supported
    • Since these are web services interface, can’t accessed from Sandbox Solutions
    • Requires learning of CAML to query small result set – Hard coded, Un complied, Not strongly typed CAML query
    • Can’t elevate the user privilege using RunWithElevatedPrivilege or Impersonate using CSOM. It means, results retrieved using CSOM are always security trimmed by default.
    • Requires IISREST while deploying farm level, .NET managed CSOM code on the server
REST Based API – WCF Data Services
  • Major Features
    • New in SharePoint 2010
    • Implemented as REST based WCF Data Services – ListData.svc, REST is HTTP-based XML data transfer design pattern based on OData protocol – Stateless, cacheable, uniform, Able to maintain & browse lists using HTTP verbs – GET, POST, PUT, DELETE, and MERGE
    • Returns results in ATOM Feed or JSON format (For JavaScript clients)
    • Available for Lists (ListData.svc) and Excel Services REST API (ExcelRest.aspx)
    • Add Service Reference to ListData.svc, Proxy class provides LINQ-based strongly-typed access
  • Pros
    • Confronts Open Data (OData) protocol to support batching, concurrency, and partial updates
    • Client-side technique with strongly typed access, Intelligence Support, LINQ style productivity, and compile time errors checking against from proxy class
    • Can be used in Silverlight as a replacement for Client OM for strongly typed access
    • Can be query from any kind of client : Silverlight, Javascript, and even from PHP and JAVA
  • Cons
    • Supported only for Lists and Excel Services
    • Needs to refresh the proxy class if List Schema changes
    • Since these are web services interface, can’t accessed from Sandbox Solutions
    • Overhead of three Query conversations from URL based REST Queries to LINQ Queries to CAML Queries
    • Can be used against only SPList, can’t used against SPWeb, SPSite, or SPUser, doesn’t support SharePoint Object Model
    • Can’t query external list data within a site
    • Can’t query more than 1000 items at a time
SOAP Based API – ASMX Web Services
  • Major Features
    • Uses Legacy ASMX  ASP.NET Web Services technology
    • Deprecated, other options should be preferred over this
    • Scoped at the List or Library level data access, requires custom web services for multiple list joins
    • Small subset of APIs compared to SSOM
    • Provides legacy approach for remote data access
    • Developer must parse CAML fragments and access to columns is not strongly typed
    • Used in conjunction with SPServices for jQuery clients, SPServices supports Anonymous access and cross- site collection and cross-domain access
  • Pros
    • Ideal for accessing cross farm data when Enterprise Search API is not an option but CSOM should given preference here for remote cross farm data access in farm level solutions
    • Ideal for Office 365 Cross Site Collection data access in Sandbox Solutions in conjunction with SPServices, none of the other options like CSOM or REST APIs would work in sandbox
    • Supports advanced SharePoint Server capabilities like search, social, or user profile services, which are unavailable through the CSOM or REST APIs
    • Supports access from JavaScript and non-windows clients
  • Cons
    • Requires learning of CAML to query small result set – Hard coded, not strongly typed CAML query, no intelisense
    • Difficult to use in current format, often custom wrapper is required
    • Can be used against only SPList, Doesn’t support SharePoint Foundation Object Model
Custom WCF Services
  • Major features
    • Create your own web service interface for SharePoint
    • Extend out of box SharePoint functionality, requires to expose SharePoint functionality that is unavailable through the existing APIs
    • Can be hosted in SharePoint, IIS, or any other .NET client
  • Pros
    • Ideal for third party vendors and ISVs
    • Ideal for organizations to integrate enterprise systems with SharePoint as service oriented architecture
  • Cons
    • Requires knowledge of complex WCF Services development
Enterprise Search API
  • Major Features
    • Query against Search Index – KeywordQuery and FullTextQuery API
    • This is Enterprise Search capability, not FAST Search
    • Perfect for Cross-farm, Cross-Web Application, or Cross-Site Collection Data Access
    • Use Search API to query large amount of data
  • Pros
    • Cross boundaries, including: farm, web application, site collections, sub sites, libraries, etc.
    • Ideal for Cross-Site Collection Navigation Menu
    • Can query across large data corpuses
    • Queries are fast even with huge data corpuses
    • Greater scalability, All other techniques are mostly SQL-based
  • Cons
    • Requires advanced search service administration and configuration.
    • Content needs to be in the indexed (dependency)
    • Content must be tagged with metadata (to be effective)
    • Crawl properties must be in index and Managed properties must be mapped to crawled properties.
Comparing SharePoint 2010 Server Side Data Technologies
Posted by at No comments:

Wiki Pages vs Web Part Pages vs Publishing Pages for SharePoint 2010 Intranet Content Pages


SharePoint 2010 has three major options to create content pages – publishing pages, web part pages, and wiki pages.

As usual, to make proper architectural decision, I ended up documenting characteristics of each type of pages to allow me make final decision. Here are the high level characteristics of web part pages, wiki pages, and publishing pages.

Publishing Pages
  • Introduced in MOSS 2007 as web content management & publishing infrastructure
  • Publishing pages are designed for creating content pages in more controlled manner with consistent look & feel. These pages are based on page layouts and content types. Typically page layouts are designed by IT & page designers and publishing content pages can be created based on pre-defined page layouts by authors. This process is common for web content management systems.
  • Publishing pages has pre-defined content areas like web part zones & publishing field controls. This allows page designers to define page layouts and full control over how these page content can be rendered or different controls can be branded.
  • Publishing pages content can be versioned and and display history of changes. Publishing pages optionally allows passing articles through proper page approval and page scheduling life cycle.
  • Publishing pages are stored in Pages library. This library is available when publishing infrastructure is enabled on the site. There is only one pages library per site. You can enable multiple page layouts by enabling multiple content types to the pages library.
  • Publishing pages are created by site members or above security groups (contribute permission)
  • Publishing pages are edited by site members or above security groups (contribute permission)
  • You can access publishing infrastructure and create page layouts using Microsoft.SharePoint.Publishing APIs. Please note that you can’t use this namespace in Office 365 sandboxed solution. Alternatively in Office 365 and even on-premises, you can use SharePoint Designer to create page layouts.
Web Part Pages
  • Heavily used in MOSS 2007 and SharePoint 2003 days
  • All content on a web part page is displayed using web parts. Web Part pages are structured web part content including lists, libraries, and other collaborative content including rich media, other web pages, search results, and an aggregation of information. You can’t add text or image easily on web part pages – it requires web parts like content editor or image web parts. This is one of the major disadvantages of web part pages over wiki pages because adding simple graphics, images would require web parts or knowledge of content editor web part.
  • Web part pages provides ideal middle landscape where you still have semi-strict formatting control like publishing pages and partially-controlled collaborative editing capabilities like wiki pages.
  • Web part page has pre-defined content areas like web part zones where web parts can be added and moved as needed
  • Web part page content can be versioned with limited functionality. Please see Maurice Prather’s article – http://www.bluedoglimited.com/SharePointThoughts/Lists/Posts/Post.aspx?ID=305
  • Web part page layout and content configured for all users and optionally personalized for individual users
  • Web Part pages can be stored any document library. Mainly it stored in site assets, site pages, or any other document library you would like to use.
  • Web Part pages can be created by designers or above security groups (design permission)
  • Web Part Page can be edited by members or above security groups (contribute permission)
  • It’s easy to maintain web parts (add, update, remove) in web part pages programmatically using server side object model.
    • Programmatically add web parts to the web part pages by programmatically dropping web parts on web part zones using web part manager
Wiki Pages
  • Introduced in SharePoint 2010
  • Wiki pages consists of rich text editor providing WYSIWYG in-browser editing experience using Web Edit technology. It is designed to add free-form text & rich content including text, tables, links, images, as well as SharePoint lists and web parts anywhere on the page without any needs for web part zones like in web part pages or field controls like in publishing pages. e.g. it doesn’t require web parts like content editor or image web parts to add texts or images.
    • While you can easily add web parts on web part pages (requires advanced skills to use content editor web part for advanced customization), it’s much easier to add text, images, and links including web parts on a on a Wiki page. This would make wiki pages far more flexible to add contents compare to web part pages.
    • Wiki pages are easier to change than Web Part pages by end users with minimal IT dependency. This is major advantage of wiki pages over web part pages. On the flip note, because it’s easy to apply different fonts and styles on wiki pages content, web part pages would allow you better governance and control over standardization of presentation, formatting, and look and feel. It is important to note that advanced power users with SharePoint designer and HTML skills can easily apply different styles and look & feel in web part pages as well. Only way to fully control layout and style of the content in content pages are publishing pages without web part zones. Please note that even publishing pages with web part zones, advanced power users can add different web parts and apply different styles and look & feel.
    • One of the major issues of wiki pages is hidden HTML tags while editing the page in WYSIWYG editor. This might frustate end users who doesn’t have knowledge of HTML and how to remove those hidden tags and spaces. In most cases, you need advanced power user tools like SharePoint Designer to delete those troubled HTML tags like hidden paragraphs and DIV tags. Web part pages with fixed layout of web part zones & web parts would provide little bit better experience than wiki pages while adding content in more strict manner.
    • Another major issue of wiki pages are targeting specific section to brand wiki pages. Because wiki pages uses MS-RTE CSS classes to wrap most of the content tags like DIV, it’s hard to target specific section of wiki pages to brand. Web part pages can easily allow wrapping web part zones by DIV tags to target specific area using CSS.
  • Wiki pages have HTML zones where content can be added directly on the page.
  • Wiki pages can’t be personalized. It is designed to share information in collaborative way where multiple people can add content.
  • Wiki pages can be versioned and display history of changes.
  • Wiki pages are stored in site pages library
  • Wiki pages are created by site members or above security groups (contribute permission)
  • Wiki pages are edited by site members or above security groups (contribute permission)
  • All the content added to wiki pages are added as HTML markup. There is no direct API available to programmatically maintain (add or remove) web parts on the wiki pages.
Overall, if properly architected, in the bigger picture, I still see wiki pages are better option for intranet content pages because of end-user empowerment for content creation & IT non-dependency. In most cases, because of versatility of wiki pages, I personally prefer wiki pages over web part pages for intranet content pages. Some of the greatest benefits of the wiki pages are not only it’s flexibility to add all kind of contents easily but allows more intuitive experience for non-IT business users to create these pages easily without IT’s assistance to build their sites which may contribute into intranet adoption.
Some may argue that ease of use may be one of the biggest concerns of wiki pages over web part pages, which further cause content governance or uneven content look & feel issues especially on major department home pages. More formal editing experience makes web part pages ideal candidate for home pages for department or major business areas where IT would like to balance standardization of page layout and agility to allow business owners to manage content on the home pages.

In our client intranet environment, we ended up using all three types of pages for different scenarios.
  • Publishing Pages – Main Intranet Home Page – Since this page is main landing page for all employees, it required most structured content with fixed page layout making publishing pages ideal choice
  • Web Part Pages – Department or Major business area Home Pages – Since most of department home pages were maintained by department content owners, IT wanted to standardize the look & feel and layout of home pages across intranet. Web part pages were ideal choice for us to allow department content owners to add content in more controlled manner.
  • Wiki Pages – Intranet Content Pages and Team Site Home Pages – Because of it’s WYSIWYG in-page editing capabilities, this is ideal candidate for end-users to create and manage contents on their team sites in more flexible manner where content presentation and standardization of layouts is less important.
Additional Resources
Posted by at No comments:

Easy way to deploy .resx (resource) files under App_GlobalResources folder in SharePoint 2010

Resource files in SharePoint 2010

Resource files are mainly used for localization of the custom solution.
While working with SharePoint 2010, many times the customizations need to be localized and hence, it means that developers have to play around the language specific resx files. Deployment of resx files through the SharePoint solution can be achieved using SharePoint mapped folder named "Resources". However the files those goes under this path can be accessed using SPUtility.GetLocalizedString function. Majority of the times, you may have customizations related to the user interface which are declarative. SharePoint 2010 is based on ASP.NET technology so for, any tags related to resources the resx files will be searched in App_GlobalResources folder located under intepub\wwroot\wss\<<application>> folder hierarchy.
This puts additional overhead of deployment to the developer who want to use the traditional ASP.NET way of localizing UI resources. As, we need to ensure that the resx files should be deployed under both 14 hive and App_GlobalResources folders.
There are multiple ways to deploy the resource files. Following are few of them
  • Write an event handler to copy resx files
  • Custom timer job
  • PowerShell Script as a part of deployment
  • Manual copy and so on....
But what about the solution uninstallations, upgrades and moreover if you have multi server environments, manual deplooyment of resx files is more tedious and erroneous.
SharePoint 2010 Projects supports feature called as "Elements". Using Elements we can deploy number of files at specific locations. Following solution makes use of Elements to deploy resx files to App_GlobalResources folder. Few advantages of this are as below
  • No need to write custom code for deployment
  • Resx files are packaged as a part of WSP
  • No need to worry about upgrades and uninistallations its done automatically in SharePoint way
  • Works perfectly on multi server enviornment
  • No manual steps

 How to do it?

  • Create new Empty SharePoint 2010 Project name it as ResxDeployment
  • Choose a local site for debugging and, choose deployment type Deploy as farm solution
 
  • In Solution Explorer, right click on ResxDeployment project and Add SharePoint Mapped Folder
  • In Add SharePoint Mapped Folder dialog box, choose Resources and click OK
     
  • In Solution Explorer, right click on ResxDeployment project and Add New Item
  • Add few sample resx files to the Resources folder
 
  • In Solution Explorer, right click on ResxDeployment project and Add New Item. Add Empty Element and name it as required for e.g. App_GlobalResources
 
  • In Solution Explorer, click on Show All Files icon to view all files. Open SharePointProjectItem.spdata files located under App_GlobalResources node
 
  • Add the relavent information to the xml file which includes Source, and Type of the file. The type should be set to AppGlobalResource and source should be a relative path of resx file. Following is the example
<?xml version="1.0" encoding="utf-8"?> 
<ProjectItem Type="Microsoft.VisualStudio.SharePoint.GenericElement" DefaultFile="Elements.xml" SupportedTrustLevels="All" SupportedDeploymentScopes="Web, Site, WebApplication, Farm, Package" xmlns="http://schemas.microsoft.com/VisualStudio/2010/SharePointTools/SharePointProjectItemModel"> 
 <Files> 
 <ProjectItemFile Source="Elements.xml" Target="App_GlobalResources\" Type="ElementManifest" /> 
 <ProjectItemFile Source="..\Resources\Contoso.resx" Type="AppGlobalResource"/> 
 <ProjectItemFile Source="..\Resources\Contoso.de-DE.resx" Type="AppGlobalResource"/> 
 <ProjectItemFile Source="..\Resources\Contoso.en-GB.resx" Type="AppGlobalResource"/> 
 <ProjectItemFile Source="..\Resources\Contoso.en-US.resx" Type="AppGlobalResource"/> 
 <ProjectItemFile Source="..\Resources\Contoso.es-ES.resx" Type="AppGlobalResource"/> 
 <ProjectItemFile Source="..\Resources\Contoso.it-IT.resx" Type="AppGlobalResource"/> 
 </Files> 
</ProjectItem>
  • In Solution Explorer, right click on ResxDeployment project and choose Deploy
  • If everything goes well the solution will be deployed on given web application. Also, you can verify that the resx files are deployed under App_GlobalResources and 14\Resources folders

Points to be noted :

  1. Resource files are deployed at two diffrent locations. You can directly add resx files to only elemets folder if needed.
  2. There is no need to copy the files from Resources mapped folder to App_GlobalResources element folder in Visual studio. There is only one copy of resx file hence, no need to worry about multiple location changes
  3. For every additional resx file, SharePointProjectItem.spdata file should be updated otherwise the file will not be copied to App_GlobalResources folder of web application
  4. Please set the Scope of the Feature that includes this module as relavent. It is preferrable to set, Application Level Scoped
In this way, by using OOTB SharePoint features we can deploy resx files to App_GlobalResources folder.
Posted by at No comments:

SharePoint 2010 Solution Deployment/Retraction and Feature Activation/Deactivation Process


SharePoint 2010 Solution Deployment/Retraction and Feature Activation/Deactivation Process:

   
Have you ever wondered what really happens when you deploy/retract SharePoint WSPs and Activate/Deactivate site collection or sub site level features at the farm level? As you execute different PowerShell commands or activate/deactivate features from browser interface, SharePoint 2010 makes several changes at the different places on the servers and databases.
This article provides high level overview of what really happens when you execute different farm level PowerShell commands. Hopefully it will be helpful. 
Central Admin
Site/Web Level Features
GAC
Web.Config
14-Root Features
SharePoint Config DB, Objects Table – Solutions
SharePoint Config DB, Objects Table – Features
Web App Content DB, Features Table
Add-SPSolution
Solution Added but Not Deployed
N/A
N/A
N/A
N/A
Yes – Solution Definition Added
N/A
N/A
Install-SPSolution
Deployed to Web App
Installed Feature
Yes – DLLs Added
Yes – Safe Control Entries Added
Yes – Features Added
Yes – Solution Definition Still Exists
Yes – Feature Definition Added
N/A
Enable-SPFeature
Solution Still Deployed
Activated feature to Site/Web
Yes – Still Exists
Yes – Still Exists
Yes – Still Exists
Yes – Solution Definition Still Exists
Yes – Feature Definition Still Exists
YES – Feature Activation Link Added
Disable-SPFeature
Solution Still Deployed
Deactivated feature from Site/Web
Yes – Still Exists
Yes – Still Exists
Yes – Still Exists
Yes – Solution Definition Still Exists
Yes – Feature Definition Still Exists
NO – Feature Activation Link Deleted
UnInstall-SPFeature
Solution Still Deployed
Uninstalled feature
Yes – Still Exists
Yes – Still Exists
Yes – Still Exists
Yes – Solution Definition Still Exists
No – Feature Definition Deleted
N/A
UnInstall-SPSolution
Retracted from Web App
Uninstalled feature
No – DLLs Deleted
No – Safe Control Entries Deleted
No – Features Deleted
Yes – Solution Definition Still Exists
No – Feature Definition Deleted
N/A
Remove-SPSolution
Solution Deleted
N/A
N/A
N/A
N/A
Yes – Solution Definition Deleted
N/A
N/A

 
Posted by at No comments:
Subscribe to: Posts (Atom)