Denying your public classes from your end customers

Here's a cool way to make sure that no one else but your application can use any of the public classes that are exposed by your business assemblies: you put a permission requirement on the class that requires the strong name of your calling assembly:

[StrongNameIdentityPermission(SecurityActoin.LinkDemand, PublicKey="XXXYY)]

public class MyPublicLogicClass

{

//do something

}

[via Juval Lowy's .Net Master class]

Published Wednesday, December 29, 2004 4:43 PM by RoyOsherove
Filed under:

Comments

Wednesday, December 29, 2004 7:03 AM by TrackBack

# Denying your public classes from your end customers (from: Roy Osherove)

Wednesday, December 29, 2004 4:48 PM by John Rusk

# re: Denying your public classes from your end customers

Nice technique.

It's worth nothing that code running with "full trust" can get around all the CLRs security features (see http://msdn.microsoft.com/msdnmag/issues/04/04/SecurityBriefs/ ), so presumably this technique is only reliable when calling code is known to be partially trusted.

Wednesday, December 29, 2004 9:40 PM by TrackBack

# Denying other software inadvertent use of your public classes

Thursday, December 30, 2004 3:12 AM by Roy Osherove

# re: Denying your public classes from your end customers

John: There's no way around this. Even in fully trusted code.
Thursday, December 30, 2004 4:42 AM by Tim Haines

# re: Denying your public classes from your end customers

Hi Roy,

Nice to know about. Frans Bouma describes a way around this. I haven't tried it, but thought you might be interested to see it. Read the comments here: http://blogs.msdn.com/tims/archive/2003/12/03/57463.aspx

Sunday, January 02, 2005 8:35 AM by TrackBack

# Denying other software inadvertent use of your public classes