Chapter 8: Developing Phase: Additional Features in .NET

This chapter describes some of the additional features of the Microsoft® .NET Framework that you can use in migrating applications from UNIX. These features include:

  • Securing applications in .NET.

  • Isolated storage.

  • Serialization.

  • .NET Remoting.

  • XML Web services in .NET.

  • Enterprise Services in .NET.

  • Enterprise Templates.

On This Page

Securing Applications in .NET Securing Applications in .NET
Isolated Storage Isolated Storage
Serialization Serialization
.NET Remoting .NET Remoting
XML Web Services in .NET XML Web Services in .NET
Enterprise Services in .NET Enterprise Services in .NET
Enterprise Templates Enterprise Templates

Securing Applications in .NET

The .NET Framework and the common language runtime (CLR) provide new features that facilitate development of more secure applications. They provide many useful classes and services that enable developers to easily write more secure code. These classes and services also enable system administrators to customize code access to protected resources. In addition, the runtime and the .NET Framework provide useful classes and services that facilitate the use of cryptography and role-based security. The major security mechanisms available in the .NET Framework are described in the following sections.

Code Access Security

Code access security allows code to be trusted to varying degrees, depending on where the code originates and on other aspects of the code's identity. All managed code that targets the common language runtime receives the benefits of code access security. The following code access security concepts should always be considered in .NET:

  • Writing type-safe code

  • Imperative and declarative syntax

  • Requesting permissions for your code

  • Using secure class libraries

Role-based Security

Business applications often provide access to data or resources based on credentials supplied by the user. Typically, such applications check the role of a user and provide access to resources based on that role. .NET Framework role-based security supports authorization by making information about the principal available to the current thread. A principal represents the identity and role of a user and acts on the user's behalf. A principal is constructed from an associated identity; the identity can be either based on a Windows account or be a custom identity unrelated to a Windows account. .NET Framework applications can make authorization decisions based on the principal's identity or role membership, or both. Role-based security in the .NET Framework supports three kinds of principals:

  • Generic principals. Represent users and roles that exist independent of Microsoft Windows operating system users and roles.

  • Windows principals. Represent Windows users and their roles.

  • Custom principals. Define an application's principals.

Note More information on role-based security is available at

Cryptographic Services

.NET provides various classes in the cryptography namespace to manage many details of cryptography, such as unmanaged Microsoft CryptoAPI and other managed implementations. Cryptography is used to achieve the following goals:

  • Confidentiality. To help protect a user's identity or data from being read.

  • Data integrity. To help protect data from being altered.

  • Authentication. To ensure that data originates from a trusted data source.

To achieve these goals, a combination of algorithms and practices can be used as part of .NET cryptography as described as follows:

  • Secret-key or symmetric encryption

  • Public-key or asymmetric encryption

  • Digital signatures

  • Hash values

  • Random number generation

Note More information about the preceding mechanisms is available at
.NET Application Security is also discussed in detail in Chapter 1, “Introduction to .NET” in this volume. More information on how to develop secured applications in .NET is available at

Isolated Storage

Isolated storage is a data storage mechanism that provides isolation and safety by defining standardized methods for associating code with saved data. With isolated storage, data is always isolated by user and by assembly. Credentials such as the origin or the strong name of the assembly determine assembly identity. Data can also be isolated by the application domain, using similar credentials. When using isolated storage, applications save data to a unique data compartment that is associated with some aspect of the code's identity, such as its Web site, publisher, or signature. The data compartment is an abstraction, not a specific storage location. It consists of one or more isolated storage files, called stores, which contain the actual directory locations where data is stored.

Administrators can limit how much isolated storage an application or a user has available, based on an appropriate trust level. In addition, administrators can remove all a user's persisted data. To create or access isolated storage, code must be granted the appropriate IsolatedStorageFilePermission.

To access isolated storage, the code must have all necessary native platform operating system rights. Microsoft .NET Framework applications already have operating system rights to access isolated storage unless they perform (platform-specific) impersonation. In this case, the application is responsible for ensuring that the impersonated user identity has the proper operating system rights to access isolated storage. The three main classes provided to help you perform tasks that involve isolated storage are:

  • IsolatedStorageFile. It derives from IsolatedStorage and provides basic management of stored assembly and application files. An instance of the IsolatedStorageFile class represents a single store located in the file system.

  • IsolatedStorageFileStream. It derives from System.IO.FileStream and provides access to the files in a store.

  • IsolatedStorageScope. It is an enumeration that enables you to create and select a store with the appropriate isolation type.

