CSC 325 Advanced Programming Techniques

1
Assemblies

• Mikhail Brikman

2
Chapter 18 Topics Discussed

• Assembly manifest.
• Assembly resources.
• Creating assemblies.
• Satellite assemblies.
• Application domains.
• Shared assemblies.

3
.NET Assemblies - I

• Assemblies - fundamental unit of deployment,
  version control, reuse, activation scoping, and
  security permissions.
• Executable (.exe) file or dynamic link library
  (.dll) file.
• Collection of types and resources that form a
  logical unit of functionality and are built to
  work together.
• Can be shared by including into the global
  assembly cache.
• Must be strong-named before they can be included
  in the global assembly cache

4
.NET Assemblies - II

• Loaded into memory only when required.
• Efficiently manage resources in large projects.
• Reflection is used to obtain assembly information
  at runtime.
• To load an assembly only to inspect it, use a
  method such as ReflectionOnlyLoadFrom.

5
.NET Assemblies - III

• Solve versioning problems no DLL hell.
• Version rules on the usage of different software
  components are set and enforced at runtime.
• Allow multiple versions of an application or a
  component to be run simultaneously (side-by-side
  execution).
• CLR attempts to bind with the exact version of an
  assembly that the application was built with.
• Default behavior can be overridden by
  configuration file settings.

6
Assembly Functions - I

• Contains code that the CLR executes.
• MSIL (Microsoft intermediate language) code in a
  portable executable (PE) file will not be
  executed if it does not have an associated
  assembly manifest.
• Each assembly can have only one entry point.
• Forms a security boundary - an assembly is the
  unit at which security permissions are requested
  and granted.
• Forms a type boundary.

7
Assembly Functions - II

• Every data type's identity includes the name of
  the assembly in which it resides.
• Creates a reference scope boundary.
• Presents a version boundary.
• Assembly is the smallest versionable unit in the
  CLR.
• All types and resources in the same assembly are
  versioned as a unit.
• Assembly's manifest describes the version
  dependencies you specify for any dependent
  assemblies.

8
Assembly Functions - III

• Is a deployment unit.
• When an application starts, only the assemblies
  that the application initially calls must be
  loaded into memory.
• Other assemblies, such as localization resources
  or assemblies containing utility classes, are
  retrieved on demand.
• This allows applications to be kept simple and
  thin when first loaded.

9
Assembly Types - I

• Single file - DLL or EXE.
• Multifile - several DLLs, EXEs, resource files,
  etc.
• Static assemblies store .NET Framework types
  (interfaces and classes), resources for the
  assembly (bitmaps, JPEG files, resource files,
  and so on).
• Static assemblies are stored on disk in portable
  executable (PE) files.

10
Assembly Types - II

• System.Reflection.Emit namespace allows create
  dynamic assemblies by emitting metadata and
  Microsoft intermediate language (MSIL) at run
  time and optionally generate a portable
  executable (PE) file on disk.
• Dynamic assemblies are run directly from memory
  and are not saved to disk before execution.
• Dynamic assemblies can be saved to disk after
  they have executed.

11
Assembly Manifest - I

• The metadata describing an assembly
• Contains assembly metadata that is used for
  resolving types and satisfying resource requests.
  
• Specifies the types and resources that are
  exposed outside the assembly.
• Enumerates other assemblies on which it depends.
• May be a separate file, or may be included in one
  of the executable files.
• The version number is stored in the manifest
  along with other identity information, including
  the friendly name and supported locales.

12
Assembly Manifest - II

• Contains
• Assembly name.
• Version number.
• Culture.
• Strong name information.
• List of all files in the assembly.
• Type reference information.
• Information on referenced assemblies.

13
Assembly Components

• A static assembly consists of
• Assembly manifest.
• Type metadata.
• MSIL code that implements the types.
• A set of resources.
• Only the assembly manifest is required, but
  either types or resources are needed to create a
  useful assembly.

14
MSIL Disassembler - I

• ildasm.exe
• Displays the information for any .NET .exe or
  .dll in human readable format.
• Shows namespaces and types, including their
  interfaces.
• Can examine native .NET assemblies or assemblies
  provided by others.
• Use the Visual Studio Command Prompt Start -gt
  All Programs -gt Visual Studio -gt Visual
  Studio Tools - gt Visual Studio Command
  Prompt.

15
MSIL Disassembler - II

• From inside Visual Studio Tools -gt ILDasm.
• chapter18\AssemblySamples\SharedDemo\bin\Debug\Sha
  redDemo.dll
• Manifest window - all metadata.
• Tree view items double click to see the MSIL
  code.

16
Creating Assemblies

1. Use development tools, such as Visual Studio, to
   create .dll or .exe files. All C projects in
   Visual Studio generate assemblies.
