Finding the right licensing product and/or methodology for licensing ASP.NET applications is much tougher than what is required for windows applications. Why? You have to take into account that most of your clients will want their ASP.NET applications to run under NETWORK SERVICE or some other low priviledged account. So, you are restricted to what can be placed in the registry (if anything at all) and where you can read/write files. Of course, your installer can take care of the latter "if" your client accepts it in conjunction with their own security policies.Microsoft SLP
My company uses PreEmptive Solutions Dotfuscator Professional to obfuscate our assemblies. This year, they began offering an integrated licensing solution that incorporates Microsoft SLP (Software Licensing and Protection). Naturally, I turned to SLP's hosted alternative. It is very, very expensive but offered increased piracy protection and impressive feature usuage tracking capabilities within the software itself. I found their administration web site and code samples relatively easy to follow.
Microsoft SLP's email support is pretty much useless. Even though they don't have very many clients (evidence by lack of traffic to their forums), they rarely reply to legitimate questions. Typically you can get a non-account specific question answered via the forums within a couple of days though.
The biggest let down was that Microsoft SLP requires read access to the registry to validate the license. It offers no other alternative. Our clients will balk at this. Why they chose to force registry usage is beyond me considering the direction Microsoft has taken with User Access Control and various other endeavors to restrict what certain windows accounts can read and write to. What is important to gather from this is not whether access to the registry is a large security risk but whether your potential clients will perceive it that way. With that in mind, I had to scrap Microsoft SLP.Desaware Licensing
As many of you know, the famed Dan Appleman runs the show over there at Desaware. So, when I discovered that they offered a licensing solution I downloaded the demo. Fortunately for Desware, my first impression was not my final impression. I had all kinds of trouble installing the licensing server's database to an existing installation of SQL Server 2005 Developer Edition. I ended up having to create the database in SQL Server 2005 Express and copy the database to Developer Edition.
The client application doesn't "look" impressive. Its feature set is relatively limited in contrast to Microsoft SLP. You get the core licensing capability and that's about it. There are a variety of processes to manage updated dlls and implementing license keys that are far from intuitive and often times don't work. Desaware has a lot of work to do in this area to increase sales. Many times, the non-informative error messages you'll receive will remind you of Microsoft products.
Desaware's support is very responsive and quite helpful. They'll give you the specifics you need to resolve the problem and not berate you when (like most males) you failed to read and follow their directions.
The Desaware Licensing product really works well for licensing ASP.NET applications. The most common approach with their toolset is to use the client License Manager (which uses web services to communicate with the license server) to create .NET resource files for inclusion within the assembly you want licensed. The .NET resource file contains the information your application will need to contact the license server or how to manage non-internet based licensing scenarios. You'll reference their sample C#/VB.NET source code samples to write code in your assemblies to handle the license validation and execution tasks anyway you like. When your code decides that it is time to install a license, your code creates a license file external from your assemblies that is tied to that specific machine/server. Wherever applicable, your app can validate the license against this local external license file. It will ensure that the license file can be used on this machine/server.
The license file can be placed in machine/user isolated storage or anywhere you choose on disk. So, your ASP.NET installer or the application itself can get around pretty much any reasonable security restriction you can envision.
At the end of the day, I ended up with a licensing solution that was powerful and flexible along with solid customer support. I got neither from Microsoft SLP. Keep in mind, I spent $1500 "after" I had a working solution and had gotten around the problems mentioned above. I'd strongly recommend looking at Desaware when deciding on your licensing solution.DesawareMicrosoft SLP
Many of the licensing samples you'll see store the result of the license validation process in ASP.NET Cache, Session, or Application variables. You need to remember that anyone wanting to bypass your license validation can easily upload code to sit alongside yours and quickly discover and override what you store in cache, session, or application variables.
You are going to need to properly obfuscate your assemblies and bury your licensing logic deep in at least one of them. Make sure that anything you store in memory cannot easily be accessed by someone else's code at runtime.