Embedding

A huge concern for me when creating the install application for Serial Key Maker was making the installation process as error proof as possible.

If the installation process fails, or is clunky, my potential clients are never going to see the benefits my application has, and won’t trust it enough to hand over their money for it.

It thus became important for me to reduce the number of dependencies in the project. I wanted to reduce the complexity involved in getting the application working, and in referencing the API from their applications.

Recall, Serial Key Maker is made up of two related products. The GUI which allows the developer to generate product keys and the API which they use in their code to validate the product keys.

I had a logging object that encapsualtes error trapping and general logging functionality. It is used in both the GUI and in the API. I didn’t want to duplicate the logic in both places, so I made a separate DLL that both projects referenced.

+1 for code reuse

-2 for complexity

To reference my API to validate product keys, the developer had to include the logging DLL AND the API DLL into the project. A small thing, but I obcess on making this product SIMPLE to implement, and referencing TWO DLL’s feels like over-complication when one will suffice.

I explored various options:

1. Duplicate the code in both places
2. Embed the logging DLL into the GUI and the API projects.

There are trade off’s with each solution: duplication makes it more difficult to maintain the code. Using an embedded DLL, while elegant, turns out to be fairly slow performing.

I eventually decided to put the logic for logging into a separate class and use that class in each project. The duplication requires me to be carefull, but I figured it was more important to affect the user less.

I did learn by figuring out how to embed a DLL and get access to its methods, so the effort was not wasted. 

This post is a description of how to embed a DLL into a compiled application and then reference it via the application’s resource manifest.

To show how to use an embedded DLL, I have created a project that demonstrates the technique. [Download Embedding Sample Code]

Note: The sample solution was created with VS2008, and is written in VB.Net.

The Code Explained

 I have encapsulated most of the code we need to handle
Embedded DLL’s into a shared class. [EmbeddedAssemblyHelper.vb]

Step 1 – Embedd the DLL

The first thing to do is to embed the DLL into your project, and flag it to reside in the application’s resource data. Do the following:

1. Right click on your project, and select “Add” and then “Exisiting Item”. Note: Do NOT use the “Add Reference” option
2. Navigate to, and select, the DLL you want to embed. The DLL will show up in the file list of your application.
3. Select the DLL in Solution Explorer, and open the property page for the DLL.
4. The first property is “Build Action”. Change the drop down option to be “Embedded Resource”

 

Now when you compile your project, the DLL will be built into your binary file for use within your application

Step 2 – Initialize the Event Handler

When we reference the embedded DLL within the project, the framework will go through its regular discovery process to try find the DLL, and it will raise an error – it is not in any of its search locations (GAC, local etc).

We need to set up a handler to intercept this error.  To do that, make a call to the “Initialize” method.

Note: You need to call “Initialize” as early in your application’s startup as possible. Also, you cannot reference the embedded DLL in the same method you make the call to “Initialize”.

 

When the framework raises an error, we intercept it and run the “LoadEmbeddedAssembly” method.

The framework passes the name of the assembly it failed to resolve. We use that name (our Embedded Assembly) and load it manually.

We call out to the EmbeddedAssembly_LoadManually method, which then uses the “GetManifestResourceStream” method to extract the data embedded in our application’s resource data.

We then use that stream to create an Assembly by calling “System.Reflection.Emit.AssemblyBuilder.Load”

Referencing the Embedded DLL

In the sample provided, I made a DLL (“GP_EmbeddedTestDLL”) that has a worker class (“classWorkerTest”). The class contains 3 complex methods that I will use to show the various ways to access the methods ont his embedded DLL

The code examples I found on the web that address this issue only showed the most basic way to call a method – methods that had no parameters, and returned no data.

I have made methods that contain parameters, and in one case returns a user defined data type (“GetPersonObject”).

Step 3.1 – Creating a Reference to the Embedded Assembly

Using reflection we do an Assembly load:

This triggers our event and returns our embedded assembly reference.

Step 3.2 – Create an Instance of the Assembly

Use the CreateInstance method on our assembly to create an instance of our object:

Step 3.3 – Invoke the Method

3.3.1 The first example of a method to call has no paramters and returns a string (“GetCurrentTime”):

3.3.2 The second example of a method to call has a paramter (diameter) and returns a string (“CalculateCircumference”):

3.3.3 The last example of a method to call has multiple paramters and returns a user defined class. I made a “Person” object which is a class inside the “GP_EmbeddedTestDLL” object we embedded in our application. 

It is a class that has properties about the person, and is returned by the function call “GetPersonObject”.

1. We invoke the method as usual, passing in the array of parameters.
2. We then use the “GetProperty” on the type to get at the property values of the class returned.

As mentioned, I decided not to use embedding in Serial Key Maker due to performance concerns I had, however, I think this is a powefult technique and will use it when it makes sense to do so.
I’d love to hear from anyone who is using this technique in their applications. Please email me at
grant@serialkeymaker.com

Thank you for reading,

Grant

Why do you need License Key Protection?

Do you want license key protection to stop hackers using your software for free? Or is it perhaps to stop competitors from reverse engineering your algorithms?

