When you are working with folders and lists:
Cause of this error: dll reference for Microsoft.SharePoint.dll is missing. Even after installing WSS extension for Visual Studio 2005 and creating a web part project you can recieve this error if the Microsoft.SharePoint.dll is not found in 12 hive path i.e. C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI.
You can find all the WSS related .dll files at this path C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI, so if you recieve such kind of error probable reason is .dll files are not available in this folder.
Best approach to come up with this problem is either reinstall WSS extension for VS.Net or Try Start > Search and find this file “Microsoft.SharePoint.dll” so that if in case you have installed it other than default location you can able to add reference and can go ahead.
This programming task provides an overview of how to create a custom Web service that operates within the context of Windows SharePoint Services 3.0. It steps through the process of creating a simple “Hello World” Web service and then shows how to modify the service so that it implements the Windows SharePoint Services 3.0 server-side object model to return site and list data.
Basic Steps for Creating a Web Service
- Create an ASP.NET Web service in Microsoft Visual Studio 2005.
- Create a class library within the Web service that defines the programming logic for the Web service.
- Generate and edit a static discovery file and a Web Services Description Language (WSDL) file.
- Deploy the Web service files to the _vti_bin directory.
- Create a client application to consume the Web service.
Creating an ASP.NET Web Service in Visual Studio
The first step is to create an ASP.NET Web service Web site in Visual Studio 2005.
To create an ASP.NET Web service
- In Visual Studio, click File, point to New, and then select Web Site.
- In the Templates box of the New Web Site dialog box, select ASP.NET Web Service, select File System in the Location box, select a programming language and location for the project, and then click OK.
- Within the new Web service solution, create a separate class library project to contain the Web service logic. To create the project, click File, point to New, and then select Project.
- In the New Project dialog box, select a language in the Project types box, select Class Library in the Templates box, provide a name and location for the project, select Add to Solution in the Solution box, and then click OK.
- Add a reference to the System.Web.Services namespace in the class library project. Right-click the project in Solution Explorer, click Add Reference, select System.Web.Services in the Add Reference dialog box, and then click OK.
- Replace the default class file in the class library project with the default service class file that Visual Studio provides in the App_Code folder of the Web service.To replace the class file with the service class file
- In Solution Explorer, drag Service.cs or Service.vb to the top node in the class library project.
- Delete the Class1.cs or Class1.vb file, and also delete the Service.cs or Service.vb file that remains in the App_Code folder.
- Create a strong name for the class library:
- In Solution Explorer, right-click the class library project, and then click Properties.
- In the Properties dialog box, click Signing, select Sign the assembly, and then select <New> in the Choose a strong name key file list.
- In the Create Strong Name Key dialog box, provide a file name for the key, clear the Protect my key file with a password check box, and then click OK.
- To build only the class library project, right-click the project in Solution Explorer, and then click Build.
- To add your assembly to the global assembly cache (GAC), you can either drag the assembly into the
%windows%\assembly directory using 2 instances of Windows Explorer, or use the command line utility gacutil.exe that is installed with the Microsoft .NET Framework SDK 2.0.To use gacutil.exe to copy the class library DLL into the GAC
- To open the Visual Studio command prompt, click Start, point to All Programs, point to Microsoft Visual Studio 2005, point to Visual Studio Tools, and click Visual Studio 2005 Command Prompt.
- At the command prompt type a command in the following form, and press ENTER:
gacutil.exe -if "<Full file system path to DLL>".
- Now you are ready to modify the assembly information in the default Service.asmx file of the Web service with information for the DLL from the GAC. To get information from the GAC, open the
%windows%\assembly directory in Windows Explorer, right-click your assembly, and click Properties.
- To open Service.asmx in Solution Explorer, right-click the file and click Open.
- Remove the CodeBehind attribute from the page directive in Service.asmx, and modify the contents of the Class attribute so that the directive matches the following format, where the assembly name “MyServiceAssembly” and the public key token are values specified in the Properties dialog box that you opened in step 10:
<%@ WebService Language="C#" %>
In Visual Basic include the namespace to identify the class, for example,
Class="MyServiceNamespace.Service, MyServiceAssembly, Version=18.104.22.168, Culture=neutral, PublicKeyToken=8f2dca3c0f2d0131".
- Rename your .asmx file appropriately, and then save your changes.
To provide discovery and description for your custom Web service, you must create a .disco file and a .wsdl file. Because Windows SharePoint Services virtualizes its URLs (for example,
http://MyServer), you cannot use the autogenerated .disco and .wsdl files generated by ASP.NET. Instead, you must create a .disco page and a .wsdl ASPX page that provide the necessary redirection and maintain virtualization.
You can use ASP.NET to generate the .disco and .wsdl files by temporarily hosting your Web service in a virtual directory, such as
/_layouts, and then using the .NET Framework Web Service Discovery tool (Disco.exe) to obtain the generated files.
To generate the static discovery and WSDL files
- In Windows Explorer, copy the .asmx file of your Web service to
\\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS.
- Run Disco.exe at the command prompt from the LAYOUTS directory to generate .disco and .wsdl files. Run a command in the following format to generate the files in \LAYOUTS:
- To register namespaces of the Windows SharePoint Services object model, open both the .disco and .wsdl files and replace the opening XML processing instruction —
<!--?xml version="1.0" encoding="utf-8"?> — with instructions such as the following:
<%@ Page Language="C#" Inherits="System.Web.UI.Page" %>
<%@ Assembly Name="Microsoft.SharePoint, Version=22.214.171.124, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Import Namespace="Microsoft.SharePoint.Utilities" %>
<%@ Import Namespace="Microsoft.SharePoint" %>
<% Response.ContentType = "text/xml"; %>
- In the .disco file, modify the contract reference and SOAP address tags to be like the following example, which replaces literal paths with code generated paths through use of theMicrosoft.SharePoint.Utilities.SPHttpUtility class, and which replaces the method name that is specified in the binding attribute:
<contractRef ref=<% SPHttpUtility.AddQuote(SPHttpUtility.HtmlEncode(SPWeb.OriginalBaseUrl(Request) + "?wsdl"),Response.Output); %>
docRef=<% SPHttpUtility.AddQuote(SPHttpUtility.HtmlEncode(SPWeb.OriginalBaseUrl(Request)),Response.Output); %>
xmlns:q1="http://tempuri.org/" binding="q1:HelloWorld" xmlns="http://schemas.xmlsoap.org/disco/soap/" />
xmlns:q2="http://tempuri.org/" binding="q2:ServiceSoap12" xmlns="http://schemas.xmlsoap.org/disco/soap/" />
- In the .wsdl file, make the following similar substitution for the SOAP address that is specified:
<soap:address location=<% SPHttpUtility.AddQuote(SPHttpUtility.HtmlEncode(SPWeb.OriginalBaseUrl(Request)),Response.Output); %> />
- Rename both files in the respective formats MyCustomWebServicedisco.aspx and MyCustomWebServicewsdl.aspx so that your service is discoverable through Windows SharePoint Services.
Copying the Web Service Files to the _vti_bin Directory
The _vti_bin virtual directory maps physically to the Local_Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI directory, which contains the default Web service files used in Windows SharePoint Services. Copy the new MyCustomWebServicewsdl.aspx and MyCustomWebServicedisco.aspx files, and also the MyCustomWebService.asmx file, to the ISAPI folder.
From the _vti_bin directory, a Web service offers its functionality to the site that is specified when adding a Web reference for the service.
To verify that your custom Web service is discoverable, navigate to
List the New Web Service in spdisco.aspx
To make your Web service discoverable in Visual Studio as a Web service alongside the default Windows SharePoint Services Web services, open the spdisco.aspx file located in \Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI and add the following code, specifying the .asmx file for your Web service.
<contractRef ref=<% SPHttpUtility.AddQuote(SPHttpUtility.HtmlEncode(spWeb.Url + "/_vti_bin/MyCustomWebService.asmx?wsdl"), Response.Output); %>
docRef=<% SPHttpUtility.AddQuote(SPHttpUtility.HtmlEncode(spWeb.Url + "/_vti_bin/MyCustomWebService.asmx"), Response.Output); %>
xmlns=" http://schemas.xmlsoap.org/disco/scl/ " />
Creating a Windows Application to Consume the Web Service
After you copy the Web services files to the _vti_bin directory, the next step is to create a Windows Application to consume the Web service.
To create a Windows Application that consumes the Web service
- Open Visual Studio 2005, and on the File menu, point to New, and then click Project.
- In the New Project dialog box, select Visual C# or Visual Basic, and then select the Windows Application template.
- Type a name for the application in the Name box, specify a location for the project files in the Location box, and then click OK.
- In Solution Explorer, right-click the project, and then click Add Web Reference.
- In the address bar of the Add Web Reference browser, type the URL for the site to apply the service to, as follows, and then press ENTER:
- Click Add Reference to download the service contract for the Web service.
- Open Form1 in Design view, display the Toolbox, and then drag a button onto the form.
Add the following code that calls your custom method.
Web_Reference_Folder.MyServiceClass MyCustomService = new Web_Reference_Folder.MyServiceClass();
MyCustomService.UseDefaultCredentials = true;
You can customize how you track your team project and how you design your workflow, work item forms, and data fields by customizing one or more work item tracking objects. You can customize the following work item tracking objects:
- Work item type defines the rules, fields, states, and transitions for a work item that will be tracked on a team project, such as bugs, requirements, and risks. This object also specifies the fields you can use to track data and display the form for the work item type. There are three main components that define a work item type:
- Work item fields define the types of data that are associated with a work item type. Each field is defined by a number of attributes, including its data type, use in reporting, and whether or not it is indexed. You can also specify optional elements that restrict, auto-populate, or place conditions on the values that can be entered in the field through the work item form.
- Workflow defines how a work item is tracked by defining the states, transitions, and reasons by which a work item progresses from an open or active state to a closed or completed state.
- Work item form defines the layout and contents that appear on the form that team members interact with to track work item data.
- Link type defines the rules and restrictions that control the relationships that can be made between work items.
- Global list defines a list of values, a pick list, that you can use across work item types to select a value for a work item field.
- Category defines a group of work item types that track similar items of work but are referred to by different names. Categories are useful for running queries, generating reports, and setting default work item types in specific instances.
Your team members can use work items to track work to be completed on a project. They can create a work item based on a default work item type such as a bug, requirement, risk, or task. The exact set of default work item types available depends on the installed methodology, such as Microsoft Solutions Framework (MSF) for Agile Software Development and MSF for CMMI Process Improvement. A work item type is a template from which work items of that type are created.
You can add customized work item types to the default set to make Team Foundation help with the processes your team uses and the ways that you communicate. For example, you might want to create work item types for a project-specific bug, a change request, a quality of service requirement, a risk to manage, and a scenario-based task.
After you create a work item, it contains the fields and behavior that were defined in the work item type from which you created it.
Each work item type is a set of XML definitions that you can author or modify to customize the work item type to meet your needs.
In addition to creating work item types, you can also modify existing work item types. For example, to better support the processes used by your team, you can add fields to a work item type or change the workflow behavior of a work item type.
You can create and modify objects to track work items by using Process Editor, a power tool for Visual Studio. This tool is not supported. For more information, see the following page on the Microsoft Web site: Team Foundation Server Power Tools April 2010.
- Add, remove, or customize how you use a work item field to track data. You can customize an existing work item type or create a work item type to meet your project tracking requirements. Each work item type corresponds to an XML definition file that is imported to a team project.
- Understand how to name fields and other work item tracking objects. You can specify a friendly name for all work item tracking objects, and for some you must also specify a reference name. Both types of names must meet the requirements defined based on the object type.
- Create and customize a type of work item. You can create a type of work item from an existing type, and then add a field, add rules to the field, define the allowed values for the field, add states and transitions for the type, and change the form layout for the type.
- Identify how you use existing fields to track information and progress. You can define and customize types of work items more easily if you use existing fields to store common kinds of data.
- Add, remove, or customize how you use a work item field to track data. You use work item fields to track data for a work item type and to define the filter criteria for queries as well as to generate reports. Any data element that you want to track, use to define the workflow, or appear on the form for a work item type must be defined in the work item type definition file by using the FIELD element.
- Add, remove, or modify the states or transitions that control workflow. You control the workflow by defining its initial state, its valid states, the valid transitions between those states, and the users or groups that have permission to perform those transitions. The WORKFLOW section of the work item type controls how a work item is tracked.
- Modify and customize the work item form for a work item type. You can control the way a work item type displays user-interface elements through the FORM section of the work item type definition. Each work item type must have one and only one form. You describe the whole form, which includes all its tabs, fields, and groups.
- Share pick lists across work item types. To quickly update the contents of pick lists that are used for many work item types, you define global lists.
- Create and customize link types. You can customize an existing link type or create a link type to meet your project tracking requirements. Link types are used to create relationships between work items.
- Create and manage categories of work item types. You can group one or more work item types in the same project into a category. Categories are useful when your team projects contain similar work item types that are named differently. Define categories to support queries, reporting, and team collaboration.
- Look up the schema definition for an element of a work item type. You can view the syntax used for each schema element that is associated with types of work items.
- Work Item Type Schema Reference
- Determine the work item customization option that supports your tracking requirements. You can customize work item types for your teams and projects and what determines the scope of your changes.
- Determining the Scope of Your Customization Requirements
- Identify what can be localized in a work item type definition. You can localize some parts of the work item type definition so that they appear in the user’s native language.
- Work Item Type Definition Localization and Globalization
- Understand what types of links support your project requirements. Before you start to create links between work items, you should analyze how you might use links to plan your project and track the status of work items.
- Choosing Link Types to Effectively Track Your Project
- Import, export, and manage work item tracking objects. With the witadmin command-line utility, you can create, delete, import, and export categories, global lists, types of links, types of work items, and work item fields. Management of these objects is performed for a project collection or a specific team project.