Create an Application That Will Expire After a Trial Period

Create an application that will expire after a trial period

If you go with a date-based approached, it can be circumvented by a user's setting their date back (although I doubt people do this very often). An alternative is to allow the application to be started a certain number of times before expiring; this approach obviously ignores any date changes.

My preferred method is to disable parts of the application that are critical to normal use of the program but aren't critical to its evaluation (like the ability to save your work, for example). I do this with my own software, and then send them an unlocking code unique to their computer when they purchase the full program. One primary advantage of this approach is that the installed demo functions as a potential sales tool forever. I'd rather have my program always working to some extent; I don't think a "Sorry, this program has expired" message generates many sales.

Code to check 30 days trial for my application

This depends entirely on what you want to have happen when a trial expires.

You probably want to immediately end the program. You could also give them the option of visiting your website to purchase a license. Maybe something like this:

if (day > 30)
{
    if (MessageBox.Show("Trial expired. Visit site to purchase license?",
        "Trial Expired!", MessageBoxButtons.YesNo) == DialogResult.Yes)
    {
        Process.Start("http://www.yourwebsite.com");
    }

    Environment.Exit(0);
}

If you have something else in mind, or other requirements, update your question with more details.

How can I make my product as a trial version for 30 days?

You could have another registry key that you increment after every day's use. That way, even if they change the computer's date, this key would indicate to your program that it's been running for > 30 days.

Additionally, this value could be encrypted so that if the user tries to manually change it, the program can refuse to run because it was unable to decrypt the value and get a valid number out of it.

To get around reinstalls, you could add some information to any file saved with the trial version of your app which is unique to that specific version of the app (perhaps a timestamp from when it was installed). When a trial version of your app tries to open a file, it will check this signature and ensure that it was created with that same instance, otherwise refuse to open the file. This essentially neuters the ability to simply reinstall the app and continue using it.

At the end of the day though, the user has complete control over their machine and can probably find a way around whatever it is you want to do (short of accessing a web service where these details are kept before you let the user use the app). You probably shouldn't expend so much energy trying to stop the guys who are willing to go through this extra trouble, but instead spend that extra time/money/energy improving the app for those who are willing to pay.

Show application Registration dialog on first run and after trial expired

Thanks to the above discussion with @Akram Mashni. I come up with this Solution which work fine for my scenarios.

I modified the DaysToEnd() Method to public so i can call it with instance of the TrialMaker class from anywhere else (My Main() for example):

public int DaysToEnd()
{
    FileInfo hf = new FileInfo(_HideFilePath);
    if (hf.Exists == false)
    {
        MakeHideFile();
        return _DefDays;
    }
    return CheckHideFile();
}

Then I make use of it in my Main() method to check my scenarios. When I call DaysToEnd() it will update the info stored on the SystemFile by calling CheckHideFile() inside it.

I called DaysToEnd() first so i can update the info in the SystemFile
DaysToEnd() will return int value representing days remain in trial period. Also I called get for TrialPeriodRuns which I added earlier to the library and it represent the remaining runs in the trial period.

Also I implemented nested if-else statements to check my scenarios:

        int daystoend = t.DaysToEnd();
        int trialperiodruns = t.TrialPeriodRuns;
        /// Check if it is first run here 
        if (dte == 15 && tpr == 1000)
        {
            bool is_trial;
            /// then show the Registration dialog
            TrialMaker.RunTypes RT = t.ShowDialog();
            if (RT != TrialMaker.RunTypes.Expired)
            {
                if (RT == TrialMaker.RunTypes.Full)
                    is_trial = false;
                else
                    is_trial = true;

                PharmacyManagementSystem.App app = new PharmacyManagementSystem.App();
                app.InitializeComponent();
                app.Run();
            }
        }
        /// Check if it is trial but not first run
        /// no Registration Dialog will show in this case
        else if (dte > 0 && tpr > 0)
        {
            PharmacyManagementSystem.App app = new PharmacyManagementSystem.App();
            app.InitializeComponent();
            app.Run();
        }
        /// Check if it is expired trial
        else if (dte == 0 || tpr == 0)
        {
            bool is_trial;
            /// then show the Registration Dialog here
            TrialMaker.RunTypes RT = t.ShowDialog();
            if (RT != TrialMaker.RunTypes.Expired)
            {
                if (RT == TrialMaker.RunTypes.Full)
                    is_trial = false;
                else
                    is_trial = true;

                PharmacyManagementSystem.App app = new PharmacyManagementSystem.App();
                app.InitializeComponent();
                app.Run();
            }
        }
        /// the full version scenario remain and it comes here 
        /// no need to show Registration Dialog
        else
        {
            bool is_trial;
            TrialMaker.RunTypes RT = t.ShowDialog();
            if (RT != TrialMaker.RunTypes.Expired)
            {
                if (RT == TrialMaker.RunTypes.Full)
                    is_trial = false;
                else
                    is_trial = true;

                PharmacyManagementSystem.App app = new PharmacyManagementSystem.App();
                app.InitializeComponent();
                app.Run();
            }
        }

And finally it works like a charm for me

thanks again @Akram Mashni for inspiring me

Disable application after expiry date for trial

You can't make things complete secure, but you can make it hard(er).

Packing with UPX adds some level of complexity to the hacker.

You can check at runtime if you're running under a debugger in several places or if you're running under a virtual machine.

You can encrypt a DLL you're using and load it manually (complicated).

You can write a loader that checks a hash of your application and your application can check the hash of the loader.

You can get the system time and compare it to a system time you already wrote to disk and see that it's monotonic.
All depends on the level of protection you want.

If you go to PirateBay or any other torrent site, you'll see that everything get's hacked if hackers are interested.

