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.html
In CLR v1.x, there is a concept of identity permission, where we can use for example StrongNameIdentityPermission class to restrict calling permissions.app
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.less
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.aspxide
Now within the new model, how can we secure our assembly from mal-calling?rest
One of my proposals would be to use InternalsVisibleTo attribute: http://msdn.microsoft.com/en-us/library/bb385840.aspxcode
And I've seen it has typically been used in some test solution: http://www.cnblogs.com/lmule/archive/2010/08/15/1800227.htmlorm
This can be applied if the most concern is at compilation.htm
If you have more concern in runtime, you may consider doing the authorization logic in the source code such as checking caller's publickey.blog
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.get