NET Frameworks week 5 December 4 2003

. NET Frameworks week 5 December 4, 2003

Agenda – December 5, 2003 Other. NET Languages Class Exercise How the. NET CLR provides Multiple Language Support PE File Format DUMPBIN Class Exercise bootstrapping the CLR. NET How JIT compilation works Packaging code in. NET Assemblies using the ILDASM Class Exercise Modules and assemblies Assembly Identification Strong names The Global Assembly Cache Class Exercise Homework

Course Schedule Week Topics 5 - Thursday Bootstrapping the Common Language Resource (CLR) 12/4/2003 Modules and Assemblies. Net Packaging Public and Private Keys Shared Assemblies The Global Assemble Cache (GAC) Strong Names. NET Frameworks Language Overview Frameworks Class Library

Course Schedule Week 6 - Monday 12/8/2003 Topics ASP. NET Programming. NET Web Form Application Introduction to Web Services Web Security 7 - Thursday Web Services Class Project 12/11/2003 8 - Monday Web Services Class Project (continued) 12/15/2003

Homework Questions ? • Tab Controls • Setting Focus to Text. Box's

Course Goals

Course Goals #1 Provide an overview of the. NET Architecture and it’s Major Components – Programming Languages – ADO. NET – ASP. NET – Web Services – XML Integration

Course Goals #2 Understand the. NET Frameworks as an Object Oriented, Strongly Typed, Computing Environment

Course Goals #3 Work with various. NET Framework components – Common Language Runtime (CLR) –. NET Framework Class Library (FCL) – Assemblies – Strong Names – The Global Assembly Cache (GAC) – ADO. NET – ASP. NET – Web Services

Course Goals #4 Develop a basic fluency programming in C#

Where Are We After 4 Weeks? • Learned some C# • Worked with Windows Forms and. ADO • Spent some time on Classes, Types and Objects • Now we're going to look into the. NET portion of. NET, Strong Names and Shared Assemblies Tonight • On to Web Forms and then Web Services

Tonight’s Class Goals • • • Other. NET Languages How the. NET CLR provides Multiple Language Support PE File Format DUMPBIN bootstrapping the CLR. NET How JIT compilation works Packaging code in. NET Assemblies using the ILDASM Modules and assemblies Assembly Identification Strong names The Global Assembly Cache

Other. NET Languages

Other languages • The. NET Framework supports a host of language environments – – – Visual Basic. NET Visual C++. NET JScript. NET Fujitsu COBOL. NET Python, Perl, Eiffel…. • Let’s do a quick comparison of C# with VB. NET

Language Comparison Feature C# VB. NET JScript Declaring variables int x; int x = 10; Dim x As Integer Public x As Integer = 10 var x : int; var x : int = 10; var x = 10; Comments // comment /* multiline comment */ ' comment x = 1 ' comment Rem comment // comment /* multiline comment */ Assignment Statements n. Val = 7; Conditional statements if (n. Cnt <= n. Max) { If n. Cnt <= n. Max Then if (n. Cnt <= n. Max) { n. Total += n. Cnt; n. Cnt++; } else { Else n. Total +=n. Cnt; n. Cnt--; } n. Total += n. Cnt += 1 n. Total += n. Cnt -= 1 n. Total += n. Cnt; n. Cnt++; } else { n. Total +=n. Cnt; n. Cnt--; End If }

Language Comparison (continued) Feature C# VB. NET JScript For loop for (int i = 1; i <= 10; i++) Console. Write. Line("The number is {0}", i); For n = 1 To 10 for (var n = 0; n < 10; n++) { print("The number is " + n) } While loop while (n < 100) n++; While n < 100 n += 1 End While while (n < 100) n++; Select statement switch(n) { case 0: Console. Write. Line("Zero"); break; case 1: Console. Write. Line("One"); break; case 2: Console. Write. Line("Two"); break; default: Console. Write. Line("? "); } Select Case n Case 0 Msg. Box ("Zero") Case 1 Msg. Box ("One") Case 2 Msg. Box ("Two") Case Else Msg. Box ("Default") End Select switch(int(n)) { case 0 : print("Zero") break case 1 : print("One") Break case 2 : print("Two") default : print("Default") } Msg. Box("The number is " & n) Next

Language Comparison (continued) Keyword C# VB. NET JScript Classes class Class class Current object this Me this Namespaces namespace Namespace package Accessing a namespace using Imports import

Visual Basic Class Exercise or How about a visual basic hello world visual studio program (i. e. a form, some text, a few buttons, change the colors, display a messagebox, be creative. . . )?

