ASP.NET Pipeline November 21, 2010

http://www.codeproject.com/KB/aspnet/aspnetrequestarchitecture.aspx

When you create a new IIS website, IIS registers the site with http.sys, which then receives all HTTP requests for any web application within the site. The http.sys functions as a forwarder, directing the HTTP requests to the User mode process that runs the web application. In this case, the User mode process is the worker process running the application pool which the web application runs under. The http.sys implements a queuing mechanism by creating as many queues as there are application pools in IIS.

Following up with our example, once the request reaches “myserver”, http.sys picks up the request. Let us say that “myapplication” is configured to run under the application pool “myapplicationpool”; in this case, http.sys inspects the request queue of “myapplicationpool” and forwards the request to the worker process under which “myapplicationpool” is running under.

OK, so now, the request is forwarded to the application pool as explained in the previous section. Each application pool is managed by an instance of the worker process “w3wp.exe”. The “w3wp.exe” runs, by default, under the “NetworkService” account. This can be changed as follows: right click on the application pool hosting your application–Properties–Identity tab. Recall that the application pool is run by the worker – the “w3wp.exe”. So now, the worker process takes over.

The worker process “w3wp.exe” looks up the URL of the request in order to load the correct ISAPI extension. The requested resource in the URL is “mypage.aspx”. So, what happens next? A full discussion of ISAPI extensions (and filters) is beyond the scope of this article, but in short, ISAPI extensions are the IIS way to handle requests for different resources. Once ASP.NET is installed, it installs its own ISAPI extension (aspnet_isapi.dll) and adds the mapping into IIS. IIS maps various extensions to its ISAPI extensions. You can see the mappings in IIS as follows: right click on the website-Properties-Home Directory tab-Configuration button-Mappings tab. The figure below shows the mappings:

http://www.devx.com/dotnet/Article/6962

ISAPI extensions and filters.

ISAPI Extensions and Filters
Before ASP.NET, the only way to process custom file extensions was to write an ISAPI (Internet Service Application Programming Interface) extension or an ISAPI filter. However, writing ISAPI extensions and filters is difficult, requires strong C/C++ skills, and is considered “out of reach” for many programmers. ASP.NET improves the situation greatly. ASP.NET’s HttpExtensions and HttpModules provide functionality similar to ISAPI Extensions and ISAPI filters, respectively. Writing HttpHandlers and HttpModules is just a matter of implementing certain interfaces.

HttpExtensions let you process a particular extension (or a set of extensions) using custom code.

Similarly, HttpModules let you filter client requests. For example, you could use an HttpModule if you wanted to manipulate the requested URL by changing the file names before letting the ASP.NET engine handle the request—thus hiding the real file names from the clients. Unlike HttpExtensions, HttpModules execute for every request—irrespective of the file extension. You can create an HttpModule to tweak the request either before or after the appropriate handler processes it.

HttpModules intercept each request to Web application resources. The class that is to act as HttpModule must implement an interface called IHttpModule. Again, the interface is simple:

Page Life-Cycle October 21, 2010

http://www.15seconds.com/issue/020102.htm

Debugging ASP.NET Permissions June 8, 2010

http://www.west-wind.com/weblog/posts/2153.aspx

Sharepoint How To Add ASP.NET Page To _layouts or site December 22, 2009

http://blogs.msdn.com/besidethepoint/archive/2010/05/01/how-sharepoint-integrates-with-the-asp-net-infrastructure.aspx

HTTPModule and HTTPHandler.

http://msdn.microsoft.com/en-us/library/cc297200.aspx

MasterPageFile=”~/_layouts/application.master”

http://asp.net-tutorials.com/basics/events/

http://odetocode.com/Articles/406.aspx

http://weblogs.asp.net/soever/archive/2006/11/09/SharePoint-2007-_2D00_-_2F005F00_layouts-and-how-to-create-pages-that-run-in-site-context.aspx

Create a web application project that can be deployed to the SharePoint /_layouts virtual directory, so my code is executed in the context of a site.

The solution happens to be really easy:

