11 June 2015CSE3210: Lecture 7-->121 A (Somewhat) Deeper Look at.NET Components CSE3210: Software Component Technology Lecture 7 12 Dan Eaves

April 18, 2023 CSE3210: Lecture 7-->12 1

A (Somewhat) Deeper Look at .NET Components

CSE3210:Software Component Technology

Lecture 712Dan Eaves

Haven’t we been here before?

• Yes!

• The purpose of this lecture is to take a deeper look at the material originally presented in Lecture 7


The Microsoft Distinction between Component and Control Isn’t Universal – and Is Dying

• We have a historical accident built into programming language evolution – controls were written in a language that didn’t allow their use

• This actually isn’t all that unusual• Our nomenclature and design errors tend to stay

with us, like the QWERTY keyboard – it’s just too much of a hassle to change

• So, while we distinguish between classes and components, the distinction isn’t critical


Another Distinction We Need to Keep in Mind: Passing variables by value or reference

• Here VB differed from other languages– Variable names were kept in an index containing

• The name in standard form• The address in RAM of the current value

– Variables could be passed by Ref (name) or Value – The default was Ref!

• And great was the incompatibility with C and C++• And difficult indeed was the use of the API!

• A primary purpose in .NET was to eliminate such incompatibilities



Characteristics of Components

• We started with a working definition:– Multiple-use– Non-context-specific– Composable with other components– Encapsulated i.e., non-investigable through its

interfaces– A unit of independent deployment and

versioning

• Wikipedia, “Software Componentry”, 4 September, 2005, from Szyperski and Messerschmitt


We Can Also Use a More Technical List

• Löwy’s Principles of Component-Oriented Programming– Separation of interface and implementation– Binary compatibility– Language independent– Location transparency– Concurrency management– Version control– Component-based security

• Juval Löwy, Programming .NET Components, 2nd ed. O’Reilly, 2005


Separation of Interface and Implementation

• (Note that we are using interface to refer to how two quasi-independent chunks of program relate to each other.)

• “An interface is a logical grouping of method definitions that act as the contract between the client and the service provider.”– Note that a property is logically part of a method to

create an object on a form– The component

• Is in binary form• Is completely insulated from the client – black box• Can be changed without the client knowing because the

interface remains unchanged

Separation of Interface and Implementation 2

– The unit of use is the component’s interface, not an element of any class library therein.

– But the component will probably be made out of instances of classes, as well as additional code

– There should be a higher level of abstraction, and a lower granularity

– These are advantages to the programmers and to no one else!



Binary Compatibility

• Components have to maintain their interfaces across releases– The newly compiled version of the component must

continue to support the contract expressed by the interface.

– The client can continue to use the component without• Revision• Recompilation

– Ideally, component replacement should be possible while the client is running.

Note that this is not a solution to DLL Hell. Indeed, it describes DLL Hell rather precisely!


Language Independent

• The client neither knows or cares about the language in which the component is written

– Note: A characteristic of controls since the original VBXs in 1991.

– However, the environment must be compatable

• Language independence implies no constrictions on the type of language used in development (OO, procedural, declarative, functional, etc.) as long as the interface (which will support OO use) works, BUT…


Language Independent 2

• With .NET, MIL is required! That is, C#, C++, Eiffel, etc. can be used to create the component, but,

• Binary compatibility requires MIL, at some stage, so components must have be compiled using the CLR’s JIT compiler

• When the using component is fully compiled, the component’s assembly metadata is available so the necessary data is available to the CLR’s compiler


Location Transparency

• The client should not have to know or care where the component is located– Follows the Web model – the facility to discover

location is present, but that location isn’t known• By the requesting browser/page• By the supplied page

• The is good because:– You can develop the component on the same

machine as a client, which makes development and testing much easier

– You can locate multiple copies of the component as necessary to meet load requirements

– You can reconfigure the host facilities without worrying about component locations.


Location Transparency 2

• But what of DLL Hell?

• At least in the short term, component distribution is a theoretical, rather than an actual, advantage.

• This implies that a lot more work on versioning is necessary.


Concurrency Management

• The component developer can’t know– Exactly how clients will use the component– Whether multiple threads will access the component

concurrently

• This implies that components should – Support multi-threading– Provide load-balancing services

• (Hummmmm. This is a heavy programming requirement, which the earlier items in the list aren’t !)

– “…the underlying component technology should allow components and clients to provide their own synchronization solutions for fine-grained control and optimized performance.”

• Gulp!


Concurrency Management 2

• This adds a level of complexity to all .NET component development.

• One has to assume that, eventually, somewhere, your gizmo will have to support concurrency.

• Concurrency is no longer in any way optional


Version Control

• Both components and their clients will evolve separately– New versions of clients should work with old versions

of components– Old versions of clients should work with new versions

of components

• It is the component’s responsibility to notify the user of likely problems

• DLL Hell shows us how important intelligent and comprehensive version control really is.


Version Control 2

• Private components can readily be made relatively safe. One copy per application…

• Shared components are harder– .Net 2 (VS 2005) outlines a number of mechanisms to

cope with possible version problems.– There is a heavy reliance on metadata at a number of

levels.

• I am sceptical, – We have evolving versions of applications– We have evolving versions of components– We have multiple versions of components and

applications, and of .NET itself…


Component-based security

• Löwy argues that components must take responsibility to eliminate possible misuse.

