There is no such thing as "C# reference". A "a programming language writer" like you should be able to understand such basic things.
I assume you mean how to figure out, given an assembly, which assemblies it references. From the other hand, it could be the set of actually loaded assemblies.
This is how to get referenced assemblies:
http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getreferencedassemblies.aspx[
^].
This is another method giving somewhat different results, getting loaded assemblies:
http://msdn.microsoft.com/en-us/library/system.appdomain.getassemblies.aspx[
^].
With second method, you can take all Application Domains during runtime of your process and merge loaded assemblies.
So, why these two methods give different results? The thing is: when you load assemblies, you can reference more of them then you actually need. It looks like actually unused referenced assemblies are optimized out by the CLR: if you use the second method, you may find that some of your assemblies are not actually used. Another reason is this: you can load assembly during runtime, using one of corresponding methods of
System.Reflection.Assembly
. From this moment, some new assembly will appear as loaded in the Application Domain where you did it, but such assembly does not have to be referenced.
[EDIT]
Also, you question suggests that you confuse assemblies and namespaces. For example, "System" cannot be "referenced", because this is not an assembly. If you take just .NET FCL assemblies, you will see that two different assemblies declare types under then namespace "System". Moreover, you can create your own assembly and declare types under the same namespace, and it will be perfectly valid, some 3rd-party products are like that. And one assembly can declare types under two or more different (related or unrelated) namespaces.
Those things are just orthogonal to each other. In fact, namespaces do not exist as any actual objects when the code is compiled to CIL. They are no more but some subsets of fully-qualified type names. The type and the assemblies declaring them, as well as modules — this is what actually exist. And only assemblies can be referenced, not namespaces.
You just need to read about those concepts, before you can move forward.
—SA