Create a web application project, either directly in the /_layouts folder or somewhere else and copy over all files needed to run your application.

The *.dll and *.pdb files produced as build output must be places in the bin folder of your SharePoint web site. In my test situation this is the folder C:\Inetpub\wwwroot\wss\VirtualDirectories\3a938f6a-15f2-49ae-be78-328ad78974f5\bin. You can find this folder in your Internet Information Server Manager as follows:

•Right-click of the SharePoint web site
•Select properties
•Go to the Home Directory tab
The value in Local Path specifies the path to the virtual directory, and in this virtual directory you find a folder bin.

http://sharenotes.wordpress.com/2008/02/21/add-custom-aspx-pages-or-asp-net-pages-in-sharepoint/

Solutions:

1.The SharePoint designer approach: This approach can be used if there are few aspx pages with little functionality.
2.Using web parts. This can be used in conjunction with SharePoint designer. But once again, developing many web parts is not feasible and also raises performance issues.
3._Layouts folder approach: This is the simplest of all. Just deploy the web application pages under the _layouts folder of SharePoint and the pages can be accessed from any SharePoint site. Cons: The pages don’t inherit the security and access rules from SharePoint. The pages can be accessed from any site existing on that server farm. Master Page integration is not possible. MSDN Article explains with a sample.
4.User controls using Smart Part: In this approach, the developer can develop web parts using the third party Smart Part control. In this way the developer can have the drag – drop functionality as he/she can develop it as a user control and drop it in the smart part. This method is similar to web parts but the developer has the privilege of drag-drop functionality but it still carries the negatives mentioned for the web parts approach.
5.Using features and WSP package: Following some steps as recommended by Andrew Connell (MOSS MVP). Here is the blog. I believe this is the standard approach users are using in the SharePoint developer community.
6.Using VSeWSS (Visual Studio extensions for WSS): This is yet another and latest solution. Microsoft recently released the VSeWSS 1.1 RTM. Using this, we can deploy all the asp .net pages into SharePoint by setting up a new project in Visual Studio. VSeWSS creates a solution package using features. Setup the project and hit ‘Deploy’ and it is done.

http://www.andrewconnell.com/blog/articles

/UsingCodeBehindFilesInSharePointSites.aspx

In native ASP.NET 2.0 sites, adding new pages involves dropping a new ASPX file into the desired folder in the site. In SharePoint, while it is possible to drop files within the webroot of the SharePoint site, it is not recommended. Rather, developers should create a template (just an ASP.NET 2.0 file) and then provision an instance of the file into the SharePoint site that points to the file on the file system. In both environments, the assembly containing the compiled code behind file of the ASP.NET 2.0 page is deployed to either the site’s \BIN directory or the server’s GAC.

There are two main differences in creating custom ASPX pages for use in a SharePoint site vs. an ASP.NET 2.0 site is that the file you create (ASPX) is used as a template for the real file (instance) within the SharePoint site. After creating the ASPX page, an instance needs to be provisioned into the SharePoint site. This is done using a SharePoint Feature.

Next, create the ASPX page that will be added to the SharePoint site and put it in the Feature folder: SharePointCodeBehindPage. With the file created, add whatever is necessary to implement the page the way you want it. The one thing to point out is you should use one of the four SharePoint master page tokens as the value in the MasterPageUrl attribute in the Page directive.

With the ASPX page and code behind created, now the two need to be linked together. Recall how Visual Studio does it… it adds an Inherits attribute to the Page directive in the ASPX automatically. So… we can do it manually! So what do we put in this attribute? The full name to the type, or class, of our page object. This is also known as the 5-part name. The five parts are: [full type name], [assembly name], [version], [culture], [public key token]. Everyone has different ways of getting this. One of the easiest is to build the project and then open the file using Lutz’s Reflector. This gives you the last four parts of the name, also called the assembly full name. Note that the type name needs to also include the namespace. For the code in Figure 3 above, here’s what my Inherits attribute is (note: don’t include the line breaks in the Inherits attribute as shown in the image… they are present just for readability):

