Building an Assembly That References a Strongly

Named Assembly....................................................................................... 74

Strongly Named Assemblies Are Tamper-Resistant.................................... 75

Delayed Signing......................................................................................... 76

Privately Deploying Strongly Named Assemblies....................................... 79

How the Runtime Resolves Type References.............................................. 80

Advanced Administrative Control (Configuration)..................................... 83

In Chapter 2, “Building, Packaging, Deploying, and Administering Applications and Types,” I talked about the steps required to build, package, and deploy an assembly. I focused on what’s called pri- vate deployment, in which assemblies are placed in the application’s base directory (or a subdirectory thereof) for the application’s sole use. Deploying assemblies privately gives a company a large degree of control over the naming, versioning, and behavior of the assembly.

In this chapter, I’ll concentrate on creating assemblies that can be accessed by multiple applica- tions. The assemblies that ship with the Microsoft .NET Framework are an excellent example of glob- ally deployed assemblies, because all managed applications use types defined by Microsoft in the

.NET Framework Class Library (FCL).

As I mentioned in Chapter 2, Windows has a reputation for being unstable. The main reason for this reputation is the fact that applications are built and tested using code implemented by someone else. After all, when you write an application for Windows, your application is calling into code written by Microsoft developers. Also, a large number of companies make controls that application develop- ers can incorporate into their own applications. In fact, the .NET Framework encourages this, and many control vendors have appeared over time.

As time marches on, Microsoft developers and control developers modify their code: they fix bugs, make security updates, add features, and so on. Eventually, the new code makes its way onto the user’s machine. The user’s applications that were previously installed and working fine are no longer using the same code that the applications were built and tested with. As a result, the applications’ behavior is no longer predictable, which contributes to the instability of Windows.

File versioning is a very difficult problem to solve. In fact, I assert that if you take a file that is used by other code files and change just one bit in the file—change a 0 to a 1 or a 1 to a 0—there’s abso- lutely no way to guarantee that code that used the file before it was changed will now work just as well if it uses the new version of the file. One of the reasons why this statement is true is that a lot of applications exploit bugs, either knowingly or unknowingly. If a later version of a file fixes a bug, the application no longer runs as expected.

So here’s the problem: How do you fix bugs and add features to a file and also guarantee that you don’t break some application? I’ve given this question a lot of thought and have come to one conclu- sion: It’s just not possible. But, obviously, this answer isn’t good enough. Files will ship with bugs, and companies will always want to provide new features. There must be a way to distribute new files with the hope that the applications will work just fine. And if the application doesn’t work fine, there has to be an easy way to restore the application to its last-known good state.

In this chapter, I’ll explain the infrastructure that the .NET Framework has in place to deal with versioning problems. Let me warn you: What I’m about to describe is complicated. I’m going to talk about a lot of algorithms, rules, and policies that are built into the common language runtime (CLR). I’m also going to mention a lot of tools and utilities that the application developer must use. This stuff is complicated because, as I’ve mentioned, the versioning problem is difficult to address and to solve.

Date: 2016-03-03; view: 621