What may not be apparent in the projects that we’ve created so far is that when we’re deploying a solution to SharePoint, the artifacts in our Visual Studio project are collated into a package file that is then copied to the server. The SharePoint deployment process then uses the contents of the package to install our customization. We can see this process in action by monitoring the output window in Visual Studio.
So far we’ve been working on a single server development machine, but what happens if a farm includes several servers? How can we deploy our customization to all servers? The answer is, of course, to use a package that can be stored centrally and automatically rolled out to all servers in the farm as part of the installation process. As new servers are added to the farm, centrally stored packages are automatically deployed as required. Furthermore, farm administrators have the ability to deploy and retract packages from the Central Administration console.
SharePoint packages are created as cabinet (CAB) files with a .wsp extension. We can, however, rename a .wsp file, such as myproject.wsp, to myproject.cab and view the contents in Windows Explorer.
Each package file contains many different elements, mostly consisting of XML files and resources such as dynamic link libraries (DLLs), script files, or images. One thing that package files have in common, however, is a manifest.xml file. This file is basically the setup guide for the package and contains a list of the deployable items within the package.
Each solution consists of one or more deployable item. A number of different types of deployable items exist, such as an assembly, a resource file, or a site definition file. However, for the most part, deployable items are defined using feature manifests.
Let’s see how these ideas jibe with our understanding of the Visual Studio project structure.
Let’s take a look at what’s happened in Visual Studio. We have a Features folder and a Package folder. If we double-click Package.package within the Package folder, we’ll see the package designer shown here:
The package designer gives us a visual tool we can use to modify the manifest.xml for a package file. Click the Manifest button at the bottom of the page to see the underlying manifest.xml file:
In this manifest are two deployable items: an assembly that will be the build output of our Visual Studio project and a FeatureManifest that points to a Feature.xml file.
By default, the build output assembly will always be added to the solution file. This means that any code that we add within our project will be compiled and the resultant DLL will be deployed to SharePoint in the solution package. In some situations, however, we may need to add another assembly. By clicking the Advanced button in the Solution Designer, we can either add an assembly or add the compiled output of another project within the solution. Along with adding additional assemblies, we can also add any resource assemblies that should be included.
Adding Safe Controls
When adding assemblies to a solution, we can also add a safe control entry. Safe control entries were mentioned in preceding chapters, but I’ll clarify exactly what they are and why you might need them here.
SharePoint makes use of a custom page parser to assemble the user interface, and this parser is known as the Safe-Mode Parser. Its primary function is to prevent users from executing code on the server that hasn’t been specifically approved by an administrator. The mechanism by which an administrator approves code for execution is the SafeControl entry, which is ultimately applied as a web.config entry on each front-end server. If our assembly contains user controls or web parts or any other component that can be declaratively added to a page, a SafeControl entry is required. If a user attempts to add a component that does not have a corresponding SafeControl entry, an error will be thrown detailing the absence of the SafeControl entry as the problem.
Share Point 2010 Related Interview Questions
|Web Services Interview Questions||XML Interview Questions|
|Share Point 2010 Interview Questions||ASP.NET Interview Questions|
|Share Point Administration Interview Questions||BizTalk Admin Interview Questions|
|Microsoft Office SharePoint Server (MOSS) Interview Questions||Biztalk Server Interview Questions|
|Asp Dot Net Mvc 4 Interview Questions||Biztalk Esb Toolkit Interview Questions|
|InfoPath Interview Questions|
Share Point 2010 Tutorial
The Microsoft Sharepoint 2010 Platform
Developing With Sharepoint 2010
Presentation Layer Overview
Client Object Model
Infopath Forms Services
Enterprise Content Management
User Interface Customization
Application Services Overview
Service Application Framework
Word Automation Services
Data Access Overview
Linq To Sharepoint And Spmetal
Business Connectivity Services
User Profiles And Social Data
Packaging And Deployment Model
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.