http://aspalliance.com/936_Including_Your_Own_ASPNET_Pages_in_Your_SharePoint_Portal.2

If you look at the inheritance hierarchy for WebPartPage, it is inherited from System.Web.UI.Page (the one that is inherited from for ASP.NET pages).

System.Object

System.Web.UI.Control

System.Web.UI.TemplateControl

System.Web.UI.Page

Microsoft.SharePoint.WebPartPages.WebPartPage

ASP.NET Impersonation and Security October 2, 2009

http://www.15seconds.com/issue/040511.htm

Sharepoint security and ASP.NET impersonation.

Impersonation

To make Windows security integration possible, SharePoint utilizes .NET impersonation. .NET Impersonation allows an application to run under the context of the client accessing an application. With ASP.NET impersonation, IIS is responsible for authenticating users against the domain and passing to ASP.NET an authenticated token, which can then act on behalf of the client. ASP.NET impersonation can be defined implicitly through configuration settings, or, as covered later in this article, explicitly through code. A close look at the web.config file for a SharePoint site reveals the implicit impersonation configuration for a SharePoint installation running under Integrated Windows Authentication mode:

<identity impersonate="true" />

This setting instructs ASP.NET to implicitly act on the behalf of the client who is accessing SharePoint.

The Problem

The time will come during a SharePoint customization project where a developer will want .NET code to perform some action that all users of the SharePoint site do not have the permission to perform. For example, accessing and displaying data from lists on other SharePoint sites and virtual servers (through the SharePoint object model), accessing Active Directory, or pushing files to a non-public shared drive. A developer may even need to access data from a SQL Server instance that requires Windows Authentication. Some users will possess the necessary permissions to perform these operations while others won’t, and we certainly do not want to grant these permissions to everyone.

There are several steps involved with performing explicit impersonation, which I have wrapped up into a class called Impersonator (download here). The steps for impersonation are as follows:

1. Authenticate a valid account which possesses the proper permissions to perform the necessary operations
2. Create a new System.Security.Principal.WindowsIdentity instance that represents the account
3. Begin impersonating the new Windows identity
4. Perform actions that require higher permission level
5. Stop impersonating and revert back to the client’s identity

The goal of wrapping these steps into one class is to write the following simple code to begin impersonation, execute code under the context of a different domain user account, and revert back to the original security context of the client:

Impersonator i = new Impersonator("SharePointRead", "MARINER", "password123").Impersonate();

http://www.15seconds.com/Issue/020312.htm

With ASP.NET impersonation, the thread servicing the client request can optionally execute with the identity of the client. Let me explain it in detail.

IIS always maps a user request to some Windows account; in case of anonymous access, this is IUSR_machinename account or any other account that has been defined to be used with anonymous access; in the case of Windows authentication, this is the account whose credentials are provided by the Web site user. After successful authentication, IIS forwards this logged-in user’s identity to the ASP.NET worker thread. Now the ASP.NET worker thread has the following three options:

• It can run under the identity defined by the <processModel> tag.
• It can run under the client identity passed to it by IIS.
• It can run under the identity of the user whose credentials have been listed for impersonation.

Now the decision depends on the impersonation settings for the ASP.NET application.

• If impersonation is enabled and any specific Windows account has not been listed in the Web.config file for impersonation, then the ASP.NET worker thread runs under the client identity passed to it by IIS.
• If impersonation is not enabled, then the ASP.NET worker thread runs under the identity of the ASP.NET worker process (which has been defined by using the <processModel> tag in the Web.config file)
• If impersonation is enabled and a specific Windows account has been listed in the Web.config file for impersonation, then the ASP.NET worker thread runs under the identity generated using that account.

Impersonation for ASP.NET applications can be set up by using the <identity> tag in the Web.config file. We can specify impersonation in the following three ways: 

• <identity impersonate=”true”/> This means impersonation for the ASP.NET worker thread is enabled.
• <identity impersonate=”true” name=”username” password=”password”/> This means impersonation for the ASP.NET worker thread is enabled, but the worker thread will run under the identity that will be generated by using the credentials specified by username and password attributes.
• <identity impersonate=”false”/> This means impersonation for the ASP.NET worker thread is not enabled.