• I find it hard to imagine the form such security might take.

• This is the one of Löwy’s principles I have to, at least for now, disagree with. There are an infinite number of misuses possible…


Underlying These Principles Is the Failure of OO Reuse

• Two of the main reasons for this are– The fine granularity of most classes and– The availability of inheritance

• The results are custom extensions rather than simple reuse.– This further complicate the class library structures– Further extends the structures beyond human

cognitive limitations.• (Note: This means that most people have a hard time

learning and using such structures, not that their learning and use is impossible.)


DLL Hell Revisited

• Components were entered into the Registry and placed in the System or System32 directory– This means there was only one definitive copy, no matter how

many programs used, and so tried to install, the component.– The Registry incremented a counter each time a program tried to

install a component and decremented it with each uninstall via the Control Panel

– All components were suppose to be upwardly compatible

• With different programs adding different versions of components when being installed,it was possible for the installation of ProgramFred to make ProgramGeorge stop running. Infrequent, but very hard to debug.


Pain versus Power (After Löwy, p. 20)

Skill

Application Functionality

C++ MFC ATL COM

.NET

VB 6


Containers and What’s Contained

• The standard VS.NET application is contained in a solution.

• A solution can contain one or more projects.• Each project in a solution can be written in a

different language.• The theory is that different languages are better

for different tasks.• In practice this supports

– Evolution, from VB and C++ to C#– Reuse of existing toolkits (code modules in VB)– (Creation of simpler languages and IDEs to fill the role

formerly occupied by VB?)


Containers and What’s Contained 2

• All parts of a solution are compiled into Microsoft Intermediate Language (IL)

• The Common Language Runtime (CLR), inter alia, compiles the IL into processor specific machine language. Note that this in theory allows environment-specific performance tuning

• The CLR has access to metadata at all levels for the different parts being built into a system. It can also add metadata to components which, while not being compiled into the solution, will be used by it.


A Solution Also Can be Compiled into One or More Components

• Will have either a .DLL or .EXE suffix• Will have public variables which are the

properties of components.• Will have default values for most of those

variables/properties.• Can produce the shells for the code to make use

of the methods in the component, • e.g., the events the component knows how to catch and

respond to.

• Will have metadata• Will have security


Assemblies

• The basic packaging unit of .NET• Handles

– Deployment– Versioning– Security

• Can contain multiple .DLLs and/or .EXEs, each with its interface

• “Think of an assembly as a logical library, a metafile that can contain more than one physical file.” (Löwy)


Just to Confuse Things

• A one or more DLLs/EXEs (each being one or more components) in an assembly can be called a module– But in VB.NET modules are .vb files with no form description, and are

widely used for reusable routines, functions, etc. Drat!

• While an assembly can contain more than one module, that goes against the standard.

• A DLL assembly is called a library assembly and an EXE assembly an application assembly. The distinction between the two is greatly reduced in .NET 2– When developing new components, you can make

reference to both kinds of assembly


Remember, Components Are Binary• How do we (and the components themselves)

know about the component(s) in an assembly.• Metadata to the rescue• The process of reflection allows the

programmer (and the component itself) to find out– The types, structures, classes, interfaces etc.– The methods, the methods parameters, etc.– The public properties, etc.

• Metadata is created automatically in the compilation to IL. It can also be added to by program, and the programmer


Metadata

• Data about data• In a relational DB, the metadata is held in a table

that records– All other tables in the database– Each field in the database– The queries which have been created and stored,

with optimisation.

• Metadata, however, isn’t limited to DBMS• You can create and store metadata about

anything.


More Jargon: Marshalling

• There is no requirement that a component reside on the same computer as a program that is using it.

• Marshalling refers to the process of finding out where a necessary component resides and making it available via a proxy.– The program interacts with the proxy– The proxy interacts with the component– The process is transparent to the application program

(and programmer)


Marshalling 2

• This can also be called serialization. – The data/app/whatever is organised into a single,

unbroken string of bytes. – This can be reconstructed into the identical shape it

had prior to the process starting.

• Marshalling may take the form of serializing the and providing it to the requesting app, in complete form, instead of establishing proxy access.


The Manifest• (Could be described as meta-metadata.)• Metadata relates to the details within each

assembly (types, etc.)• The manifest relates to the assembly as a

whole– This is information relating to each assembly as a unit– Contains, for example, security settings (including

names and hashes of each file) version numbers, etc.– We will get more deeply into this later

• At a minimum, an assembly contains– One chunk of IL DLL or EXE code– Metadata – A manifest


A Note on the Building of IL

• The code in this form contains hooks for where chunks of memory are going to be needed for anything.

• The JIT compiler in the CLR does the actual memory allocation, only when machine code is being generated.

• This means that binary compatibility across versions of components is simplified, because the binaries (IL) don’t ever refer to memory locations, either relative or absolute.

• Again, we will return to this point later


When Actually Compiling

• The JIT compiler notes hooks, requirements for storage space, etc. and puts them all together.

• All memory control, access and use is compiler-created: No programmer’s pointers, no programmatic access to memory.

• Takes care of all garbage collection, guaranteeing absence of memory leaks.

• (Never a problem with VB, which did its own garbage collection.)

Documents

11 June 2015CSE3210: Lecture 7-->121 A (Somewhat) Deeper Look at.NET Components CSE3210: Software Component Technology Lecture 7 12 Dan Eaves