What Are .Net Assemblies

What are .NET Assemblies?

In more simple terms: A chunk of (precompiled) code that can be executed by the .NET runtime environment. A .NET program consists of one or more assemblies.

What exactly is an Assembly in C# or .NET?

An assembly is the compiled output of your code, typically a DLL, but your EXE is also an assembly. It's the smallest unit of deployment for any .NET project.

The assembly typically contains .NET code in MSIL (Microsoft Intermediate language) that will be compiled to native code ("JITted" - compiled by the Just-In-Time compiler) the first time it is executed on a given machine. That compiled code will also be stored in the assembly and reused on subsequent calls.

The assembly can also contain resources like icons, bitmaps, string tables and so on. Furthermore, the assembly also contains metadata in the assembly manifest - information like version number, strong name, culture, referenced assemblies and so forth.

In 99% of your cases, one assembly equals a physical file on disk - the case of a multi-file assembly (one assembly, distributed across more than a single file) appears to be a rather odd-ball edge case which I've never encountered so far in my 5+ years of .NET development.

In a multifile assembly there would still be only one assembly manifest in a DLL or EXE and the MSIL code in multiple netmodule files.

What are assemblies?

Most of your questions are for c# so here is the link for .net Assembly

In the .NET framework, an assembly is
a compiled code library for use in
deployment, versioning and security.
There are two types: process
assemblies (EXE) and library
assemblies (DLL). A process assembly
represents a process which will use
classes defined in library assemblies.
.NET assemblies contain code in CIL,
which is usually generated from a CLI
language, and then compiled into
machine language at runtime by the CLR
just-in-time compiler.

Difference Between Assembly and DLL

An assembly is .NET's "minimum unit of deployment". Usually an assembly corresponds to a single file, but it doesn't have to - you can have multiple files, with one of them being the master which knows where all the other bits are.

Single-file assemblies are usually DLLs or EXE files. If you've got a normal class library and you just want to send it to the other side, the DLL is what you want. I'd only worry about more complicated scenarios as and when you run into them :)

.NET Module vs Assembly

Every assembly has at least one module. It is an implementation detail that's highly invisible. But you can see it when you use Reflection.Emit. From the sample code for the AssemblyBuilder class:

AssemblyName aName = new AssemblyName("DynamicAssemblyExample");
AssemblyBuilder ab = 
    AppDomain.CurrentDomain.DefineDynamicAssembly(
        aName, 
        AssemblyBuilderAccess.RunAndSave);

// For a single-module assembly, the module name is usually
// the assembly name plus an extension.
ModuleBuilder mb = 
    ab.DefineDynamicModule(aName.Name, aName.Name + ".dll");

TypeBuilder tb = mb.DefineType(
    "MyDynamicType", 
     TypeAttributes.Public);

Note the use of the ModuleBuilder class, types are added to a module. That an assembly can contain multiple modules is pretty irrelevant, the build environment doesn't support it. Not just the IDE, MSBuild doesn't support it either. You'd have to write a build script yourself to use al.exe, the assembly linker. There are no good reasons to do this that I can think of, all .NET compilers already know how to generate a single module assembly directly. Al.exe is a typical bootstrapping tool, possibly used to build mscorlib.dll.

what is the need of assembly ? why we use them?

To quote the MSDN article on assemblies:
"Assemblies are the building blocks of .NET Framework applications; they form the fundamental unit of deployment, version control, reuse, activation scoping, and security permissions. An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality."

An assembly in .NET is a unit of code that has been compiled together into a single executable, library, or module. Whenever you compile code, you will generate an assembly. I do not believe there is a way to use .NET code without using an assembly.

You can use reflection to learn about the types in an assembly as well as other metadata.

In the context of assemblies in C#, what does activation scoping refer to?

Yes, this is vague.

"Activation" does not have a precise technical meaning in the CLR, or in C#. But it is a technical term in COM, the Component Object Model, which is the native Windows component model that predates and co-exists with .NET.

In COM Activation means "The process of loading an object in memory, which puts it into the running state." (https://learn.microsoft.com/en-us/windows/win32/com/com-glossary)

You can see a holdover from this terminology in the naming of the System.Activator type, which has similar functionality to the COM activator function CoCreateInstance.

In .NET a Type lives in a specific Assembly, and a Type name is unique within an Assembly. At runtime Types with the same name might be contained in other Assemblies that are currently loaded into your AppDomain. But whenever you are creating an object instance (ie an "activation"), you either specify the Type (which implies a specific Assembly), or the Assembly and Type name.

In the normal case of writing a type name in code, the compiler will identify which referenced Assembly to use for the target Type, and if multiple Types with the same name are found at compile time, the compiler will either give you a warning CS0436, or an error CS0433.

In the case of Reflection, you can load a Type by name, but you always have to specify an Assembly to load the type from. Notice that there's not an overload of Activator.CreateInstance that just takes a Type name, and Type.GetType also requires you to specify an Assembly.

In either case you are "activating" the object from a specific Assembly. So the Assembly defines the "scope" for the Type "activation".

Determining if an assembly is part of the .NET framework

I suspect that the method both most reliable and most general is going to be the PublicKeyToken. Yes, there's more than one, but it's going to be a finite list and one that doesn't change very often.

For that matter, you could just have a whitelist of assembly names -- that list, too, will be both finite and static between versions of the framework.

---

Related Topics