Class Exercise • Take 30 minutes • Use Visual Studio (except choose Visual Basic. NET as the language) • See how it feels! • Be prepared to discuss what you liked and what you didn't like

How does the. NET CLR (Common Langauge Runtime) support multiple compliant languages ? • CTS – Common Type System • CLS – Common Language Specification • FCL –. NET Framework Class Library

CTS Common Type System

Common Type System (CTS) • The CLR is heavily dependent on Type Information • Because of this, Microsoft has created a formal specification, the CTS. – It defines how types are defined – It defines how types behave • Every. NET language must abide by this spec. – This ensures that common types have the same conceptual semantics across various. NET languages.

Common Type System (CTS) • The CTS states that all types must ultimately inherit from a predefined base type, System. Object • The CTS states that a type can contain zero or more members • Members can be: – Field : a data variable that is part of an object’s state. – Method : a function that performs an operation on an object – Property : to the caller, this looks like a field, but to the implementer, it looks like a method (or two) – Event : a notification method between objects.

Common Type System (CTS) • The CTS also specifies type visibility rules and rules for access to members of a type. • The following options are allowed for methods/fields: – Private : the method is accessible only by other members of the class – Protected : the method is accessible by derived types as well – Assembly : the method is callable by any code in the same executable unit. – Protected and assembly / Protected or assembly – Public accessible by any code in any executable unit

CLS Common Language Specification

CLS Common Language Specification • Language integration is a great goal, but is very hard to do. • Languages are intrinsically different, especially if they have a legacy behind them (e. g. VB, C++) • The CLS is the minimum set of features that compilers must support if they are to target the CLR • As a programmer, you can build in checks for CLS compliance if you expect your type to be used from other languages.

CLS (contd. ) CLS in context: CLR/CTS VB C# CLS C++

CLS Compliance • Examples of things that would not be CLS compliant: – Unsigned integers – Case sensitive overloads of names • The compliance rules apply only to parts of the type that are visible outside the defining executable unit. • You can catch non-compliance at compile time by using the CLSCompliant(true) attribute – E. g. • [assembly: CLSCompliant(true)] sets it on for the whole executable unit. • Can turn it off on individual methods with [CLSCompliant(false)]

FCL. NET Framework Class Library

NET Framework Class Library • The. NET Framework includes classes, interfaces, and value types that expedite and optimize the development process and provide access to system functionality. • To facilitate interoperability between languages, the. NET Framework types are CLS-compliant and can therefore be used from any programming language whose compiler conforms to the common language specification (CLS).

. NET Framework Class Library The. NET Framework types are the foundation on which. NET applications, components, and controls are built. The. NET Framework includes types that perform the following functions: – Represent base data types and exceptions. – Encapsulate data structures. – Perform I/O. – Access information about loaded types. – Invoke. NET Framework security checks. – Provide data access, rich client-side GUI, and servercontrolled, client-side GUI.

. NET Framework Class Library • The. NET Framework provides a rich set of interfaces, as well as abstract and concrete (nonabstract) classes. • You can use the concrete classes as is or, in many cases, derive your own classes from them. • To use the functionality of an interface, you can either create a class that implements the interface or derive a class from one of the. NET Framework classes that implements the interface.

What Happens When You Compile?

What happens when you compile • The respective language compiler processes your code into intermediate language (IL) code. C# Code C# Compiler VB. Net Code COBOL Code VB Compiler COBOLCompiler IL and related data

. NET Standardization • Microsoft’s version of IL is know as MSIL(Microsoft intermediate language) • A word on standards – Right from day one, the intent has been to standardize the. NET framework and the C# language – To this end, Microsoft has submitted the. NET Framework and C# to ECMA (before 1994 it was known as ECMA - European Computer Manufacturers Association). • http: //msdn. microsoft. com/net/ecma/default. asp • CLI (Common Language Infrastructure) includes the CLR, FCL and IL • IL is referred to as CIL. – A hyperlinked version of the C# spec can be found at: • http: //www. jaggersoft. com/csharp_standard/index. htm

What’s in an executable, anyway? • Three types of executables: – Windows executable – Console executable – Dynamic Link Library (dll) • Executables are in PE File Format • Dumpbin is a traditional tool for looking inside an exe (or a dll). • ILDASM is a. NET tool for looking inside a. NET executable

Portable Executable File Format

