Deploying Web Parts in Windows SharePoint Services

Windows SharePoint Services requires that a Web Part be deployed in the Web Part gallery before it can be added to the page. This section describes differences between the bin folder and the Global Assembly Cache (GAC), security permissions considerations, how to strong name an assembly for deployment.

Deployment Considerations :

There are two primary locations within a SharePoint site where you can deploy a Web Part assembly.

1) bin directory — The bin directory is a folder stored in your Web application root directory. The location of this folder is determined when the Web site is created in Internet Information Services (IIS). In Windows SharePoint Services, this can happen either through the SharePoint 3.0 Central Administration site, or by manually creating a new Web site in IIS manager.

Important: If a bin directory does not exist you must add one manually. Do not store Web Parts in the local _app_bin directory, which is reserved for use by Microsoft.
For more information, see How to: Find the Web Application Root

2) global assembly cache — A global location where signed assemblies can be deployed. The global assembly cache enables you to share assemblies across numerous applications. The global assembly cache is automatically installed with the .NET runtime. Components are typically stored in C:\WINNT\Assembly.

Each location has advantages and disadvantages, as described as the following

1) bin directory :

Advantages : Assemblies run with partial trust, by default. Code that runs from this directory has a low level of code access security (CAS) permissions. Because administrators must explicitly raise permissions that have been granted to a Web Part so it can function properly, they often prefer that assemblies run in the bin directory with a known set of required CAS permissions.A bin directory is specific to a Web application. This makes it possible to isolate code to a particular Web application.

Disadvantage : In order for the Web Part to run in multiple Web applications, you must deploy it to the global assembly cache.

2) global assembly cache :

Advantages : Assemblies run with full trust by default. They are globally installed, so they will work in any Web application. The global assembly cache can contain multiple versions of the same assembly.

Disadvantage : Generally no CAS restrictions on code installed to the global assembly cache; therefore, you lose the defense-in-depth security benefit.Also, an assembly deployed to the GAC is cached, so if the assembly is rebuilt, it is not automatically updated on the SharePoint site. You must force Windows SharePoint Services to reload the assembly by resetting Internet Information Services (IIS).

Security Permissions Considerations:

By default, code access security permissions for the bin directory are low; only pure execution is allowed. In most cases you need to elevate these permissions to make your assembly run correctly, for example, if your Web Part requires access to the SharePoint object model.
There are two ways to elevate permissions:

a) Recommended method — Create a new trust policy file and point your web.config file at the new file. This option is more complicated but it gives you a precise attribution of permissions for your Web Parts.
For more information about trust policy files, see Securing Web Parts in Windows SharePoint Services.

b) Optional method — Raise the net trust level of the bin directory. In the web.config file in the Web application root, there is a tag called with a default attribute of level="WSS_Minimal". You can change this level to WSS_Medium. While this option is simpler, it grants arbitrary new permissions that you might not need and is less secure than creating a new trust policy file.

Strong Naming a Web Part Assembly

Strong naming uses a private key to digitally sign an assembly. Strong naming also stamps the assembly with a public key to validate the signature. This technique guards against unauthorized versions of a Web Part. If the public key fails to validate the digital signature, Windows SharePoint Services will refuse to run the module.

When deploying a Web Part to the bin, the recommend practice is to strong name the assembly. When deploying a Web Part to the Global Assembly Cache, the assembly must have a strong name. An assembly without a strong name is not recommended in Windows SharePoint Services.

For more information: Click Here

Special Thanks to : Pasalkar, Amit