The isolated storage classes enable you to create, enumerate, and delete isolated storage. The methods for performing these tasks are available through the IsolatedStorageFile object. Some operations require you to have the IsolatedStorageFilePermission that represents the right to administer isolated storage. The Isolated Storage tool, Storeadm.exe, can also be used for simple store management such as listing or deleting all the stores for the current user.

Note More information on isolated storage is available at


Serialization is the process of converting an object or a graph of objects into a linear sequence of bytes either for storage or for transmission to another location. Through serialization, a developer can perform actions like sending the object to a remote application by means of a Web service, passing an object from one domain to another, passing an object through a firewall as an XML string, or maintaining security or user-specific information across applications. When the object is serialized to a stream, it carries not just the data, but information about the object's type, such as its version, culture, and assembly name. From that stream, it can be stored in a database, a file, or memory. Deserialization is the process of taking in stored information and recreating objects from it.

The .NET Framework provides built-in mechanisms for implementing serialization and deserialization of objects such as run-time serialization, binary serialization, and XML serialization. These mechanisms are described in detail in the following section.

Run-Time Serialization

The namespace associated with run-time serialization in the .NET Framework is System.Runtime.Serialization. It contains classes that can be used for serializing and deserializing objects. It also implements the ISerializable interface, which provides a way for classes to control their own serialization behavior. Classes in the System.Runtime.Serialization.Formatters namespace control the actual formatting of various data types encapsulated in the serialized objects.

Two kinds of serialization can be used to serialize any object at run time. They are:

  • Binary serialization. Binary serialization uses binary encoding to produce compact serialization for uses such as storage or socket-based network streams. The System.Runtime.Serialization.Formatters.Binary namespace contains the BinaryFormatter class, which can be used to serialize and deserialize objects in binary format.

  • XML serialization. XML serialization serializes the public fields and properties of an object, or the parameters and return values of methods, into an XML stream that conforms to a specific XML schema definition language (XSD) document. XML serialization results in strongly typed classes with public properties and fields that are converted to XML. The System.Xml.Serialization namespace contains the classes necessary for serializing and deserializing XML.

Note More information on the run-time serialization namespace is available at

.NET Remoting

.NET Remoting provides a rich and extensible framework for objects residing in different application domains, processes, and computers to communicate with each other seamlessly. The framework provides a number of services, including activation and lifetime support, as well as communication channels for transporting messages to and from remote applications. Formatters are used for encoding and decoding the messages that are transported by the channel. Remoting was designed with security in mind, and a number of hooks are provided that allow channel sinks to gain access to the messages and serialized stream before the stream is transported over the channel.

.NET Remoting also provides an abstract approach to interprocess communication that separates the remotable object from a specific client or server application domain and from a specific mechanism of communication. As a result, it is flexible and easily customizable. You can replace one communication protocol with another or one serialization format with another without recompiling the client or the server. In addition, the remoting system assumes no particular application model. You can communicate from a Web application, a console application, a Windows service—from almost anything you want to use.

To use .NET Remoting to build an application in which two components communicate directly across an application domain boundary, you need to build only the following:

  • A remotable object.

  • A host application domain to listen for requests for that object.

  • A client application domain that makes requests for that object.

Note More information on building a .NET Remoting application is available at

XML Web Services in .NET

XML Web services are the fundamental building blocks of distributed computing on the Internet. The focus on communication and collaboration among people and applications and open standards have created an environment where XML Web services are becoming the platform for application integration. Applications are constructed using multiple XML Web services from various sources that work together regardless of where the applications reside or how the applications were implemented.

There are as many definitions of XML Web services as there are companies building them. However, almost all definitions have the following points in common:

  • XML Web services expose useful functionality to Web users through a standard Web protocol. In most cases, the protocol used is Simple Object Access Protocol (SOAP).

  • XML Web services describe their interfaces in sufficient detail to allow a user to build a client application to talk to the services. This description is usually provided in an XML document called a Web Services Description Language (WSDL) document; it mainly consists of the metadata necessary for the client applications to consume the Web service.

  • XML Web services are registered so that users can find the services easily. This is done with Universal Discovery Description and Integration (UDDI).