A bit about the PE File Format • Microsoft introduced the PE File format, more commonly known as the PE format, as part of the original Win 32 specifications. • The term "Portable Executable" was chosen because the intent was to have a common file format for all flavors of Windows, on all supported CPUs. To a large extent, this goal has been achieved with the same format used on Windows NT and descendants, Windows 95 and descendants, and Windows CE. • PE files are derived from the earlier Common Object File Format (COFF) found on VAX/VMS. This makes sense since much of the original Windows NT team came from Digital Equipment Corporation. It was natural for these developers to use existing code to quickly bootstrap the new Windows NT platform.

A bit about the PE File Format • OBJ files emitted by Microsoft compilers use the COFF format. You can get an idea of how old the COFF format is by looking at some of its fields, which use octal encoding! COFF OBJ files have many data structures and enumerations in common with PE files, and I'll mention some of them as I go along. • The addition of 64 -bit Windows required just a few modifications to the PE format. This new format is called PE 32+. No new fields were added, and only one field in the PE format was deleted. The remaining changes are simply the widening of certain fields from 32 bits to 64 bits. In most of these cases, you can write code that simply works with both 32 and 64 -bit PE files. The Windows header files have the magic pixie dust to make the differences invisible to most C++-based code.

A bit about the PE File Format • The distinction between EXE and DLL files is entirely one of semantics. They both use the exact same PE format. The only difference is a single bit that indicates if the file should be treated as an EXE or as a DLL. Even the DLL file extension is artificial. You can have DLLs with entirely different extensions—for instance. OCX controls and Control Panel applets (. CPL files) are DLLs.

The Portable Executable (PE) file format. • Since the days of Windows NT 3. 5, MS has used the PE file format as the layout format of their executable files. DOS MZ Header PE Header COFF Header Executable Code (. text, . idata)

The PE file format (continued) • The advantage of the PE format is that it maps out almost identically in memory at runtime. • The. text section has machine instructions • The. idata section (Import data) contains references to other dlls.

DUMPBIN

DUMPBIN Reference • The Microsoft COFF Binary File Dumper (DUMPBIN. EXE) displays information about 32 -bit Common Object File Format (COFF) binary files. • You can use DUMPBIN to examine COFF object files, standard libraries of COFF objects, executable files, and dynamic-link libraries (DLLs). • Note DUMPBIN runs only from the command line. C: Program FilesMicrosoft Visual Studio. NETVc 7bindumpbin. exe

DUMPBIN command line • To run DUMPBIN, use the following syntax: DUMPBIN [options] files. . . • Specify one or more binary files, along with any options required to control the information. DUMPBIN displays the information to standard output. You can either redirect it to a file or use the /OUT option to specify a file name for the output. • When you run DUMPBIN on a file without specifying an option, DUMPBIN displays the /SUMMARY output. • When you type the command dumpbin without any other command-line input, DUMPBIN displays a usage statement that summarizes its options.

Class Exercise 1. Create a directory C: Demo 2. Download Demo. zip to C: Demo 3. Unzip all files to C: directory (this will put the files into the C: Demo directory tree) 4. Open a console window 5. Set Default to C: Demo (cd c: demo) 6. Type: dumpbin/headers helloworld. exe | more

Managed. NET executables also use the PE file format.

The structure of a. NET PE file • We will keep referring to this as we delve deeper into assemblies. • The MZ header ensures that this code does not crash on a DOS box. DOS MZ Header PE/COFF Header CLR Header IL Metadata

Delving further into a PE file MZ Header PE/COFF Header Definition Tables CLR Header IL Reference Tables Metadata Manifest Tables

bootstrapping the CLR. NET

bootstrapping the CLR. NET • Every managed exe/dll does have one 6 byte piece of x 86 code in it’s. text section – JMP _Cor. Exe. Main or – JMP _Cor. Dll. Main • When the exe runs, the first instruction it encounters is this JMP instruction • The loader looks for _Cor. Exe. Main in the. idata section, and finds that it is in MSCor. EE. dll • MSCor. EE. dll gets loaded into the process’s address space, the loader gets the address of _Cor. Exe. Main and fixes the JMP instruction to reference the function.

Starting up the. NET CLR • The process’s main thread jumps to _Cor. Exe. Main and starts executing • _Cor. Exe. Main initializes the CLR, and looks at the PE file’s CLR header to determine the managed entry point to execute. • The IL code for the entry point is Just-In-Time (JIT) compiled to native instructions, and the CLR jumps to the native code. • At this point, the managed application’s code is running. • Library files (dlls) follow a similar process with _Cor. Dll. Main.

How JIT compilation works

How JIT compilation works public class App { public static void Main() { System. Console. Write. Line("Hello, "); System. Console. Write. Line("C# World"); } } Just before the Main method executes, the CLR detects all types that are referenced by Main’s code. (This is possible because of all the metadata that is built into the type. )

