July, 2010

  • Visual Studio SharePoint Development Blog

    Deploy your BDC model to a specific BCS Service using Visual Studio 2010

    • 0 Comments

    When deploying a BDC model in Visual Studio 2010, some people may see this error message “… There is no default Business Data Connectivity Service Proxy available for the given SPServiceContext…” or similar ones. This probably means the SiteUrl feature property is not appropriately set.

    SiteUrl is a SharePoint feature property that determines where a feature will be deployed. When a BCS feature is deployed, SharePoint server will look up a BCS service (if there are more than one BCS service connected to the site, it will select the default one) connected to the appointed SiteUrl. If the SiteUrl property is omitted, it assumes the value of SiteUrl is http://localhost:80. The SharePoint BDC project in VS2010 helps you customize the feature properties like SiteUrl. Let me show you how you can easily manage SiteUrl property here.

    Assume you have two BCS services, BCS1 and BCS2, and two web applications, one on port 80 (http://localhost:80) named WebApp80, and the other on port 90 (http://localhost:90) named WebApp90. In SharePoint 2010 Central Administration, you can link services up with web applications. Browse to the Web Application Management page, select the web application WebApp80 as shown in the screenshot below.

    clip_image001

    If you click the Service Connections button on the top ribbon, the Configure Service Application Associations dialog will be displayed. Now you can select BCS1 as the default BCS service for the current web application as shown in the screenshot below.

    clip_image002

    It is the same for adding BCS2 to WebApp90. Now BCS1 is the default BCS service for WebApp80 and BCS2 is the default BCS service for WebApp90.

    Now let’s create a new BDC project. SiteUrl by default is not set for a new project. So the solution will be deployed to BCS1. If we want to deploy the solution to the BCS service other than BCS1, how can we do that? Here are the steps.

    1. Select the BDC folder node in the Solution Explorer and view its properties in the Property Window. Click the […] at the end of Feature Properties row in the Property Window. See the screenshot below.

    clip_image003

    2. The Feature Properties dialog will be displayed. Now we can add the SiteUrl property and set its value to http://localhost:90 where BCS2 is the default BCS service.
    clip_image004

    3. Now if we deploy the solution again, it will be deployed to BCS2.

    Enjoy using this feature!

    Jeff Chen

  • Visual Studio SharePoint Development Blog

    Using Deployment Step events to add functionality to Deployment Configuration

    • 0 Comments

    With the help of the extensibility features in the SharePoint tools in Visual Studio, you can add functionality to deployment configurations by subscribing to the DeploymentStepStarted and DeploymentStepCompleted events.

    To learn more about deployment configurations and deployment steps in SharePoint projects, refer to the MSDN article here.

    In this blog post I will show you how to use the DeploymentStepCompleted event and add you own code that is executed when a SharePoint project is either deployed or retracted.

    Our scenario is the following: When retracting Web Parts we would like to delete the .webpart file from the SharePoint server. We will create a project item extension for the Visual Web Part project and from that extension we will subscribe to the DeploymentStepCompleted event. First we will need to create a SharePoint project item extension project.

    To do that we will need to:

    1)       Install the Visual Studio SDK from: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=47305cf4-2bea-43c0-91cd-1b853602dcc5

    2)      Create an empty VSIX project

    3)      Add a class library project which is project item extension project to the solution

    4)      Add the output from the project item extension project as MEF component content to the VSIX manifest in the VSIX project.

    For detailed information on how to create project item extensions you can refer to the walkthrough here or Bing ‘Visual Studio 2010 How to: Create a SharePoint Project Item Extensions.

    Let’s start by creating a project Item extension for Visual Web Part.

       

    [Export(typeof(ISharePointProjectItemTypeExtension))]

    [SharePointProjectItemType("Microsoft.VisualStudio.SharePoint.VisualWebPart")]

     internal class ItemExtension : ISharePointProjectItemTypeExtension

        {

            public void Initialize(ISharePointProjectItemType projectItemType)

            {

                projectItemType.DeploymentStepCompleted += new EventHandler<DeploymentStepCompletedEventArgs>(projectItemType_DeploymentStepCompleted);

            }

     

           

    void projectItemType_DeploymentStepCompleted(object sender, DeploymentStepCompletedEventArgs e)

            {

                ISharePointProjectItem SPProjectItem = e.ProjectItem;

                string webPartUrl = GetWebPartFileUrl(SPProjectItem);

     

                if (e.DeploymentStepInfo.Id == DeploymentStepIds.RetractSolution && !string.IsNullOrEmpty(webPartUrl))

                {

                    SPProjectItem.Project.SharePointConnection.ExecuteCommand<string>(DeleteWebPartFileCommand, webPartUrl);

                }

            }

     

    Notice in above code we created a new class called Item Extension that implements the ISharePointProjectItemTypeExtension interface. In order for this class to be recognized in Visual Studio we added two attributes. With the Export attribute we are telling Visual Studio that this class is a project item extension and with second attribute (SharePointProjectItemType) we are telling Visual Studio that this extension applies to the Visual Web Part projects. Extension developers can subscribe to deployment step events in the Initialize method of the project item extension.

     projectItemType.DeploymentStepCompleted += new EventHandler<DeploymentStepCompletedEventArgs>(projectItemType_DeploymentStepCompleted);

    The event we subscribed to is raised for all the deployment steps that are executed in the active deployment configuration. With the help of the event args parameter passed to the event handler we can check which step is being executed and decide what code to run.

    if (e.DeploymentStepInfo.Id == DeploymentStepIds.RetractSolution && !string.IsNullOrEmpty(webPartUrl))

    Since this includes deleting a file on the SharePoint server, the extension uses a custom SharePoint command to call into the SharePoint server object model. For detailed information on why to use SharePoint commands is discussed here.

     The line of code which uses the SharePoint command is:

    SPProjectItem.Project.SharePointConnection.ExecuteCommand<string>(DeleteWebPartFileCommand, webPartUrl);

     

    When this line of code is executed we create a new process named vssphost4.exe or use an existing one. The SharePoint command named DeleteWebpartFileCommand is executed inside this process during execution.

    To create a SharePoint command class we need to:

    1)      Add a class library project that targets the .NET Framework 3.5 to the same solution as the VSIX and project item extension projects.

    2)      Add references to Microsoft.SharePoint.dll and Microsoft.VisualStudio.SharePoint.Commands.dll.

    3)      Add the commands project output to the VSIX manifest in the VSIX project as a Custom Content Type with Type= “SharePoint.Commands.v4”. This will include the commands project in the VSIX as custom assembly which can be used by the SharePoint project extensions.   

     

    internal class Command

        {

            [SharePointCommand("DeleteWebPartFile")]

            private void DeleteWebPartFile(ISharePointCommandContext context, string webPartFileUrl)

            {

                //Append RootWeb Url

                string fullWebpartFileUrl = SPUrlUtility.CombineUrl(context.Web.Site.RootWeb.Url, webPartFileUrl);

                try

                {

                    SPFile file = context.Web.Site.RootWeb.GetFile(fullWebpartFileUrl);

                    if (file.Exists)

                    {

                        file.Delete();

                        context.Logger.WriteLine(string.Format("Visual Webpart Extension:Deleted file at {0}", fullWebpartFileUrl), LogCategory.Status);

                    }

                }

                catch (Exception ex)

                {

                    context.Logger.WriteLine(string.Format("Visual Webpart Extension:Exception occured when deleting file at: {0}", fullWebpartFileUrl), LogCategory.Status);

                    context.Logger.WriteLine(string.Format("Visual Webpart Extension:Exception occured when deleting file at: {0}; Exception:{1}", fullWebpartFileUrl, ex.Message  +       ex.StackTrace), LogCategory.Verbose);

                }

            }

        }

     

    Notice in the above code we are have an attribute SharePointCommand for the method name which will enable it to be recognized and used by the project item extension to call into. Also the first parameter should be ISharePointCommandContext which will have reference to ‘SPWeb’ to take advantage of Server object model.

     You will also see the logger object is also exposed in the context parameter with which we can log back messages to the output window of Visual Studio from vssphost4.exe.

    You can now install the extension located in the bin/output folder of the VSIX project after the solution is built. Once this extension is installed the DeploymentStepCompleted event will be raised each time a Visual Web Part project is being retracted after the ‘retractSolution’ step.

    To test and debug the extension:

    1)      Download and open the extension project from MSDN code gallery.

    2)      Place a breakpoint in the projectItemType_DeploymentStepCompleted event handler in ItemExtension.cs file and press F5 to start debugging. This will install the VSIX extension in the experimental instance of Visual Studio.

    3)      The experimental instance of Visual Studio will start. Create a Visual Web Part project (select the project template under the SharePoint 2010 node) and use default values in the wizard.

    4)       Once the project is created, press F5.

    5)      Close IE or stop debugging to start executing the retraction steps.

    6)      Once the retraction steps start executing, you will see the breakpoint being hit after “Retract Solution” step.

    7)      You will see the file being deleted after the code is executed.

    Output Window snapshot

    For more information on how to extend the SharePoint project system in Visual Studio you can refer to MSDN topic here or Bing Visual Studio 2010 Extending the SharePoint Project System“.

    Murali Madala.

  • Visual Studio SharePoint Development Blog

    Extending the SharePoint Tools in Visual Studio: An Overview

    • 0 Comments

    Since you’re reading this blog, you’re probably aware that Visual Studio 2010 includes an all-new set of tools for creating SharePoint solutions for Microsoft SharePoint Foundation 2010 and Microsoft SharePoint Server 2010. These tools include a set of project and item templates for developing various types of solutions, integrated Feature and packaging support (with designers), and the SharePoint Connections node in Server Explorer.

    However, you might not know that the SharePoint tools include a comprehensive extensibility model. This extensibility model is public and fully documented. In fact, all of the built-in tools were implemented by using same extensibility model that you can use to create your own extensions. A number of Visual Studio extensions that were built by using this extensibility API are already available, such as VSeWSSImport and vsixforsp.

    The purpose of this post is to provide a high-level overview of the different ways you can extend the SharePoint tools, with some pointers to relevant topics and code examples in the documentation.

    Introduction to the Extensibility Model

    To extend the SharePoint tools in Visual Studio 2010, you use types in three assemblies that are included with Visual Studio:

    • Microsoft.VisualStudio.SharePoint.dll
    • Microsoft.VisualStudio.SharePoint.Commands.dll
    • Microsoft.VisualStudio.SharePoint.Explorer.Extensions.dll.

    For the rest of the post I'll refer to these collectively as the SharePoint tools API. You can think of this API as an abstraction layer on top of the Visual Studio automation object model (DTE and related types) and integration object model (VSPackages and related types). When you create extension for the SharePoint tools, you always work directly with the SharePoint tools API, but you can also call into the automation and integration object models if you need to leverage functionality that is provided only in those object models.

    The SharePoint tools API consists of two main groups of types:

    • Extensibility interfaces that you implement as the basis for an extension of the SharePoint tools. To extend a particular feature of the SharePoint tools, you implement an interface that is defined by the SharePoint tools and apply the Export attribute (and additional attributes as necessary) to your interface implementation. There are a handful of extensibility interfaces provided by the SharePoint tools, including ISharePointProjectItemTypeExtension, ISharePointProjectItemTypeProvider, and ISharePointProjectExtension. The SharePoint tools use the Managed Extensibility Framework (MEF) to expose extensibility interfaces and to manage extensions.

    • Other types that represent components that you can modify or automate in extensions (such as ISharePointProject and ISharePointProjectItem, which represent a SharePoint project and project item, respectively), and other supporting types such as delegates, attributes, and enumerations. Most of the types in the SharePoint tools API fall into this category.

    There are two main feature areas that you can extend: the SharePoint project system and the SharePoint Connections node in Server Explorer.

    SharePoint Project System

    The SharePoint project system refers to the components and functionality that are available in a SharePoint project. At the highest level, this includes the project itself, each SharePoint project item in the project, and other contents of the project such as mapped folders, Feature definitions, and the package definition. A SharePoint project item (or SPI for short) represents a specific SharePoint customization - for example, a Web Part, an event receiver, or list definition. In a SharePoint project that is open in Solution Explorer, each SharePoint project item is represented by a node with an icon that identifies the item type. This node can contain additional files that are associated with the project item, such as Elements.xml files or code files.

    The Microsoft.VisualStudio.SharePoint namespace contains most of the main types in the SharePoint project system, such as ISharePointProject and ISharePointProjectItem. Other project system types are also provided in the Microsoft.VisualStudio.SharePoint.Deployment, Microsoft.VisualStudio.SharePoint.Features, Microsoft.VisualStudio.SharePoint.Packages, and Microsoft.VisualStudio.SharePoint.Validation namespaces.

    You can extend the SharePoint project system in the following ways:

    • Create an extension for a particular type of SPI, such as the built-in List Definition project item. Your extension is loaded only when an instance of the targeted SPI type is in a project that is open in Visual Studio. For more information and related code examples, see Extending SharePoint Project Items in the MSDN documentation.

    • Create your own new type of SPI, which you can associate with an item template or project template. You can even implement your own wizard that appears when a customer adds your SPI to a project, or creates a new project that includes your SPI. For more information and related code examples, see Defining Custom SharePoint Project Item Types in the MSDN documentation.

    • Create an extension for SharePoint projects. Your extension is loaded whenever any type of SharePoint project is open in Visual Studio. For more information and related code examples, see Extending SharePoint Projects in the MSDN documentation.

    • Extend the packaging and deployment behavior of a SharePoint project or SPI. For example, you can create your own deployment steps or deployment configurations, handle various deployment-related events, or create your own validation rules for Features and package definitions. For more information and related code examples, see Extending SharePoint Packaging and Deployment in the MSDN documentation.

    There are a number of tasks you can perform in extensions of the SharePoint project system. For example, you can add custom properties to SharePoint projects or particular types of SPIs (these properties appear in the Properties window when a project or SPI is selected in Solution Explorer), add your own context menu items to SharePoint projects or particular types of SPIs (these menu items appear when you right click the project or SPI in Solution Explorer), and you can handle many different events that are raised by SharePoint projects and SPIs in various scenarios. The MSDN topics I link to above provide how-to topics and walkthroughs that demonstrate all of these tasks.

    SharePoint Connections Node in Server Explorer

    The new SharePoint Connections node in Server Explorer is intended to be used to browse the contents of local SharePoint sites on your development computer. After you add a connection to a local SharePoint site, many (but not all) of the components of the site are displayed here in a hierarchical tree view. This can help provide a quick, comprehensive view of the site while you are working on a new SharePoint solution that you plan to deploy to it. For an overview of how this feature is used, see Browsing SharePoint Connections Using Server Explorer.

    The Microsoft.VisualStudio.SharePoint.Explorer and Microsoft.VisualStudio.SharePoint.Explorer.Extensions namespaces contain the types that you can use to extend the SharePoint Connections node.

    You can extend the SharePoint Connections node in the following ways:

    • Extend a node, such as the node that represents fields, lists, or content types. For a code example and step-by-step instructions, see How to: Extend a SharePoint Node in Server Explorer in the MSDN documentation.

    • Create a new type of node. For example, you might want to do this if you want to create an extension that can display components of SharePoint sites that the built-in SharePoint Connections node does not support, such as Web Parts. For a code example and step-by-step instructions, see How to: Add a Custom SharePoint Node to Server Explorer in the MSDN documentation.

    As with the project system, you can also add custom properties and context menu items to nodes, and there are a number of different events you can handle. The MSDN topics I link to above provide how-to topics and walkthroughs that demonstrate all of these tasks.

    Important Features

    The following features play an important role in most extensions of the SharePoint tools.

    SharePoint Commands

    Most extensions need to call into the SharePoint APIs to perform some work, such as determining whether a particular file exists on a SharePoint site or adding or deleting content from a site. Although the 2010 releases of SharePoint now include a client object model, most SharePoint tools extensions should use the "traditional" server object model, because the client object model was designed to be used to call into remote SharePoint installations, not local installations. However, the SharePoint server object model cannot be called directly from SharePoint tools extensions, because the SharePoint server object model can be called only from 64-bit processes that target the .NET Framework 3.5, but SharePoint tools extensions are run in the Visual Studio process, which is a 32-bit process that targets the .NET Framework 4.

    To bridge this gap, the Visual Studio tools include the concept of a SharePoint command. A SharePoint command is essentially an intermediary method that can call into the SharePoint server object model directly, and that can be called by your extension. For a nuts-and-bolts explanation of how this works, see Calling into the SharePoint Object Models, How to: Create a SharePoint Command, and How to: Execute a SharePoint Command in the MSDN documentation.

    SharePoint Service

    The Visual Studio tools provide a special service object, called the SharePoint service, which provides a number of different features such as the ability to convert some types in the SharePoint tools API to types in the Visual Studio automation and integration object models, execute a SharePoint command, and access any open SharePoint project or project item. For more information, see Using the SharePoint Project Service in the MSDN documentation.

    Related Walkthroughs

    For end-to-end walkthroughs that demonstrate how to implement, deploy, and test different types of SharePoint tools extensions, see the following walkthroughs in the MSDN documentation.

    Project System Extensions

    Extensions of the SharePoint Connections Node in Server Explorer

    McLean Schofield

     

Page 1 of 1 (3 items)