Testing and Debugging | MCAD/MCSD Training Guide (70-310): Developing XML Web Services and Server Components with Visual Basic(R) .NET and the .NET Framework

‚ ‚

Deploying Windows Services, Serviced Components , .NET Remoting Objects, and XML Web Services

Plan the deployment of and deploy a Windows service, a serviced component, a .NET Remoting object, and an XML Web service

Although the .NET Framework supports XCOPY deployment, XCOPY is not sufficient for advanced deployment requirements. For advanced requirements, you should instead use a Microsoft Windows Installer ‚ based installation package to deploy applications.
The Microsoft Windows Installer is the built-in installation and configuration service of the Windows operating system. In addition to providing several advanced installation features, it provides features such as the ability to roll back an installation process, uninstall an application, and repair a component or an application.
Visual Studio .NET provides four types of deployment templates: Setup Project (for Windows-based applications), Web Setup Project (for Web-based applications), Merge Module Project (for shared components and assemblies), and Cab Project (for Managed and legacy ActiveX components to be downloaded over the Internet). Visual Studio .NET also provides the Setup Wizard, which helps in creating installation packages for any of these deployment projects.

Create a setup program that installs a Windows service, a serviced component, a .NET Remoting object, and an XML Web service

When you deploy a Web service by manually copying the files, you need to manually create the virtual directory and set the virtual directory as an IIS application. The Visual Studio .NET Copy Project command does this automatically for you. The Web Setup project provides the maximum configuration options and total control over the installation process.
A Visual Studio .NET Setup Project does not package the .NET Framework files for redistribution. You should ensure that the .NET Framework is already installed on the Web server, or, better yet, you should use a bootstrapper program that installs the .NET Framework prior to installing the Web service.
The Windows Installer Service and the Installer tool (installutil.exe) perform installation in a transactional manner.
If you want a custom installer class to execute when an assembly is installed using a Web Setup project or by using the Installer Tool, you need to apply the RunInstallerAttribute to the class and set its value to true.
You use the Setup Project template to create a setup program for a Windows Service.
How you deploy a .NET remoting object depends mostly on the application that uses it. Remoting configuration is all stored in XML configuration files; therefore, no extra registration steps are required.
When you have a component that will be shared among multiple applications, you should package it as a merge module ( .msm file). Merge modules cannot be directly installed. They need to be merged with the installation program of an application that uses the shared component, packaged into a merge module.

Register components and assemblies

Installation components allow you to take custom actions during the setup of an application. The .NET Framework provides a few predefined Installer components for use with server components. You can also create custom installation components by deriving from the Installer class.
To deploy a serviced component, you must register the component with the COM+ catalog and should install the component in the GAC.
If you want other developers to be able to locate and use your Web service, consider publishing your Web service to a UDDI registry.

Publish an XML Web service

Enable static discovery

Disco is Microsoft's standard format for discovery documents, which contain information on Web services.
The Web Services Discovery Tool, disco.exe , can retrieve discovery information from a server that exposes a Web service.

Publish XML Web service definitions in the UDDI

UDDI, the Universal Description, Discovery, and Integration protocol, is a multi-vendor standard for discovering online resources including Web services.
You can publish your Web Service in the UDDI by filling out the submission forms at an online UDDI site.

Configure client computers and servers to use a Windows service, a serviced component, a .NET Remoting object, and an XML Web service

Shared assemblies are used by multiple applications on a machine. Shared assemblies are placed in the GAC, and they enjoy special privileges such as file security, shared location, and side-by-side versioning.
You generate a public/private key pair by using the Strong Name tool ( sn.exe ). This pair can be used to sign assemblies with a strong name.
You can add a shared assembly to the GAC by using Windows Explorer, the Microsoft .NET Framework Configuration tool, the Global Assembly Cache tool, or the Windows Installer.
The best way to add an assembly in the GAC during deployment is to use Microsoft Windows Installer. The Windows Installer provides assembly reference-counting features and manages removal of assemblies at the time of uninstallation.
When viewed in Windows Explorer, the assembly cache folder in the System folder displays assemblies from the GAC and native image cache.
The CLR first searches the GAC to locate assemblies, and then it looks into the files and folders where the assembly is installed. Thus, loading shared assemblies from the GAC is efficient because the CLR does not engage itself in looking into the < codebase > and <probing> elements of the applicable configuration files.
Delay signing allows you to place a shared assembly in the GAC by signing the assembly with just the public key. This allows the assembly to be signed with the private key at a later stage ‚ when the development process is complete and the component or assembly is ready to be deployed. This process allows developers to work with shared assemblies as if they were strongly named, and it secures the private key of the signature from being accessed at different stages of development.