http://www.west-wind.com/WebLog/posts/2153.aspx

ASP.NET works differently. It runs under the account that the process was started under originally. This means ASPNET or NETWORK SERVICE or if you’re using IIS 6 the account you have specifically configured for your Application Pool. So while ASP.NET provides different Authentication models to let you see who logged on to secure areas of your Web site via Forms or Windows Authentication, the underlying account in this scenario never changes. The Authentication is merely a tool for your application, but it doesn’t change the underlying security context.

This is a good thing and something that wasn’t really easily possible with classic ASP. You can however revert to the Impersonation model that works just like classic ASP by turning Impersonation on in web.config:

 <system.web>

  <location path=”admin”>

    <system.web>

      <identity impersonate=”true” />

      <!– WS: Allow only Authenticated users –>

      <authorization>

        <!– allow users=”*”/ –>

        <deny users=”?” />

      </authorization>

    </system.web>

  </location>

</system.web>

http://social.msdn.microsoft.com/Forums/en/sharepointinfopath/thread/fcc4c9e2-3779-4139-8017-b3bda06b0a90

http://www.portalsolutions.net/Blog/Lists/Posts/Post.aspx?List=1fef67f0%2D70ca%2D4263%2Db683%2Df10c1958687a&ID=39

http://msdn.microsoft.com/en-us/library/ms998351.aspx

Really good article on ASP.NET Impersonation and Delegation.

ASP.NET Connection Strings In Web.Config September 23, 2009

http://www.highoncoding.com/Articles/58_Asp__net_Web_config_Configuration_File.aspx

http://www.highoncoding.com/ArticleDetails.aspx?articleID=39

http://www.davidhayden.com/blog/dave/archive/2005/11/17/2572.aspx

<configuration>

  <appSettings>

     <add key=”ConnectionString”

          value=”server=localhost;uid=sa;pwd=;database=DBPerson” />

  </appSettings>

</configuration>

Debug and Release Builds In ASP.NET September 19, 2009

http://odetocode.com/blogs/scott/archive/2005/11/15/2464.aspx

NOTE:

To get the Configuration Manager drop down to show up on the Build tab: Tools > Options >> Projects and Solutions >> General – checkbox for Show Advanced Build Configurations.

Debug and Release Builds in ASP.NET 2.0

One of the adjustments to make when moving from ASP.NET 1.1 to 2.0 is how to produce debug and release builds.

1.1

In 1.1 we had the Build -> Configuration Manager menu option. This command launched a dialog box to let you choose from the available build configurations. Visual Studio provided Debug and Release configurations by default. The configuration selected in the Configuration Manager would tell Visual Studio how to compile the code-behind files. A successful compilation would produce a single assembly (.dll) in the bin directory, with a debugging symbol file (.pdb) appearing if the configuration asked for debugging symbols

Sometime later, the application would receive a web request and begin to execute. At this point, the ASP.NET runtime would generate code for the web forms and user controls in the application, then compile the generated code. The compilation at runtime would use the debug setting in the compilation section of web.config to determine if it should compile optimized code, or debug code (with symbols). ASP.NET would place the results underneath the Temporary ASP.NET Files directory. It is important to select the Release configuration in VS.NET 2003 and set debug=”false” in web.config to produce a true production build in 1.1.

2.0

Here is the most important concept to come to terms with in 2.0: Visual Studio 2005 knows nothing about compiling a web application. In 1.1 VS built the code-behind and ASP.NET built the web forms. In 2.0 Visual Studio 2005 delegates all compilation responsibilities to the ASP.NET platform.

With that in mind, there are two scenarios to talk about: building a web application without a Web Site Deployment project, and building a web application with the Web Site Deployment project. Let’s start with “without”.