How JIT compilation works • This causes the CLR to allocate an internal data structure that is used to manage access to the referenced type. • This internal data structure has an entry for each method defined by the type. • Before the first call, each method entry points to an undocumented stub function. (Richter calls this JITCompiler) • When Console. Write. Line is invoked for the first time, it hits the JITCompiler function

How JIT compilation works • Inside JITCompiler, – Inside the dll that implements Console, lookup the method Write. Line in the metadata. – From the metadata, get the IL (Microsoft intermediate language) for this method – Allocate a block of memory to hold the native code. – Verify and compile the IL, put the resulting native code into the allocated memory – Modify the internal data structure to point to the allocated block of memory – Jump into it and start executing • The next time Write. Line is invoked, code executes immediately. • Code is JITted every time it is executed – no caching between executions.

How JIT compilation is made more efficient • A JIT compiler can compile to the exact hardware you are running on, not the lowest common denominator (x 86) • A JIT compiler can optimize for multiple CPUs. • Since JIT happens at runtime, the CLR could use branch prediction to compile sections of IL while the application runs • If you are still doubtful, you could use ngen. exe (that ships with the Framework SDK) to precompile code– generally not a good idea

IL and verification • The IL (Microsoft intermediate language) execution engine is stack based – Simple to implement • Since IL is abstract and carries complete metadata, the CLR can perform code verification – No memory is read from without having been written to. – Every method is called with the right number/types of parameters. – Array/string boundaries are not overwritten. – Return values are used properly.

