Newbie to .net framework - what is an .net assembly?

[Ronen Yacov]

Hi there,

I'm new to the .net frameowrk - I've been working with C++ for over
ten years now.
What is a .net assembly? Is it like an executable created in C++?
Do you run it?

Thanks for any answer,
Ron

 

[Andy]

Hi there,

I'm new to the .net frameowrk - I've been working with C++ for over
ten years now.
What is a .net assembly? Is it like an executable created in C++?
Do you run it?

Thanks for any answer,
Ron

An assembly is the unit of deployment for .Net applications.
Assemblies are simply a collection of classes within a namespace. A
library assembly is typically stored in a .dll, but an .exe is also an
assembly as well. The only real difference is that an exe assembly
must have a method that matches the signature static [ void | int ]
Main( [ string[] args ] ).

This is a pretty good overview: http://en.wikipedia.org/wiki/.NET_assembly

Andy

 

[Guest]

For the .NET Platform, Assembly refers to the main unit of compilation that
is used to create objects by the CLR (Runtime).
If you compile a Windows Forms EXE, that's an assembly. If you compile a
class library to a DLL, that's also an assembly. These are loaded by CLR into
an AppDomain at runtime, JIT-compiled into machine code, and executed.
Peter

 

[Larry Smith]

For all intents and purposes (as the others have already mentioned), an
assembly is simply a DLL or EXE in the .NET world (each is called an
"assembly" but it's just terminology). From a conceptual viewpoint it's
really that simple. You create your DLL or EXE and distribute it just like
you would in C++ (though the rules for finding DLLs at runtime are different
in order to eliminate DLL hell). The former contains library routines and
the latter is an executable just like you're used to (usually anyway). Now,
it's actually more elaborate than a native DLL or EXE for various reasons.
First, it doesn't contain natively compiled (machine) code. It contains IL
(Intermediate Language) code which is compiled on-the-fly when you first run
it (to machine language on whatever machine you're running it on). That is,
when you compile your .NET app in VS, it's compiled to IL and not machine
code. You can therefore run it anywhere that .NET is supported just like
Java (but Windows is really the only game in town). When you do run it for
the first time, .NET compiles the IL code to native machine code
behind-the-scenes using what's known as the JIT (Just-in-Time) compiler. It
then runs it and so ends the basic story. In any event, note that assemblies
also contain other info including the definitions of all classes/structus
you defined in the assembly (known as metadata). These classes (if not
declared "internal") can be used by any other .NET app regardless of
language. Language interoperability is therefore a breeze compared to what
you're used to (eliminating the need to rely on other component technologies
like COM - thankfully I might add). You can also secure your assemblies
using the public/private key pattern so that a malicious 3rd-party can't
tamper with them (.NET will refuse to run an assembly if tampering has been
detected). Many other benefits also exist. I suggest you get hold of a copy
of "Programming .NET Components" by Juval Lowy. He's a MSFT recognized guru
on the subject and his book is indispensible IMO (for experienced .NET
developers as well). Also download Petzold's free book here. It's
specifically for C/C++ developers though he seems to forget that sometimes:

http://www.charlespetzold.com/dotnet/index.html

Lastly, I also worked in C/C+ for many years (since the early 80s) and .NET
is a great piece of work but it's not a panacea. It has it weaknessess and
the docs have been a serious problem for me in particular (due to lack of
sufficient info). Good luck.