.NET assemblies - executable and static - confused

I solely work with web applications, so I have virtually no real experience with Windows Forms designed in .NET.

I'm reading up on assemblies, and there are two types; static, which comes in .dll form, and exectuable, which comes in .exe form.

As far as I can work out, an 'executable assembly' is just another name for a compiled application (that is, a console application or a Windows Fo开发者_如何学JAVArms application).

Can you clarify it?

Edit: My terminology comes from this article: http://msdn.microsoft.com/en-us/library/k3677y81%28VS.71%29.aspx

Edit 2: OK, so now, as I understand it, you have static and dynamic assemblies, static exists on disk, dyanmic is created on the fly/on demand. Secondly, you have executable assemblies, which are our applications, such as a console application like helloworld.exe.

I've never heard of the term "static assembly" for executable files or class libraries. Basically, a .NET assembly can have an entry point. The ones that have an entry point and are executable directly from the operating system shell (or the CLI runtime, to be more accurate) are ".exe" files and the ones that don't have an entry point and are used merely as supporting libraries of other applications are stored as ".dll" files.

Update:

Looking at the reference you provided, it's clear what it means from a "static assembly":

Assemblies can be static or dynamic. Static assemblies can include .NET Framework types (interfaces and classes), as well as resources for the assembly (bitmaps, JPEG files, resource files, and so on). Static assemblies are stored on disk in portable executable (PE) files. You can also use the .NET Framework to create dynamic assemblies, which are run directly from memory and are not saved to disk before execution. You can save dynamic assemblies to disk after they have executed.

The MSDN article is calling the assemblies stored as files on disk "static assemblies", as opposed to "dynamic assemblies" that are generated at runtime by some code (e.g. classes in System.Reflection.Emit namespace). It doesn't matter whether they are DLLs or EXEs (both of the file types have a Portable Executable (PE) header, as well as a CLR header). Only thing that matters is that they are not generated dynamically (hence the term "static") and are previously stored on disk. Outside the context of dynamically generated assemblies, the term "static assembly" is rarely used.

The differences are very minor in the .NET world. A .exe is simply an assembly that was compiled with the /target:winexe compiler option and contains a static Main() method in one of its types. As opposed to a DLL type of assembly, compiled with the /target:library option.

Having an entry-point is very important for a .exe, that's where the program starts executing. Every Windows program gets started that way. You just don't see it in a ASP.NET app, the .exe that runs your code is iis.exe.

To confuse you more, an assembly that is compiled to a .exe in .NET works just as well as a .dll. You only have to use Assembly.LoadFrom() in your code and you'll have access to all the types in the .exe module, just like you'd have in a .dll module.

Key point is that if the CLR isn't hosted by some other executable process, like ASP.NET or SQL server or MMC or the myriad of programs that leverage CorBindToRuntimeEx(), you'll need to tell .NET where your code starts executing. Main point that it starts at Main().