All partners who develop a solution or an extension face the possibility that someone might misuse the code, copy it, or pass the code off as their own solution.

There are really 2 aspects to the problem.

1) Theft of the code 'Invention' - the techniques and business rules that are contained in the application extension.

And

2) Pirate copying and unauthorized use of the application extension.

A business partner will need to stop a competitor both stealing the code and also stop them just copying the files into another CRM installation.

Compiled .NET assemblies are of course non-human readable. Theoretically they can be obfuscated - but, in practice only part of a project can be obfuscated as all the external methods must remain publically available. This is so the methods can be called from the CRM interface (tab groups etc). This makes obfuscation more difficult to use effectively.

ASP pages like all script files can be encrypted. I am not sure I like encryption as it is not compilation and when the page is run the ASP page will need to be decrypted each time. There will be a small performance cost. Encryption of a text file means that it is very vulnerable to accidental alteration. If someone opens a file and adds a space character then the encryption check will fail and the page will be invalid. The encryption of the files also means that you loose the best advantage of an ASP page which is its ability to be edited by a consultant while on the customer site.

Some development partners have used instead of encryption the idea of bundling and compiling using VB6 all their code and the ASP objects into a single dll. This approach has worked in the past but it is not actually checked for by QA so I could not recommend that practice. Also VB6 is not some what outdated.

Another approach which can work the ASP pages is taking the critical code and creating a COM object that is referenced from the ASP page. The creation of a binary COM object would hide effectively the business rules from prying eyes. The same approach could be used with Sage CRM.NET assemblies as they can reference other code which is obfuscated.

But for both ASP pages and .NET API application extensions a problem remains. What is there to stop someone just copying the dll or the ASP page into another site? Both advertise as a feature the fact that they can be dropped into an install very easily.

To stop that happening there must be a reference to something that authorizes the application extension on a particular install. This is perhaps by a registry key entry, an entry in the custom_sysparams table or even a hardware dongle that maybe present. It is up to the partner to thing about any custom key generation they need. All techniques have been used by partners.