How to make trial period for my python application?

You need a web server and a database to get this working.

Create a licenses table in your database.
Each time a new client pays for your software or asks for a trial, you generate a new long random license, insert it in the licenses table, associate it to the client's email address and send it to the client via email.
Each time a client tries to install the software on their computers, you ask for a license and contact the webserver to ensure that the license exists and is still valid.

Using that, people can still just create multiple emails and thus potentially get an infinite amount of trial versions.

You can then try to add a file somewhere in the person's computer, a place where nobody would ever look for, and just paste the old license there so that when the app starts again (even from a new installation), it can read the license from there and contact the webserver without asking for a license. With this method, when your app contacts the server with an expired trial license, your server can reply with a "license expired" signal to let your app know that it has to ask for a non-trial license now, and the server should only accept non-trial licenses coming from that app from now on. This whole method breaks if your clients realize that your app is taking this information from a local file because they can just delete it when found.

Another idea that comes to mind is to associate the MAC address of a laptop (or any other unique identifier you can think of) to one license instead of an email address, either at license-creation time (the client would need to send you his MAC address when asking for a trial) or at installation time (your app can check for the MAC address of the laptop it's running on).

How do I enforce an expiration date for a trial install of my software?

I've discovered over the course of several years of trying out varying licensing systems that there's a strong inverse correlation between security, and alienation of your potential customers.

There are essentially two kinds of piracy you need to worry about. One is casual piracy - users using the software without paying simply because they haven't really thought to pay. The other is deliberate piracy - people who are determined not to pay, and are willing to put real effort into not doing so.

Casual piracy can be handled with what essentially comes down to gentle reminders - activation keys, time limits, etc. Deliberate piracy, on the other hand, essentially can't be prevented. As Sony, Apple, Microsoft, Nintendo, and a number of other companies will tell you, even when you have the benefit of control of the hardware as well as the software, your protection scheme will be broken. And the person breaking it is as likely to be doing it for the sake of a fun challenge as for the desire to get free software. So for a certain demographic, making the protection stronger doesn't discourage them, it does quite the opposite.

Meanwhile all the stuff you do to try and achieve strong protection is driving legitimate users up the wall. Maybe the trip for detecting gerrymandering with the system clock got set off because they changed time zones. Or maybe they had to replace a bad hard drive or CPU or something, and that set off the system cloning mechanism. Or maybe Microsoft changes Windows's default security settings in a way that causes Windows to pop a mess of UAC warnings while your app's in use thanks to it not being friendly to some trick you used to try and hide the file that stores the licensing data. At work we use a commercial solution, and we've discovered that their protection mechanism can trip in ways that, thanks to a bug in the software, can cause the license data to be corrupted, thus locking the user out of the program. Because of the way their system stores that data, its an unrecoverable situation - the customer literally has to choose between not using that software on that computer ever again, and wiping the hard drive. Yes, it's happened multiple times. Yes, we've lost a lot of potential revenue over it. Yes, I get queasy to think of the damage it's caused because we rely primarily on word of mouth and it's generated a whole lot of bad word of mouth. Long story short, the naive paranoia about piracy of earlier years has probably cost me quite a number of sailing vacations in the Caribbean.

And the worst of it is, it's only a problem for legitimate users. Crackers can easily - painfully easily - get around it with the aid of - if it comes to last resorts - a debugger and decompiler. If the software is on a device in the possession of the end user, you might as well start thinking as if your software's already been cracked. It's to the point that there's a cottage industry that has built up around the idea of people cracking software they legitimately own, just to avoid the annoyance of the software protection mechanisms. They'll give you the money, but they'll still crack the software because your copy protection is just that irritating, and just that easy to circumvent. The alternative - and this is the route I've gone - is to just go buy different software that's less annoying, or use free software instead.

So go with the minimum - watch the clock and time out the demo, because you do need to remind your users to send you a check. But don't do it in a way that makes them decide they don't want to give you a check. If your goal is to convert sales, consider this as the most elegant, cost-effective, and efficient system for keeping users from violating your demo period by mucking with the system clock: It's really, really irritating to work with a computer that's got the clock set to the wrong date. And that's just for home users. For (legitimate) businesses, it's not even a feasible option. And anyone who isn't deterred by that is probably a script kiddie who never really had the means to pay for your software in the first place.

Creating an Android trial application that expires after a fixed time period

Currently most developers accomplish this using one of the following 3 techniques.

The first approach is easily circumvented, the first time you run the app save the date/time to a file, database, or shared preferences and every time you run the app after that check to see if the trial period has ended. This is easy to circumvent because uninstalling and reinstalling will allow the user to have another trial period.

The second approach is harder to circumvent, but still circumventable. Use a hard coded time bomb. Basically with this approach you will be hard code an end date for the trial, and all users that download and use the app will stop being able to use the app at the same time. I have used this approach because it is easy to implement and for the most part I just didn't feel like going through the trouble of the third technique. Users can circumvent this by manually changing the date on their phone, but most users won't go through the trouble to do such a thing.

The third technique is the only way that I have heard about to truly be able to accomplish what you want to do. You will have to set up a server, and then whenever your application is started your app sends the phones unique identifier to the server. If the server does not have an entry for that phone id then it makes a new one and notes the time. If the server does have an entry for the phone id then it does a simple check to see if the trial period has expired. It then communicates the results of the trial expiration check back to your application. This approach should not be circumventable, but does require setting up a webserver and such.

It is always good practice to do these checks in the onCreate. If the expiration has ended popup an AlertDialog with a market link to the full version of the app. Only include an "OK" button, and once the user clicks on "OK" make a call to "finish()" to end the activity.

Create an Application That Will Expire After a Trial Period