When you ask Visual Studio to build a web project, nothing seems to happen. You don’t get the comforting feeling of having a bin directory with a .dll file inside. This is because ASP.NET, not Visual Studio, performs the build. ASP.NET builds everything, including .cs and .vb code files. ASP.NET places all the resulting assemblies in a folder underneath the Temporary ASP.NET files directory. You’ll see the results of the build if you poke around in the directory.

Because ASP.NET does all of the compilation, the debug setting in the compilation section of web.config controls debug or release mode. Compile with debug=”true” and you’ll find the .pdb debugging symbol files alongside each assembly.

This new compilation model makes the Configuration Manager for a web site obsolete. The only option appearing in a Visual Studio 2005 web site “project” is a Debug configuration. Don’t fret – it means nothing. The web.config file now rules the school.

When you are ready to deploy, you can publish the web site. The Publish command (Build -> Publish) will precompile a web application and place the results into a directory of your choosing. You can also publish to an IIS or FTP location. When you select the Publish command you’ll see a dialog box to choose a destination, and options for strong naming, fixed naming, etc. These options map directly to switches for the command line aspnet_compiler tool (see my article for more details). The aspnet_compiler tool also provides a switch to produce debugging symbols, but this option is not available from the Publish dialog. Publish will always precompile a release build without debugging symbols.

Note: the Publish command does not change the debug setting in web.config. The Publish command always compiles for “release”, however, if you precompile to an updateable web site, and then update the web site in place (which results in dynamic compilations), those dynamic compilations will produce debug code and pdb files.

The new Web Site Deployment (WSD) project changes the above scenario slightly. The WSD adds Release and Debug configurations to the Visual Studio 2005 configuration manger. This does not mean that Visual Studio knows how to compile a web site. Instead, Visual Studio knows how to use the MSBuild file provided by WSD to ask for Debug and Release builds. You can now select Debug or Release from the Configuration Manager in Visual Studio. The build request ultimately arrives at the same aspnet_compiler tool described above, and used by the Publish command.

Unlike the Publish command, a WSD Release build will change the debug setting of web.config to false. The WSD also defaults to placing release builds in a Release directory and debug builds in a Debug directory, which is familiar to anyone using .NET outside of web forms. WSD is an awesome tool and I’m sure will be covered in more detail here (eventually).

In conclusion, you control debug and release builds using the debug attribute of the compilation section in web.config – unless you are precompiling the website with the Publish command or the Web Site Deployment tool. The WSD will let you select Debug or Release builds, precompiles the site, and modifies web.config appropriately.

Namespace Structure

http://www.15seconds.com/Issue/030602.htm

Open Visual Studio .NET and select File > New > Blank Solution. In the Location box, make sure you are pointing to the “Visual Studio Projects” folder (or whatever your folder for projects is located). In the Name box, type “FunCo.AutoEmailer”. Notice how the solution location hint is creating a folder called “FunCo.AutoEmailer”. This will need to be changed. Click OK and close the IDE.

Open Windows Explorer and browse to the “Visual Studio Projects” folder. Rename the FunCo.AutoEmailer folder to “FunCo”. Browse into your new FunCo folder and create a folder called “AutoEmailer”. Select the FunCo.AutoEmailer.sln and the FunCo.AutoEmailer.suo files and drag them into the AutoEmailer folder.

Browse into the AutoEmailer and double click the FunCo.AutoEmailer.sln file to open the solution in the IDE. Click File > Add Project > New Project. Select the “Visual C# Projects” > Class Library project type. Name the project “DataAccessTier”. Click OK.

If the Solution Explorer window is not showing, close the IDE and reopen the solution. Right-click on the DataTier project and select Rename. Rename the project “FunCo.AutoEmailer.DataAccessTier”. Right-click on the project again and click Properties. Change the Assembly Name and Default Namespace values to “FunCo.AutoEmailer.DataAccessTier”. Click OK.

Right-click on the solution in the Solution Manager and select

Add > New Project. Select a Class Library project type and name the project “BusinessTier”. Click OK.

 Rename the project “FunCo.AutoEmailer.BusinessTier” and change the Assembly Name and Default Namespace to “FunCo.AutoEmailer.BusinessTier”. Click OK.