2. Use tools in the .NET Framework SDK (al.exe -
   assembly linker) to create assemblies with
   modules created in other development
   environments.
3. Use command-line tools.
4. Use common language runtime APIs, such as
   Reflection.Emit, to create dynamic assemblies.

17
Assembly Attributes

• Assembly attributes provide information about an
  assembly
• Assembly identity attributes - name, version, and
  culture.
• Informational attributes - company or product
  information.
• Assembly manifest attributes - title,
  description, the default alias, and
  configuration.
• Strong name attributes.
• chapter18\AssemblySamples\AssemblySamples.sln -gt
  DynamicAssembly.csproj -gt AssemblyInfo.cs

18
Dynamic Assemblies

• CSharpCodeProvider class - runtime access to
  instances of the C code generator and code
  compiler.
• CompilerParameters class represents the settings
  and options for an ICodeCompiler interface.
• CompilerResults Class - results of compilation
  returned by compiler.
• chapter18\AssemblySamples\AssemblySamples.sln -gt
  DynamicAssembly.csproj -gt CodeDriver.cs
• Type.Invoke method uses reflection to execute the
  dynamically generated code.

19
Application Domains - I

• Represented by AppDomain class.
• Provide isolation, unloading, and security
  boundaries for executing managed code.
• Assembly must be loaded into an application
  domain before its code can execute.
• Several threads/applications can belong to a
  single application domain.
• At any given time a thread executes in a single
  application domain.

20
Application Domains - II

• chapter18\AssemblySamples\AssemblySamples.sln -gt
  AssemblyA.csproj
• chapter18\AssemblySamples\AssemblySamples.sln -gt
  DomainTest.csproj
• Uncomment line 30 and comment out line 29 in
  DynamicAssemblyWindow.xaml.cs.
• Now the code can be unloaded from the application
  single compile.
• chapter18\AssemblySamples\AssemblySamples.sln -gt
  DynamicAssembly.csproj -gt CodeDriverInAppDomain.cs

21
Shared Assemblies - I

• Assemblies can be private or shared.
• Default - simple programs not used by other
  applications should be in a private assembly.
• Shared assembly must be placed in the Global
  Assembly Cache (GAC).

22
Shared Assemblies - II

• To share an assembly
• Create your assembly.
• Assign a strong name to your assembly.
• Assign version information to your assembly.
• Add your assembly to the GAC.
• Access the types contained in the assembly from
  the other applications.

23
Global Assembly Cache - I

• Each computer using CLR has a single unique code
  cache called the global assembly cache.
• GAC only stores assemblies shared by several
  applications on the computer.
• Share assemblies in GAC only when you need to.
• Keep assembly dependencies private and place
  assemblies in the application directory unless
  sharing an assembly is explicitly required.

24
Global Assembly Cache - II

• To deploy an assembly into the GAC
• Use a Windows installer designed to work with the
  GAC - recommended option for installing
  assemblies into the global assembly cache.
• Or use the Global Assembly Cache tool
  (Gacutil.exe), provided by the Windows Software
  Development Kit (SDK).
• GAC assemblies must have a strong name.
• Before an assembly is added to GAC, integrity
  checks are performed on all files that make up
  the assembly.

25
Strong-Named Assemblies - I

• Strong name assembly's identity.
• Includes
• Simple text name.
• Version number.
• Culture information (if provided).
• Public key.
• Digital signature.

26
Strong-Named Assemblies - II

• Generated from an assembly file (assembly
  manifest, which in turn contains the names and
  hashes of all the files that make up the
  assembly) using the corresponding private key.
• If assemblies have the same strong name, they are
  expected to be identical.
• Using a strong-named assembly as a reference,
  results in as versioning and naming protection.
• Strong-named assemblies can only reference other
  strong-named assemblies.

27
Strong-Named Assemblies - III

• To sign an assembly with a strong name, create a
  public/private key pair.
• Use the Strong Name tool (Sn.exe).
• Visual Studio C and Visual Basic project
  property pages include a Signing tab to select
  existing key files or to generate new key files
  without explicitly using Sn.exe.
• Key pair files usually have an .snk extension.

28
Strong-Named Assemblies - IV

• chapter18\AssemblySamples\AssemblySamples.sln -gt
  SharedDemo.csproj, Client.csproj
• When signing an assembly, the private key my not
  be available.
• Business might not provide access to the key pair
  to developers.
• Use delayed signing to provide the public key,
  deferring the addition of the private key until
  the assembly is released.

29
Versioning

• The specific version of an assembly and the
  versions of dependent assemblies are recorded in
  the assembly's manifest only for strong-named
  assemblies.
• Rules for locating assemblies at runtime.
• The default version policy - applications run
  only with the versions they were built and tested
  with, unless overridden by explicit version
  policy in configuration files.
• CLR versioning rules.