Page 18 - Open Soource Technologies 304.indd

Unit 1: Introduction to Visual Basic

that could have affected the application. A user may remember installing something a week Notes
ago, but there is no obvious correlation between that installation and the behavior they are now
seeing. To make matters worse, there are few diagnostic tools available today to help the user
(or the support person who is helping them) determine what is wrong. The reason for these
issues is that version information about the different components of an application aren’t recorded
or enforced by the system. Also, changes made to the system on behalf of one application will
typically affect all applications on the machine–building an application today that is completely
isolated from changes is not easy. One reason why it’s hard to build an isolated application is
that the current run-time environment typically allows the installation of only a single version
of a component or an application. This restriction means that component authors must write
their code in a way that remains backward compatible, otherwise they risk breaking existing
applications when they install a new component. In practice, writing code that is forever backward
compatible is extremely difficult, if not impossible. In .NET, the notion of side-by-side is core to
the versioning story. Side-by-side is the ability to install and run multiple versions of the same
component on the machine at the same time. With components that support side-by-side, authors
aren’t necessarily tied to maintaining strict backward compatibility because different applications
are free to use different versions of a shared component.

1.3.9 Global Assembly Cache (GAC)

Each computer where the common language runtime is installed has a machine-wide code cache
called the global assembly cache. The global assembly cache stores assemblies specifically
designated to be shared by several applications on the computer. You should share assemblies
by installing them into the global assembly cache only when you need to. As a general guideline,
keep assembly dependencies private, and locate assemblies in the application directory unless
sharing an assembly is explicitly required. In addition, it is not necessary to install assemblies
into the global assembly cache to make them accessible to COM interop or unmanaged code.

Note There are scenarios where you explicitly do not want to install an assembly into the
global assembly cache. If you place one of the assemblies that make up an application in
the global assembly cache, you can no longer replicate or install the application by using
the xcopy command to copy the application directory. You must move the assembly in the
global assembly cache as well.
There are several ways to deploy an assembly into the global assembly cache:
Use an installer designed to work with the global assembly cache. This is the preferred
option for installing assemblies into the global assembly cache.
Use a developer tool called the Global Assembly Cache tool (Gacutil.exe), provided by the
.NET Framework SDK.
Use Windows Explorer to drag assemblies into the cache.

Note In deployment scenarios, use Windows Installer 2.0 to install assemblies into the
global assembly cache. Use Windows Explorer or the Global Assembly Cache tool only in
development scenarios, because they do not provide assembly reference counting and
other features provided when using the Windows Installer.
Administrators often protect the WINNT directory using an Access Control List (ACL) to control
write and execute access. Because the global assembly cache is installed in the WINNT directory,

LOVELY PROFESSIONAL UNIVERSITY 11