Implement versioning

The set of rules that CLR uses to locate an assembly is called binding policy. Binding policy is a deciding factor in how and where the assemblies of an application should be deployed.
A private assembly is identified using its simple text name and is deployed for use by a single application.
Binding policy for private assemblies is modified using the application configuration file. This is done by specifying additional search locations for the assembly in the <probing> XML element.

Plan, configure, and deploy side-by-side deployments and applications

Different versions of an assembly can be deployed in the GAC for side-by-side execution. You can implement side-by-side execution of an assembly by configuring the binding policy in the application configuration, publisher policy file, or the machine configuration file.
The publisher policy file can be used to deploy service pack ‚ like bug-fix updates for the assemblies. The publisher policy file is an XML file that is converted into a strong named assembly and installed in the GAC.

Configure security for a Windows service, a serviced component, a .NET Remoting object, and an XML Web service

Permissions control access to resources.
Code can request the minimum permissions that it needs to run and optional permissions that it would like to have. It can also refuse permissions and demand permissions on the part of calling code.
Code access permissions represent access to resources, whereas identity permissions represent things that the .NET Framework knows about code.
The .NET Framework supplies both attribute-based declarative security and class-based imperative security.
Code groups are sets of assemblies that share a security context.
Permission sets are sets of permissions that can be granted as a unit.
The Common Language Runtime computes actual permissions at runtime based on code group membership and the calling chain of the code.
Custom permissions allow you to create your own permissions to protect particular resources.
The most important security decision you must make with a Windows service is which security account should be used to run the service. You can choose between the LocalSystem account or a user account on Windows 2000. On Windows XP, the LocalService and NetworkService accounts provide additional flexibility.
Because Web services are hosted by ASP.NET, they have the entire spectrum of IIS authentication, authorization, and security features available to them.
You can use IIS to control access to a Web service, and then use declarative or imperative security to control the access of the Web service to resources.
WS-Security is a new specification for a set of SOAP headers to handle authentication, encryption, and signing directly in SOAP messages.
Remoting servers that require secure hosting are best run in the ASP.NET process. Remoting servers that require additional speed but less security can be run in a Windows service host instead.
You can configure security for serviced components by applying attributes within the code for the components and then specifying COM+ roles with the Component Services tool.

Configure authentication type. Authentication types include Windows authentication, Microsoft .NET Passport, custom authentication, and none

The .NET Framework supports both authentication and authorization. Authentication refers to verifying a user's identity. Authorization refers to granting rights based on that identity.
Users must satisfy any IIS authentication requirements before ASP.NET authentication takes over.
ASP.NET authentication uses interchangeable authentication providers. You can choose Windows authentication, Passport authentication, or forms-based authentication.

Configure and control authorization. Authorization methods include file-based authorization and URL-based authorization

After you have authenticated a user, you can use authorization to control the user's access to resources.
File-based authorization uses operating system security to allow or deny resources to files such as .aspx and .asmx files.
URL-based authorization uses the <authorization> section in the web.config file to control access to an application.

Configure and implement identity management

Identity impersonation enables the ASP.NET process to act as the authenticated user.
The WindowsPrincipal and WindowsIdentity classes let you check the authentication status of the current user.
You can use the IsInRole method of the WindowsPrincipal object to check for membership in Windows groups.
The PrincipalPermission class allows you to perform declarative or imperative role-based security operations.

‚ ‚

Top