Assemblies

Assemblies are the fundamental units of deployment, version control, reuse,

activation scoping, and security permissions for .NET-based applications. An
assembly is a collection of types and resources that are built to work together
and form a logical unit of functionality. Assemblies work as a building block in
a .NET application. All the resources needed by an application are contained in
an assembly, such as classes, structures, interfaces, and so forth. An assembly
is automatically created whenever a developer creates a new Windows app,
web service, or class library. This assembly can be either a DLL (Dynamic
Link Library) or an EXE (Executable file).
An assembly can be a single file or it may consist of the multiple files. In .NET
Framework, you can build an assembly from one or more source code files. In
.NET Framework, assemblies can contain one or more modules. This way,
larger projects can be planned so that several developers can work on separate
source code files or modules, which are combined to create a single assembly.
 Properties of Assemblies
• Assemblies are implemented as .exe or .dll files.
• For libraries that target .NET Framework, you can share assemblies between applications by
putting them in the global assembly cache (GAC). You must strong-name assemblies before
you can include them in the GAC.
• Assemblies are only loaded into memory if they're required. If they aren't used, they aren't
loaded. Therefore, assemblies can be an efficient way to manage resources in larger
projects.
• Depending upon the creation, assemblies are classified into two namely static and
dynamic. 1) Static Assembly created when we compile our code using the compiler. 2)
Dynamic Assembly created during runtime.
• It also consists of assembly metadata which is known as Assembly Manifest. Information
about the assembly version, resources needed by the assembly, and the scope of the
assembly is stored in the manifest file.
• You can load an assembly just to inspect it by using the MetadataLoadContext class on
.NET Framework.
 Information contained in Assemblies
•Code that the common language runtime executes.
•The security boundary. An assembly is the unit at which permissions are requested and granted.
•The type boundary. Every type's identity includes the name of the assembly in which it resides. A type
called MyType that's loaded in the scope of one assembly isn't the same as a type called MyType that's loaded in
the scope of another assembly.
•The reference-scope boundary: The assembly manifest has metadata that's used for resolving types and
satisfying resource requests. The manifest specifies the types and resources to expose outside the assembly and
enumerates other assemblies on which it depends. MicroSoft Intermediate Language (MSIL) code in a portable
executable (PE) file won't be executed unless it has an associated assembly manifest.
•The version boundary. The assembly is the smallest versionable unit in the common language runtime. All types
and resources in the same assembly are versioned as a unit. The assembly manifest describes the version
dependencies you specify for any dependent assemblies.
•The deployment unit: When an application starts, only the assemblies that the application initially calls must be
present. Other assemblies, such as assemblies containing localization resources or utility classes, can be retrieved
on demand. This process allows apps to be simple and thin when first downloaded.
•A side-by-side execution unit.
 Create an assembly
• Assemblies can be static or dynamic. Static assemblies are stored on a disk
in portable executable (PE) files. Static assemblies can include interfaces,
classes, and resources like bitmaps, JPEG files, and other resource files. You
can also create dynamic assemblies, which run directly from memory and
aren't saved to disk before execution. You can save dynamic assemblies to
disk after they've been executed.
• There are several ways to create assemblies. You can use development tools,
such as Visual Studio that can create .dll or .exe files. You can use tools in
the Windows SDK to create assemblies with modules from other
development environments. You can also use common language runtime
APIs, such as System.Reflection.Emit, to create dynamic assemblies.
• Compile assemblies by building them in Visual Studio, building them with
.NET Core command-line interface tools, or building .NET Framework
assemblies with a command-line compiler.
 Types of Assemblies
.NET supports three kinds of assemblies:
• Private Assembly: It is accessible by a single application. Private assembly requires us to copy
separately in all application folders where we want to use that assembly’s functionalities; without
copying, we cannot access the private assembly features and power. Private assembly means every
time we have one, we exclusively copy into the BIN folder of each application folder.
• Public Assembly: It is accessible by multiple applications. Public assembly is not required to copy
separately into all application folders. Public assembly is also called Shared Assembly. Only one
copy is required in system level, there is no need to copy the assembly into the application folder.
Public assembly should install in GAC. Shared assemblies (also called strong named assemblies) are
copied to a single location (usually the Global assembly cache). For all calling assemblies within the
same application, the same copy of the shared assembly is used from its original location. Hence,
shared assemblies are not copied in the private folders of each calling assembly. Each shared assembly
has a four-part name including its face name, version, public key token, and culture information. The
public key token and version information makes it almost impossible for two different assemblies with
the same name or for two similar assemblies with a different version to mix with each other.
• Satellite Assembly: Satellite assemblies are used for deploying language and culture-specific
resources for an application.
 What are the Features of .NET Assembly?
•Tracking the version dependencies
•Installing an assembly is much easier than copying the file that contains the assembly
•Assemblies can be shared or private
•All of the information of an assembly is packed-up into the assembly itself
Structure of an Assembly in .NET
Four components that make up an assembly are:
•Assembly Metadata
•Microsoft Intermediate Language (MSIL)
•Type Metadata
•Resources
What is Assembly Metadata?
The information about the assembly is called assembly metadata. It is also known as an assembly
manifest. Assembly metadata contains the following information:
• The assembly’s name
• Version number
• Digital signature that uniquely identifies an assembly’s creator.
• All files which build up the assembly
• Information regarding all of the referenced assemblies.
• Information of all the exported classes, methods, properties, and other items.
What is Microsoft Intermediate Language (MSIL)?
MSIL plays a key role in making the .NET a language-neutral technology. Whenever you run the .NET
application, the code is compiled down to the same MSIL, no matter what programming language is used. It is
the MSIL that makes .NET capable of running independently. With the magic of MSIL, it becomes possible to
enable programmers to “write once, run anywhere”.
What is Type Metadata?
The type of an assembly is described by its type metadata. The resources and types that are publicly accessible
are also called type metadata. The items, such as image files and other items required by the application, are
referred to as resources.
Resources
Resources in .NET assembly can be easily placed from the assembly itself or an external resource. The process
of accessing resources within an assembly is very straightforward. There are some important classes for dealing
with the resources within an assembly. They are listed below:
• ResourceManager: A program within an assembly used to access and manage available resources.
• ResourceWriter: A program to write resource information to an external source.
• ResourceReader: A program within an assembly that reads the material from different resources, including
the Internet.
 Monolithic applications
