Security Library Classes

15 Aug 2006 5:09 AM

gary

Hi,

Eugene Bobukh's weblog from May 2005 (
http://blogs.msdn.com/eugene_bobukh/archive/2005/05/06/415217.aspx )
documents that LinkDemands are optimized out in full trust mode in .NET
2.0.

What is the best way to prevent third party applications from running
methods within my libraries? Bearing in mind my concrete classes all
derive from interfaces and as so the InternalsVisibleTo 'friendly
assemblies' method is not a solution for me.

Thanks,

Gary

15 Aug 2006 1:05 PM

Nicole Calinoiu

"gary" <gbre***@gmail.com> wrote in message
news:1155618544.421446.45020@i42g2000cwa.googlegroups.com...
> Hi,
>
> Eugene Bobukh's weblog from May 2005 (
> http://blogs.msdn.com/eugene_bobukh/archive/2005/05/06/415217.aspx )
> documents that LinkDemands are optimized out in full trust mode in .NET
> 2.0.

Aside from InternalsVisibleTo and custom stack walks (similar to
http://blogs.msdn.com/eugene_bobukh/archive/2004/03/10/87603.aspx, but you
can stop at the caller frame if you only want to simulate LinkDemand
behaviour), obfuscation and/or licensing are probably your best bets.

> What is the best way to prevent third party applications from running
> methods within my libraries? Bearing in mind my concrete classes all
> derive from interfaces and as so the InternalsVisibleTo 'friendly
> assemblies' method is not a solution for me.

Why not? Since you only want to allow your own assemblies to act as
callers, your concrete classes are presumably located in a set of known
assemblies. (I'm actually not fond of InternalsVisibleTo myself, but what
you're describing doesn't sound like a blocking issue.)