Note More information on XML Web services is available at

Enterprise Services in .NET

Component-based applications can be built using COM. However, the plumbing work required to write COM components is significant and repetitive. COM+ is not just a new version of COM; rather, COM+ provides a services infrastructure for components. The components are built and then installed in COM+ applications to build scalable server applications that achieve high throughput and are easy to deploy. (If a component does not need to use any services, then it should not be placed in a COM+ application). Scalability and throughput is achieved by designing applications that make use of services such as transactions, object pooling, and activity semantics.

The .NET Framework provides a way of writing component-based applications that has the following advantages over the COM programming model:

  • Better tool support.

  • Common language runtime (CLR).

  • Easier coding syntax.

The .NET Framework provides a managed class into COM+ called Enterprise Services (ES) within the System.EnterpriseServices namespace. This simplifies the programmatic usage of the settings in COM+ catalog by reducing the COM+ component configuration and administration time.

Figure 8.1 depicts usage of COM+ and .NET.

Figure 8.1. Usage of COM+ services in .NET Framework

Figure 8.1. Usage of COM+ services in .NET Framework

The COM+ services infrastructure can be accessed from managed as well as unmanaged code. Services in unmanaged code are known as COM+ services. In .NET, these services are referred to as Enterprise Services. Deriving a class from the ServicedComponent class indicates that services will be required for a component. (If a component does not need to use any services, then it should not derive from ServicedComponent). The important features provided by COM+ services or the .NET Enterprise Services are:

  • Automatic transaction processing

  • Just In Time activation

  • Object pooling

  • Queued components

  • Role-based security

Note More Information about the COM+ services and .NET Enterprise Services is available at

Enterprise Templates

Visual Studio .NET 2003 Enterprise edition provides a set of Enterprise Templates to use as a basis for developing more complex applications. They are based on the task the application is trying to accomplish instead of focusing on the programming language being used. Enterprise Templates perform three fundamental services that improve development effectiveness and reduce the overall cost of distributed applications:

  • Defining the initial structure of a distributed application. Enterprise Templates provide architectural guidance in the form of the initial application structure and the policy that defines where various components and technologies can be used. Visual Studio .NET 2003 provides several templates targeted at generic distributed applications. Typically, this generic structure divides an application into a set of components, such as Web/Windows User Services, Business Facade/Logic, and Data Services/Storage, and populates each tier of the solution with language projects to provide the application's components, interfaces, and services.

  • Reducing complexity for developers. An Enterprise Template makes it easier for less-experienced developers to make appropriate choices by presenting those choices that are recommended by the organization's architectural experts. Enterprise Templates implement preferred development policies, controlling available options and properties in the Visual Studio integrated development environment (IDE), and specifying custom help to guide project completion. These development policies apply to the entire application, projects, classes, and other solution items.

  • Providing architectural and technological guidance. Architectural guidance is about using proven, reusable building blocks for an application's structure. Each Enterprise Template provides such architectural guidance by defining a basic application structure, providing the beginning project files, controlling associated development policy, and displaying appropriate developer guidance information through dynamic Help and Task List items. The policy and guidance information drives developer completion of the application's final components, interfaces, and services.

Creating an Enterprise Template in Visual Studio .NET is a two-step process. First, you must create an "Enterprise Template Project" project in Visual Studio .NET, which allows you to define the application skeleton developers receive when they create a project with your template. Next, you must expose the template to developers so that it can be accessed by the environment's New Project dialog box. The latter step is accomplished by converting the template into a format understood by Visual Studio .NET.

Note More information on Enterprise Templates is available at

Along with the features described in this chapter, .NET also supports various new features in the latest versions of .NET Framework 2.0 and Visual Studio .NET 2005.

Note More information on .NET Framework 2.0 and its new features is available at
More information on Visual Studio .NET 2005 and its new features is available at


Get the UNIX Custom Application Migration Guide

Update Notifications

Sign up to learn about updates and new releases


Send us your comments or suggestions