Reverse engineering IL code • Since all. NET executables/dlls are rich in metadata, and contain fairly high level IL, they can be reverse engineered – Using ILDASM to look at IL code is one way – Anakrino – a piece of freeware, does a remarkable job (http: //www. saurik. com/net/exemplar/) • If you are concerned about intellectual property, you can – Use an IL obfuscator – Write unmanaged code and interop with a wrapper.

Packaging code in. NET

Packaging code in. NET • The. NET Framework has some clear-cut goals in terms of deployment/packaging – Reduce, or better, eliminate ‘DLL Hell’ • Differing versions of dlls with the same name overwriting one another, causes application instability. – Reduce installation complexity • Having dozens of locations to copy files to, and dozens of registry entries to create makes installation complex, and uninstallation brittle. – The packaging of code should facilitate security – i. e. let the system decide what a piece of code can do.

Assemblies

Assemblies • • An assembly is the basic unit of deployment in. NET. Every. exe or. dll you build is an assembly. Every assembly follows the PE file format. Unlike traditional exe or dll files, an assembly can consist of more than one file. – These files are called modules

Definition Tables • Module. Def – information that identifies the module • Type. Def – one entry per type defined in the module – Each entry has the type’s name, base type, flags and pointers to entries in other tables for methods, fields, properties and events • Method. Def – one entry per method defined in the module – Each entry has the method’s name, flags, signature and offset • Field. Def – One entry per field defined in the module – Each entry has field name, flags and type

Definition Tables (continued) • Param. Def – one entry per parameter defined in the module – Each entry has name, flags • Property. Def - one entry per property defined in the module – Each entry includes name, flags and type • Event. Def - one entry per event defined in the module – Each entry includes name and flags

Reference Tables • Assembly. Ref – Has one entry for each assembly reference by the module – Contains complete assembly identification info. • Module. Ref – One entry per PE module that implements types referenced by this module – Contains module’s filename and extension • Type. Ref – One entry for each type referenced by the module. – Contains type name and module reference – If the type is implemented in the same module, the module reference indicates a Module. Def entry, else indicates a Module. Ref entry

Reference Tables (continued) • Member. Ref – One entry per member (field, method, property or event) referenced by the module. – Each entry has the member’s name and signature and points to the Type. Ref entry to the type that defines the member.

MSIL Disassembler (Ildasm. exe)

MSIL Disassembler (Ildasm. exe) • The MSIL Disassembler (Ildasm. exe) is included with the. NET Framework SDK. • The Ildasm. exe parses any. NET Framework. exe or. dll assembly, and shows the information in human-readable format. • Ildasm. exe shows more than just the Microsoft intermediate language (MSIL) code — it also displays namespaces and types, including their interfaces. • You can use Ildasm. exe to examine native. NET Framework assemblies, such as Mscorlib. dll, as well as. NET Framework assemblies provided by others or created yourself. • Most. NET Framework developers will find Ildasm. exe indispensable. "C: Program FilesMicrosoft Visual Studio. NET Framework. SDKBinildasm. exe"

ILDASM IL Assembly Code

Let’s analyze the IL code • First, the class public auto ansi beforefieldinit App extends [mscorlib]System. Object { } // end of class App • . class - this defines a class • public – the class is accessible from the outside • auto – the CLR performs autolayout of this class at runtime • ansi – use ANSI string buffers between managed/unmanaged boundaries

Analyzing the IL (continued) • beforefieldinit - Initialize the class any time before first static field access • extends [mscorlib]System. Object – this class derives from the root System. Object class

Analyzing the IL (contd. ) • The Main method private hidebysig static void Main() cil managed {. entrypoint // Code size 21 (0 x 15). maxstack 1 IL_0000: ldstr "Hello, " IL_0005: call void [mscorlib]System. Console: : Write. Line(string) IL_000 a: ldstr "C# World" IL_000 f: call void [mscorlib]System. Console: : Write. Line(string) IL_0014: ret } // end of method App: : Main

Analyzing the IL (continued) • . method – this defines a method • Private – this method is only visible inside this exe • hidebysig – this method hides any method with the same signature higher up in the class hierarchy • static – this method can execute without an instance of the class • cil managed – this is code that defers to the CLR for runtime decisions • . entrypoint – this method is the entry point for the program. • . maxstack – the maximum number of stack slots required is 1 (IL is a stack based language)

Class Exercise

Modules and Assemblies

Modules and Assemblies • Individual module files are not much use unless they are part of an assembly. • Assemblies have the following characteristics: – An assembly is the smallest unit of deployment – An assembly defines the reusable types – An assembly has a version number – An assembly can have security information associated with it. • In order for a PE file to be an assembly, it needs to have a manifest metadata table.

Manifest Tables • Assembly. Def – contains a single entry identifying the module – Name, Version, Culture, Flags, Hash Algorithm and publisher’s public key. • File. Def – contains one entry for each file contained in the assembly – File name, extension, hash value, flags • Manifest. Resource. Def – one entry per resource that is part of the assembly. • Exported. Types. Def – one entry for each public type exported by the assembly • Can see the manifest using ILDASM

Why are multimodule assemblies useful ? • You can move commonly used types into one module, and rarely used typed into another module and build them into an assembly. • If the assembly is downloaded from the Internet, the modules are downloaded only if needed. • Important: Creating multi-module assemblies has to be done by hand. VS. NET does not give you a way to do this.

Assembly Identification • • • All assemblies are identified via a 4 part naming scheme: 1. Assembly Name 2. Assembly Culture 3. Assembly Version 4. Assembly Publisher Information This information gets built into the metadata for the assembly Additional information like trademark, product name, copyright etc. can also be associated with the assembly version resource field.

Assembly Name • The assembly’s name is the same as the filename, without the path and extension. • The compiler automatically does this. • You can see the assembly name in the manifest using ILDASM. assembly hello • You can change the assembly name to be different from the filename, but it is not recommended

Assembly Culture • Assemblies include culture or locale information as part of their identification • Cultures are identified as as string “<pt>-<st>” where <pt> is the primary tag and <st> is the secondary tag. – E. g. “en-US” for US English, “de-CH” for Swiss German • Typically, you would not assign a culture when you build, because the code is not culture specific. In this case, the assembly is culture neutral. • If you do need to build culture-specific info, put those resources into culture specific satellite assemblies. Satellite assemblies should not contain code, and should not be linked to the main assembly – use Reflection instead.

Assembly Version • This is the version that is stored in the Assembly. Def manifest metadata table. (Remember that ? ). Referred to as Assembly. Version – Four part version number: • major. minor. build. revision • E. g. 1. 0. 3300. 0 • There are two other versions – Assembly. File. Version – stored in the Win 32 version resource. Ignored by the CLR – Assembly. Informational. Version. Attribute – exists to indicate the version of the product that includes the assembly. Ignored by the CLR

Version rules • You have to at least specify major • If you specify major and minor, you can specify an asterisk (*) for build. This will cause build to be equal to the number of days since January 1, 2000 local time, and for revision to be equal to the number of seconds since midnight local time, modulo 2. • If you specify major, minor, and build, you can specify an asterisk for revision. This will cause revision to be equal to the number of seconds since midnight local time, modulo 2. • Examples – – – 1. 0. 34. 56 1. 2. * 1. 0. 25. * 1 (same as 1. 0. 0. 0) 1. 4 (same as 1. 4. 0. 0) - Empty (defaults to 0. 0)

How to specify an assembly’s identity and version info • Use custom attributes available in the System. Reflection namespace. • Set the attributes at the assembly level • Examples using System. Reflection; … [assembly: Assembly. Culture(“en-US”)] [assembly: Assembly. Version(“ 1. 2. 3. 4”)] [assembly: Assembly. Company(“Joe’s Software Shack”)]

VS. NET and Assembly. Info. cs • VS. NET automatically creates a file to hold all the assembly information – Assembly. Info. cs • You can change the default values in here to suit your needs • One insidious default value: [assembly: Assembly. Version("1. 0. *")] – What does this do ? – If you care about the build numbers and/or revisions, change this.

Simple Application Deployment • Assemblies don’t dictate a special means of packaging. • Easiest way to deploy is to copy all the files to the target machine. (xcopy deployment) • Since the assembly has all the dependant assembly information in its metadata, the application will just run, and look for other user defined assemblies in the same folder. • No registry entries to create/clean up. • Assemblies deployed in this manner are called privately deployed assemblies.

Deploying in subdirectories • What if you wanted to deploy dependant assemblies in their own subdirectories ? • . NET allows you to do this via configuration files. • Configuration files in. NET are XML files • Application config files for executable applications (EXEs) are always named <appname>. exe. config and are placed in the application’s base directory.

Example application config file <? xml version="1. 0" encoding = "utf-8" ? > <configuration> <runtime> <assembly. Binding xmlns="urn: schemas-microsoft-com: asm. v 1"> <probing private. Path="bar" /> </assembly. Binding> </runtime> </configuration>

App. exe. config • The previous example says that if the dependant assembly is not found in the base directory, look in a subdirectory called “bar” • Good idea to cut and paste these files from existing config files, and edit them to fit your situation. • private. Path can contain multiple semicolondelimited paths. • If you are doing this with VStudio, name the file App. config and add it to your project. The IDE takes care of generating the <application name>. exe. config file in the appropriate bin directory

Probing and private. Path • Probing is a fancy word for searching • If your application is looking for an assembly called My. Asm. dll, the probe paths are as follows: – – – <App. Base. Dir>My. Asm. dll <App. Base. Dir>private. Path 1My. AsmMy. Asm. dll … • For satellite assemblies , the probing starts at <App. Base. Dir><culture> – <App. Base. Dir>en-USMy. Asm. dll – …

Probing • private. Path can only specify subdirectories. Siblings and parents/ancestors cannot be used. • Application specific config settings can always be overridden by the administrator in the machine wide Machine. config file located at – C: WindowsMicrosoft. NETFrameworkversionCONFIG • Config files can be created by a GUI tool – the Microsoft. NET Framework Configuration Tool (in Control Panel->Administrative Tools) – Under Application, select Add an Application To Configure – Easier to just cut and paste and edit by hand

Shared Assemblies

Shared Assemblies • With private deployment, every application gets it’s own copy of dependant assemblies. • We also need a way for multiple applications to share assemblies. – E. g. the assemblies that ship with the. NET Framework that implement the FCL – Exception classes that you may implement that are shared by various applications on a machine • Assemblies that are shared by multiple applications are called shared assemblies.

The problems with sharing • Shared libraries are not new, but have had their host of problems, mostly related to versioning • Version 1 of a piece of code is overwritten by Version 2, where code has been modified. – Now any application built with Version 1 of the code is no longer guaranteed to work. – Mfc 42. dll is a prime example • COM tried fixing this by immutable interfaces and registry entries, but this was easily abused. • Led to DLL Hell, and the common (and largely accurate) notion that a Windows NT installation degrades over time.

The crux of the problem • How do you fix bugs and add features to a file and also guarantee that dependant applications do not break ? • Can you run various versions of the shared files side-by-side ? • Can un-installing a shared file be made clean ?

The. NET solution • . NET supports two kinds of assemblies – Strongly named assemblies – Weakly named assemblies (Richter’s term) • Both types of assemblies are structurally identical – PE files as described earlier • Strongly named assemblies have some more information in the metadata and CLR header to help in identification. • Both strongly and weakly named assemblies can be privately deployed. • Only strongly named assemblies support global (or shared) deployment.

A brief digression… • Most crypto-systems fall into one of 2 categories – Symmetric key encryption – Asymmetric key encryption • Symmetric key encryption uses the same key to encrypt and decrypt – Symmetric keys are easy to implement. – Safety depends on key length – Key exchange can be compromised (Remember, both sender and receiver need to know the same key).

Asymmetric Key Encryption • The key is in 2 parts – A public key which is well known – A private key, which only one party knows. • Message encryption – If you (sender) want to send an encrypted message to a receiver, you encrypt the message with the receiver’s public key (which is well known). – The receiver can decrypt the message with the private key (which only the receiver knows). – Messages intended for the receiver can only be read by the receiver • The key exchange problem goes away

Digital Signing • Asymmetric key encryption has an interesting side -effect – If the sender signs a message with his/her private key (which only the sender knows), the receiver can decrypt the message with the sender’s public key (which is well known). – This serves not to protect the message, but to confirm the sender’s identity. – Known as a digital signature.

Strong names

Strong names • • Strong names are digital signatures that are added to an assembly. A strongly named assembly has 4 attributes that uniquely identify it. 1. Filename (without the extension) 2. Version (M. m. B. R) 3. Culture 4. Public key token We’ve already seen the first 3. With asymmetric key encryption, one of the disadvantages is that the keys are fairly large. A public key token is a one way hash of the public key that is much smaller.

Strong names (continued) • Example – “My. Asm, Version=1. 2. 3. 4, Culture=neutral, Public. Key. Token=b 77 a 5 c 561934 e 089” • Any company that wants to uniquely mark it’s assemblies must get a public/private key pair. • No two companies can have the same public/private key pair (similar to GUIDs. ) • A strongly named assembly is signed with the publisher’s private key.

SN. exe • The. NET Framework SDK provides the Strong Name Utility (SN. exe) to create and use key pairs. • To generate a public/private key pair: sn –k My. Public. Private. Keys. keys – Notice that this is a binary file. • To extract the public key portion: sn –p My. Public. Private. Keys. keys My. Public. Key • To view the public key and public key token: sn –tp My. Public. Key

Some caveats • sn does not validate the input file. sn –tp junk. txt The above will print out values that look like a public key and token. • Larger companies may use key containers rather than SN to generate key pairs. • The public key is 128 bytes. • The public key token is 8 bytes.

Signing an assembly • To sign an assembly, use the Assembly. Key. File attribute. [assembly: Assembly. Key. File(“My. Public. Private. Keys”)] • Ildasm now shows you a public key in the manifest assembly def. • Any other assembly that is now built with a reference to the signed assembly will have the dependant assembly’s public key token in the assembly ref.

What happens when you sign as assembly? • When you build a strongly named assembly, the assembly’s File. Def manifest metadata table includes a list of all files that make up the assembly. • As each file is added, the file’s contents are hashed and this hash value is stored along with the file’s name in the File. Def table. • After the PE file containing the manifest is built, the entire contents are hashed (with the SHA-1 algorithm). • The hash value is digitally signed with the publisher’s private key and stored in a reserved section of the PE file. • The publisher’s public key is embedded into the Assembly. Def manifest metadata table.

Signing an assembly My. Asm. dll Sign with private key IL Hash value Hash PE file Metadata Manifest Public Key CLR Header RSA digital signature Public Key RSA digital signature

Some other facts on signing • sn –Tp My. Asm. dll – Can be used to display the public key and public key token of a signed assembly • sn –v My. Asm. dll – Can be used to verify if an assembly has been signed • Only the PE file containing the manifest has the public key stored in it.

The Global Assembly Cache

The Global Assembly Cache • Once we have a shared assembly, we need to put it some well known place where the CLR can find it and load it. • This well known location is the Global Assembly cache (or the GAC). • To look at the GAC through Windows Explorer, navigate to C: WindowsAssembly Or it’s equivalent.

The GAC

The GAC • This view of the GAC is possible due to an Explorer shell extension (Sh. Fusion. dll) that gets installed when you install the. NET Framework. • You can see the assembly name, version, culture and public key token. • You can right click and check out the properties on the assembly, including version information

The GAC • To see the real structure of the GAC, open up a command window and navigate to it. – C: WindowsassemblyGAC • Note that under each assembly are folders with names that include both the assembly version and the public key token • The format of the directory name is <Version>_<Culture>_<Public. Key. Token> • The GAC can hold multiple versions of assemblies, and applications will only run with the version they were built with • The public key token deals with the case where assemblies published by different publishers have the same name.

Installing assemblies into the GAC • Once the assembly has a strong name, it can be installed in the GAC in one of two ways: – Drag and drop using the Windows shell extension. – Using the Global Assembly Cache utility (GACUTIL. exe) on the command line. – Both techniques will flag you with an error if you try and install an assembly that has not been strongly named. – If you use the Windows shell extension, uninstalling is simply a matter of deleting from Windows explorer.

GACUTIL • Allows you to view and manipulate the contents of the global assembly cache. • The following command inserts the file mydll. dll into the global assembly cache. gacutil /i mydll. dll • The following command removes the assembly hello from the global assembly cache. gacutil /u hello – Note that the previous command might remove more than one assembly from the assembly cache because the assembly name is not fully specified. For example, if both version 1. 0. 0. 0 and 3. 2. 2. 1 of hello are installed in the cache, the command gacutil /u hello removes both of the assemblies. Also, note that the file extension (. dll) is not used

GACUTIL (contd. ) • Use the following example to avoid removing more than one assembly. This command removes only the hello assembly that matches the fully specified version number, culture, and public key. gacutil /u hello, Version=1. 0. 0. 1, Culture=”de”, Public. Key. Token= 45 e 343 aae 32233 ca • The following command lists the contents of the global assembly cache. gacutil /l

Strong Named Assembly Class Exercise

Assemblies that reference strongly named assemblies • Whenever you build an assembly, the assembly will have a reference to other strongly named assemblies. Why ? – Because System. Object is defined in MSCor. Lib. dll • When compiling references to other strongly named assemblies, you should not have to specify a full path all the way into the GAC in your /r: option. • For this reason the. NET Framework installs two copies of the Microsoft assemblies – one set in the GAC (to be loaded at runtime) and one set in the CLR directory that the compiler uses (to be used for compile time references. )

What does strong naming buy us ? • When a strongly named assembly is installed in the GAC, the following steps take place – The system hashes the contents of the file containing the manifest, and obtains a hash value (H 1) – The system extracts the publishers public key, and uses it to unsign the RSA digital signature embedded in the PE file, obtaining the original hash value (H 0) – If H 0 is not the same as H 1, the file has been tampered with.

What does strong naming buy us ? • When a strongly named assembly is installed in the GAC, the following steps take place (continued) – In addition, for a multi-module assembly, the system hashes the contents of the assembly’s other files and compares them with the hash values stored in the manifest file’s File. Def table. If any hash value does not match, the assembly has been tampered with. – If the assembly has been tampered with, it will not install into the GAC

Binding to an assembly • When an app needs to bind to an assembly, it uses the following info in the Assembly. Ref table – Name, version, culture, public key token to locate the assembly in the GAC. • If it can be found, it is loaded. If it is found, we know it has not been tampered with, and is the same version of the assembly that the app was built against. • If is not found in the GAC, the CLR looks in the app’s base directory and probes, as described earlier. • If it is still not found, a File. Not. Found. Exception is thrown.

An important caveat • Strong naming only guarantees that the file was not tampered with after being signed. • A malicious party could change the assembly and resign it (with their own private key. ) • The publisher’s identity cannot be known from the key alone – you need to use Authenticode to do this.

Internet Deployment • Strongly named assemblies can be deployed at a URL. • The application configuration file for an application using such an assembly can use a CODEBASE directive to specify location, version, culture, name and public key token of the assembly. • The assembly runs out of an Internet download cache. • The CLR compares the hash values everytime the assembly is loaded – a potential performance hit.

Using CODEBASE <? xml version="1. 0" encoding = "utf-8" ? > <configuration> <runtime> <assembly. Binding xmlns="urn: schemas-microsoft-com: asm. v 1"> <dependent. Assembly> <code. Base version="0. 0" href="http: //localhost/asslydep/math. dll" /> <assembly. Identity name="math" public. Key. Token="05171503206 bc 67 f" culture="neutral"/> </dependent. Assembly> </assembly. Binding> </runtime> </configuration>

Binding to an Assembly 1. CLR applies all the configuration policies. 2. If the required assembly is already loaded, use it. 3. Is there a match in the GAC ? If so, load that file and use it 4. Is there a CODEBASE hint, and does it match the reference ? If so, load that file and use it

Binding to an Assembly (continued) 5. Can the file be found in by probing ? a. Look in the application’s base directory, and a subdirectory with the same name as the assembly. b. Probe the directories specified by private. Path c. Continue probing through culturedependant folders. 6. If it is still not found, throw a System. IO. File. Not. Found. Exception

Some observations • The GAC is the first place the CLR looks – If you have the assembly both in the GAC and in the application base directory, the one in the GAC will be used • When you use a codebase with a URL, the assembly is run from a download directory. – If you do not change the version, the cache will need to be cleared to force a download.

To find where an assembly is running from • You can reflect on the Type object to figure out where the assembly that defines the type was loaded from typeof(<typename>). Module. Fully. Qualified. Name • This returns a string with the full path.

Homework Monday December 8, 2003 Guest. Book Database with a Visual Basic. NET Windows Form