Add a new “Windows Server” type project to the solution in the same manner. Name the project “AutoSendService” and make the necessary changes to “FunCo.AutoEmailer.AutoSendService”.

Right-click on the solution and add a new “ASP.NET Web Application” type project to the solution. Change the location box value to “http://<localwebserver>/FunCo/AutoEmailer/PresentationTier&#8221; where “localwebserver” is your local server (most likely “localhost”). Click OK. Rename the project to “FunCo.AutoEmailer.PresentationTier” and change the Assembly Name and Default Namespace to “FunCo.AutoEmailer.PresentationTier”.

Walkthrough Creating A Custom Web Service September 18, 2009

http://msdn.microsoft.com/en-us/library/ms464040.aspx

 Generating and Modifying Static Discovery and WSDL Files

---

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/MySite/MySubsite becomes 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

1. In Windows Explorer, copy the .asmx file of your Web service to \\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS.
2. 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:disco http://MyServer/_layouts/MyCustomWebService.asmx
3. 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=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
   <%@ Import Namespace="Microsoft.SharePoint.Utilities" %>
   <%@ Import Namespace="Microsoft.SharePoint" %>
   <% Response.ContentType = "text/xml"; %>

    

4. 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 the Microsoft.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="http://schemas.xmlsoap.org/disco/scl/" />
   <soap address=<% SPHttpUtility.AddQuote(SPHttpUtility.HtmlEncode(SPWeb.OriginalBaseUrl(Request)),Response.Output); %>
   xmlns:q1="http://tempuri.org/" binding="q1:HelloWorld" xmlns="http://schemas.xmlsoap.org/disco/soap/" />
   <soap address=<% SPHttpUtility.AddQuote(SPHttpUtility.HtmlEncode(SPWeb.OriginalBaseUrl(Request)),Response.Output); %>
   xmlns:q2="http://tempuri.org/" binding="q2:ServiceSoap12" xmlns="http://schemas.xmlsoap.org/disco/soap/" />

    

5. 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); %> />

    

6. Rename both files in the respective formats MyCustomWebServicedisco.aspx and MyCustomWebServicewsdl.aspx so that your service is discoverable through Windows SharePoint Services.

http://it.toolbox.com/blogs/sharepoint-blog/creating-a-custom-web-service-for-sharepoint-13553

I am not saying that you can not copy the assembly to the _vti_bin folder or wwwroot folder, of course you can but I have often seen people struggling with the service deployment. People often ask me where they should copy the assembly and what is the best place to put the assembly in. I tested my web service by putting the assembly file in all the recommended places and I found that bin folder of the virtual directory of the web application is the safest place where your web service is guaranteed to work.

Copy the assembly to the bin folder of the virtual directory of the web application of your choice. You will have to create the bin folder yourself. It is not there by default.

Adding web service to the GAC

30. You must add your assembly in the GAC on your SharePoint server. This is necessary otherwise you will get permissions error on the server. There are three ways to avoid this permissions error. One way is to add the assembly in the GAC. Second way is to change the trust level to medium in the web.config file and the third is to create a custom trust policy of your own. There is an article on Microsoft site that has all the details of Code Access Security (CAS) and it also shows how to create a custom policy file. Here is the article if you are interested in exploring this topic.

Unfortunately, this is an old version and works only with SharePoint 2003. I am not sure if Microsoft has already released an updated version of this article or not. I intend to write an updated version of this article (at least the custom policy file part) for Office SharePoint Server 2007 and Windows SharePoint Services 3.0.

To add your assembly to the Global Assembly Cache (GAC), you can either drag and drop 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 .NET Framework SDK 2.0. This utility is located in the following folder:

http://www.k2distillery.com/2009/02/custom-sharepoint-web-service-upload.html

Sharepoint Web Service And _vti_bin

http://jamestsai.net/Blog/post/Where-do-you-deploy-custom-SharePoint-web-service-files-to-(asmx-discoaspx-and-wsdlaspx).aspx