While understandable, these goals are futile for us developers.  .Net and its IL compiler makes it even more futile. No matter how much time and money you spend on obfuscation and License Key protection, there will always be someone with enough time and skill to bash and crack through it. If a computer can make sense of your code, so can a human.

My suggestion is that you should refocus your energy and redefine what you need out of License Key Protection.

As with all aspects of development, it becomes an issue of balancing cost versus benefit. You can spend many thousands (literally) of dollars on a Licensing System, and have
very very very good protection, making it very very very difficult to crack and reverse engineer, or obviously, you can do nothing, and make it easy to crack.

Somewhere in the middle is a solution for you and your software. As a Micro-ISV (my intended audience) you do not have a huge budget (or even a large one), you likely have a relatively in-expensive product (in the 20-100 dollar price range) and you are selling to regular (non-IT) people.

Your target users will find your product useful and will pay for it if asked. Unfortunately, most people will use it for free if allowed to do so. For the most part they won’t necessarily search hacker sites for a cracked version, but if they get a non-limited copy they will use it.

My opinion is that you do not need to spend hundreds (thousands) of dollars on a license key solution with all the bells and whistles. What you need is a solution that limits some of the juicy features of the product, and limits their usage for a certain amount of time. This becomes an opportunity to show your product to users, and get them hooked on its functionality, and then incent them to purchase it.

Your licensing solution should, therefore, be a marketing tool, not an anti-hacking tool. You are using it to put your product in front of people and make a sale.

You may be thinking that if this is all you need out of a licensing solution that you may as well roll your own solution. We all think like this. It’s how we became developers in the first place. However, as business people, we need to consider the real cost involved and weigh that against the benefits.

How long would it take to make a robust, error free license key solution? 20 hours is the absolute minimum, in my opinion – and I doubt it could be done even that quickly.

If your time is worth 65 to 150 dollars per hour ($1300-$3000), buying a robust solution in the price range of 100 to 200 dollars on the other hand seems like a great investment – one which would include support and maintenance, I might add. (Something to consider when your license solution breaks or needs to evolve)

Summary

• you indeed need some form of licensing solution
• you cannot get one that is uncrackable
• you do not have to make it yourself
• it does not have to be ultra expensive to be good

Thank you for reading,

Grant

My Target Audience

When I decided to make Serial Key Maker, I honed in on .Net developers who are trying to start a small business by selling their niche software.

These are people who are learning what it takes to put together a sellable product, do the marketing and figure out SEO, all by themselves. They are operating on a tight budget (less than $500 to launch), they sell their software for between $15 to $100, and are aiming to make between $5000 and $15000 per year in sales. .

Within these parameters, there is no money to shell out $1000+ for License Key Protection. It makes no sense to do so. These early stage businesses have many hurdles to cross before the money starts rolling in, and even when it does, there are many other necessities to invest in.

While my clients’ niche software does not control the secret launch codes that fire off nukes into space, the software still needs to be protected. Users will use software for free, unless they are
at least asked to pay for it. My clients need a way to present a demo version that is limited in features and typically expires after a period of time. If the user wants to keep using it, they need to purchase it.

In other words, license protection for my clients is a marketing tool. Note, it is NOT a tool to stop a competitor reverse engineering the product, or to stop 16 year old Billy with nothing else to do but cracking it so he can give free copies to anyone who logs on to his website. Choosing to develop the product in .Net makes this especially true.

Thus, some form of License Key Protection is required – even for $15 software. $1000+ is just too much to shell out on an unproven, low cost product. It just does not make business sense. So what ends up happening, is that the developer is forced to roll their solution.

However, even the simplest solution requires a time commitment of 20 or more development hours. Besides the time taken away from the core product, there is the risk that if the developer gets it wrong, he risks locking out legitimate, paying customers, or not presenting enough of a barrier to get people who would have paid, to actually pay for the software.

This is where Serial Key Maker shines! There is (in my opinion) a large enough gap between rolling your own solution, and paying many hundreds of dollars for a more full-featured solution.

I want to fill that gap so that early stage Micro-ISV developers can implement a serious marketing tool within their application, without taking the 20-40 hours to do it right. I chose $99 as the price point because that would hopefully strike the point that to do it yourself you’d be effectively paying yourself less minimum wage!

.Net compiles to IL (intermediate language). To make the code very very very very difficult to read and hack you would need to choose the products that run into the multi-thousands of dollars. In a sense it is overkill for Micro-ISV’s to go to these lengths. Very difficult, is enough

The other large feature I required for Serial Key Maker to be viable is its ease of use. The other solutions on the market are difficult and confusing to implement. They run the gamut from re-compiling linked code, to online registration systems requiring the software to regularly call home to validate registration.

Besides the extra cost, the extra work, and impact on client perceptions makes it difficult for the small companies to justify using these solutions.

I concede my thoughts on the subject may be flawed. I would love to hear your thoughts on Serial Key Maker. If you installed it, but decided not to buy it, I’d love to hear why you made the choice. What features are you looking for? What are the things that are important to you?

If you did buy the product, what else would you like to see in the product? What works for you and what does not?

Please send me an email at
grant@serialkeymaker.com

Thank you for reading,

Grant

Moved

I moved the blog from my previous site, and am in the process of moving the old posts to here.