How to protect my .net winforms assembly from customers of a customer

This question appears to have died, so I've de开发者_如何学JAVAcided to offer a bounty.

What I'm most interested in knowing is if my scenario in the ETA1 below is viable and is used. If it isn't, then a good explanation of why not would be a good answer. Another good answer would be an alternative (but not including the internalsvisibleto attribute).

The best answer would be, yes, it's viable, everyone does it and customers love it!

ETA2: I think I've thought of a good solution. I provide the customer with a distributable edition that is as functional as their edition but is unlicensed and has the classes and members hidden, using attributes. I can do this with compiler directives, on every single important member, but I wondered if there was some global way to hide all members of a class?

A simplified scenario:-

I have a class that extends a control in someway and I want to sell my class under two licenses;

(1) Standard - The customer gets x number of controls that use my class but can't instantiate the class (its internal).

(2) Developer - The same as Standard except they can create their own controls that use my class.

My problem is that when the developer customer comes to sell their controls, they can't help but expose my class to all their customers.

--- Ignore this The only way around it, in my scrambled mind, would be for the developer to somehow integrate my assembly into theirs, and in that way I can keep the constructor internal. Or, use the internals visible to attribute. / Ignore this ---

I'm sure someone here has had the same situation and any help would be greatly appreciated.

ETA1: I'm thinking aloud here, but, I could have a list of permissable calling assembly names which the customer could add to. When they ship their product, their customers' assemblies would not be in the list and therefore they wouldn't be able to instantiate certain classes. (The list could obviously be hashed).

I believe you will store the licensing information (i.e, Standard and Developer) somewhere in the registry. In such case, I suppose the simpler solution would be to implement LicenseManager. This is what most .NET component vendor use.

http://msdn.microsoft.com/en-us/library/fe8b1eh9.aspx

Hope this helps !

I believe you've come up with the only real solution, assuming the runtime will support it. As long as yours is a separate DLL, if the developers can instantiate your objects then so can anyone else, whether you try to hide it behind a constructor, a factory, whatever.

I wonder, though, whether consumers might not even be able to get around that restriction by integrating the shipped assembly into their own?

Why don't you use license keys? Your class reads the license key and depending on what permissions the license offers it disables methods at runtime?

The license key could be defined in the config file.

It's a tough one, just due to the nature of .NET. It's a shot in the dark, but you could look into products such as CodeVeil which provides assembly encryption at the IL level. Your assembly would essentially be shipped encrypted and the key would be handed to your customer. The customer would then be the only entity with the ability to decrypt your assembly instructions. Now, CodeVeil claims the following about its decryption keys:

Even though the key is stored in the application that does not make is insecure. In fact the key itself is not as important as the transformation of the data itself. CodeVeil also uses many runtime-protection operations to frustrate hackers attempting to capture the decrypted assembly. In addition CodeVeil uses a very special decryption system that decrypts only enough information for the .NET runtime to execute that specific method. The code is never stored in the same memory as the assembly itself so the decrypted code cannot be dumped to disk for analysis.

This is obviously a good thing, but this is the part you'd have to research because i am not familiar with the other techniques they use as part of their decryption algorithm. The cool thing about this is if it works, your customers will be happy and THEY can make their customers happy by exposing parts of your assembly through their own API. At the same time your code stays protected from tools such as ILDASM and Reflector.