Chapter 5. Building Applications


So far, most of the examples in this book have focused on simple, single-file .NET applications. In the real world, of course, applications tend to be much larger, consisting of many discrete files. These files will include both program files that contain code (both managed and unmanaged), and non “code- related files, such as data, message, or icon files. To complicate matters even further, many modern applications draw resources from many disparate locations ”portions of the application may come from one server, while other portions come from another server. From the user 's point of view, these discrete portions all combine at runtime to form the final application.

These concepts should be familiar to anyone experienced in creating applications using traditional techniques. The traditional model for building Windows applications is to compile multiple source code files into discrete object files, and then to link them together into a package such as a dynamically linked library (DLL) or an executable. The complete application can then be considered a grouping of these executables, DLLs, and files. This is particularly true when using COM or other component models. Individual components are built and distributed as a DLL, and the final application is generally a collection of such components, plus "glue" ”that is, the executable that combines them into a usable application.

The traditional model of packaging applications works reasonably well, but has a number of shortcomings that .NET attempts to overcome . Notably, when working with distributed applications or applications deployed via the Internet, a number of problems can surface that should be well known to any experienced developer:

Version Conflicts. As later versions of particular components are released, conflicts can arise with other applications that use the same component. For example, Application A and Application B may both use the Widget component. After the installation of both applications, a new version of Application A may be released that uses a later version of the Widget component. Under this scenario, Application B might fail when the new version of Application A is installed on a machine as the new Widget component is not 100% compatible with Application B. This situation is commonly referred to as "DLL hell."

Trojan Horse Components. A malicious (or well-intentioned but misguided) person may attempt to replace the Widget component with a completely different component that merely shares the same base name . Much as in the version conflict problem, this new component may (or may not) work well with some applications, but may cause others to fail. Debugging such failures in the field can prove very difficult.

Locale Information. Traditionally, managing locale-related or cultural differences has fallen to the application author. Although string tables and other such techniques are commonly used, the operating system and application loading process offer no real support for this task, which can make deployment painful for multiple versions of an application differing only in terms of its locale or culture.

The fundamental .NET concept for solving all of these problems is the assembly. This chapter defines and discusses the .NET assembly and demonstrates how assemblies solve these problems. In addition, it describes how to build and deploy assemblies to take advantage of the facilities offered by .NET. The final section delves further into the concept of an application domain and examines how programmers can programmatically utilize this concept.



Programming in the .NET Environment
Programming in the .NET Environment
ISBN: 0201770180
EAN: 2147483647
Year: 2002
Pages: 146

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net