Wondering about System.Int32 implementation

If you are a .NET programmer (and do not use reflector), you would look at int and System.Int32 as same. But if you are also interested in reverse engineering, you would surprise how would they implement something like this.
This is how Int32 (part of mscorelib.dll) may look like in reflector,

namespace System
{
//attributes blah blah blah
public struct Int32  //implements blah blah blah....
{
internal int m_value;
//… other code with methods with ‘int’ as return type or parameter
}
}

But if int and Int32 are same, wouldn’t it become circular reference? (not ‘reference’ exactly has int is value type ;). The answer is NO. as we use them in real life. It seems reflector’s code is hardcoded to show it or mscorelib is compiled in some alien world.

I read[1] that there a special treatment given for 'int' (and so all other keywords). Interestingly, I learned creating my Int32 (and other predefined types). When I created something like this, in my project,

public struct Int32
{
public Int32 m_value;

public Int32 GetMe()
{
return this;
}
}

But after compilation, I saw (in reflactor) compiler did this to my class,

public struct Int32
{
// Fields
public int m_value;

// Methods
public unsafe int GetMe()
{
return *(((int*) this));
}
}

hmm.. Interesting. It looks like (also suggested in link [1]) when the compiler encounter an 'int' or 'Int32' in the structure which cannot be replace by pre-compiler as Int32, it gives 32 bit to variable m_value there. So, basically variable m_value doesn't exist as int or Int32 but it is just 32 bits which can be retrieved using unsafe code as shown above. Combination of visual studio intellisence, pre-compiler, compiler are specially designed to handle this scenario.
Note: For losers using Java, int is value type and Integer is reference type. Both are not same there. What a shame!

[1] C# compiler magic regarding int vs System.Int32 Thread on MSDN