If all the functionalities of a project exist in a
single codebase, then that application is
known as a monolithic application. We all
must have designed a monolithic application
in our lives in which we were given a problem
statement and were asked to design a system
with various functionalities. We design our
application in various layers like presentation,
service, and persistence and then deploy that
codebase as a single jar/war file. This is
nothing but a monolithic application,
where “mono” represents the single codebase
containing all the required functionalities.
 Advantages of monolithic applications
• Simple to develop relative to microservices, where skilled developers
are required in order to identify and develop the services.
• Easier to deploy as only a single jar/war file is deployed.
• Relatively easier and simple to develop in comparison to
microservices architecture.
• The problems of network latency and security are relatively less in
comparison to microservices architecture.
• Developers need not learn different applications, they can keep their
focus on one application.
 Disadvantages of Monolithic applications
• It becomes too large with time and hence, difficult to manage.
• We need to redeploy the whole application, even for a small change.
• As the size of the application increases, its start-up and deployment time also increases.
• For any new developer joining the project, it is very difficult to understand the logic of a
large Monolithic application even if his responsibility is related to a single functionality.
• Even if a single part of the application is facing a large load/traffic, we need to deploy
the instances of the entire application in multiple servers. It is very inefficient and takes
up more resources unnecessarily. Hence, horizontal scaling is not feasible in monolithic
applications.
• It is very difficult to adopt any new technology which is well suited for a particular
functionality as it affects the entire application, both in terms of time and cost.
• It is not very reliable, as a single bug in any module can bring down the entire
monolithic application.
 Component-Based Application
Component-based applications consist of
several pieces of software, which are
executed independently and may reside on
the same host or on remote host over a
network (such as intra-/extra-/internet).
For such a component-based application to
work, the components must be able to
interoperate, i.e. to exchange data and
issue method calls to each other via the
component’s defined interface.
Component based applications work based
on microservice architecture.
 Microservices

It is an architectural development style in which the application is made

up of smaller services that handle a small portion of the functionality
and data by communicating with each other directly using lightweight
protocols like HTTP. According to Sam Newman, “Microservices are
the small services that work together.”
The Microservice architecture has a significant impact on the
relationship between the application and the database. Instead of sharing
a single database with other microservices, each microservice has its
own database. It often results in duplication of some data, but having a
database per microservice is essential if you want to benefit from this
architecture, as it ensures loose coupling. Another advantage of having a
separate database per microservice is that each microservice can use the
type of database best suited for its needs. Each service offers a secure
module boundary so that different services can be written in different
programming languages.
 Principles of Microservices
• Single responsibility: It is one of the principles defined as a part of the SOLID design pattern. It
states that a single unit, either a class, a method, or a microservice should have one and only one
responsibility. Each microservice must have a single responsibility and provide a single
functionality. You can also say that: the number of microservices you should develop is equal to the
number of functionalities you require. The database is also decentralized and, generally, each
microservice has its own database.
• Built around business capabilities: In today’s world, where so many technologies exist, there is
always a technology that is best suited for implementing a particular functionality. But in monolithic
applications, it was a major drawback, as we can’t use different technology for each functionality and
hence, need to compromise in particular areas. A microservice shall never restrict itself from
adopting an appropriate technology stack or backend database storage that is most suitable for
solving the business purpose, i.e., each microservice can use different technology based on business
requirements.
• Design for failure: Microservices must be designed with failure cases in mind. Microservices must
exploit the advantage of this architecture and going down one microservice should not affect the
whole system, other functionalities must remain accessible to the user. But this was not the case in
the Monolithic applications, where the failure of one module leads to the downfall of the whole
application.
 Advantages of Microservices
• It is easy to manage as it is relatively smaller.
• If there’s any update in one of the microservices, then we need to redeploy only that
microservice.
• Microservices are self-contained and, hence, deployed independently. Their start-up and
deployment times are relatively less.
• It is very easy for a new developer to onboard the project as he needs to understand only a
particular microservice providing the functionality he will be working on and not the whole
system.
• If a particular microservice is facing a large load because of the users using that
functionality in excess, then we need to scale out that microservice only. Hence, the
microservices architecture supports horizontal scaling.
• Each microservice can use different technology based on the business requirements.
• If a particular microservice goes down due to some bug, then it doesn’t affect other
microservices and the whole system remains intact and continues providing other
functionalities to the users.
 Disadvantages of Microservices
• Being a distributed system, it is much more complex than monolithic
applications. Its complexity increases with the increase in a number of
microservices.
• Skilled developers are required to work with microservices architecture,
which can identify the microservices and manage their
inter-communications.
• Independent deployment of microservices is complicated.
• Microservices are costly in terms of network usage as they need to interact
with each other and all these remote calls result in network latency.
• Microservices are less secure relative to monolithic applications due to the
inter-services communication over the network.
• Debugging is difficult as the control flows over many microservices and to
point out why and where exactly the error occurred is a difficult task.