Now the security has a trend to become more and more important in our daily work, hence I did some researches on some of the topics, and hope to do more fooling around in the future.
In CLR v1.x, there is a concept of identity permission, where we can use for example StrongNameIdentityPermission class to restrict calling permissions.
In CLR v2.0, it introduces CAS so that identity permission get bypassed. That is, a demand for an identity always succeeds, regardless of the identity of the assembly, if the assembly has been granted full trust.
In CLR v4.0, the security model changes again, some security policy has been eliminated from CAS, for more information please visit: http://msdn.microsoft.com/en-us/library/vstudio/dd233103(v=vs.100).aspx and http://msdn.microsoft.com/en-us/magazine/ee677170.aspx
Now within the new model, how can we secure our assembly from mal-calling?
One of my proposals would be to use InternalsVisibleTo attribute: http://msdn.microsoft.com/en-us/library/bb385840.aspx
And I‘ve seen it has typically been used in some test solution: http://www.cnblogs.com/lmule/archive/2010/08/15/1800227.html
This can be applied if the most concern is at compilation.
If you have more concern in runtime, you may consider doing the authorization logic in the source code such as checking caller‘s publickey.
However, there is no absolute to avoid ALL attempts of determined developers, they can always find a way, but the difference is easier or harder.
How to make your assembly more secure from referencing by unauthorized bits