Order of Classes within an Assembly

Question

What determines the order of classes within an Assembly?

And.. is there a way to change it?

---

Additional info: you can check the ordering either through reflection yourself, or you can use a tool like ILDASM, disable the alphabetical sorting, and then you will also get the order.

Order seems to be in a strange way determined by the compiler.

I already tried some things.. like renaming the classes (order stays the same), also editing the .csproj file to change the order of the .cs files.

My main focus is VS2008, C#, .net 3.5.

---

Update: I do have a scenario where the order matters (external program going through my assembly through reflection) - and I need special order there. Apart from this - you are totally right - order really should not matter.

Answer 1

I'm going to stick my neck out here and say this is an implementation detail and may well be decided by any particular compiler.

Since this is an implementation detail you shouldn't or needn't be concerned. Of course if this really is important (can't see why) you can always write your own IL.

I leave you with the following quote from Eric's blog :

Is compiling the same C# program twice guaranteed to produce the same binary output?

No.

Answer 2

What determines the order of classes within an Assembly?

The compiler.

And.. is there a way to change it?

Write your own IL directly.

---

That being said, the order of the types within the assembly really doesn't matter. You can use the types with no regard to their order.

Answer 3

Since I haven't work with this in years I am trying to recall this as best I can, however most of this is what I recall from reading "Expert .NET 2.0 Il Assembler" by Serge Lindin and writing my own disassemblers. So FWIW:

Before the world of managed code, ie Java or .NET, the layout of the code and data was more exacting because of the use of loaders that layered the code and data as raw bytes from storage right into memory. With the advent of managed environments, came an added layer that could read storage and then view it not as data to be mapped to memory by as a graph of data with Meta data. As such the Meta data could be used to layout the code and data into memory. Doing a quick scan for an answer in the book the only point of note I could find was under "Order of Manifest Declarations in ILAsm" pg. 112. "The general rule in ILAsm (and not only in ILAsm) is "declare, then reference."" So some of the Meta data has rules about ordering, but since the Meta data holds references to the actual code and data in storage, only the meta data has a specific order and the code and data we are used to having a specific order can now be unordered. Again FWIW. If you had asked me several years ago I probably could have written a whole paper for you.