[ACCEPTED]-How can I make my product as a trial version for 30 days?-trialware

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

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

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

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

You could use a licensing component. You 2 can make one yourself (see the LicenseManager class), or buy 1 one from a vendor (for example CryptoLicensing).

I have one simple solution for you.

Take 17 2 variables for registry: 1. date 2. counter

steps:

1. Set 16 a counter = 1

2. Copy system date to date

3. Check 15 each time if the date is different than 14 the current date, than copy that date to 13 the registry date, also increment the counter 12 by 1. If the date is same, don't do anything.

4. Now 11 you can check you counter for trial days 10 expiration

By using these trick, if user 9 change the system date to previous date 8 than also it works.

For registry you can 7 encrypt the date & counter so that technical 6 person would not recognize your logic!

cheers...

ADDED

This 5 logic fails only when user doesn't change 4 the date for each day! Again we have the 3 solution for that!

I don't know whether it 2 is possible or not but you can always have 1 some solution:

1. count the total time for trial period & store it in registry.
2. Now count the total time for each run and add it in another variable. (I hope that it can be done by timer)
3. Compare above two values for taking decision for expiration.

You need to have a way of detecting if the 18 user changes the date from when you first 17 started the trial. In solutions I've used 16 before, we have saved the "last executed" date 15 and the "first executed" date and if the 14 clock changes to anything more than two 13 days of "last executed" we expire the trial. You 12 also need a "days executed" counter so that 11 they can't keep moving the date two days 10 back (forgot to mention that part) - the 9 counter gets incremented on each execution.

Of 8 course, software licensing systems like 7 this are always avoidable by uninstalling 6 and reinstalling with appropriate refreshing 5 of the registry - the trick is obfuscating 4 and duplicating your license information 3 enough to make this difficult, but eventually, it 2 will get found (especially if you're using 1 an unobfuscated .NET codebase).

Hard to process 30 days without reference 16 to the system date/clock. You could always 15 keep a list of the dates on which the app 14 was started and count 1 for every time it 13 was different from the last time. This way 12 your user would have to set the same date 11 each time they fired up your app.

Other 10 than that, you could, providing there were 9 internet access, query a known good time 8 server for the current date. This could 7 be circumvented by disconnecting but you 6 could always demand an internet connection 5 before your app will start.

Lastly, an external, local 4 time source via a hardware dongle or similar 3 but I think you are getting into the extreme 2 where you'd be better off directly managing 1 the trials in person.

You can use free project Libprot. The site 24 is https://github.com/libprot/trunk.

The idea is that it should be simple 23 and easy to use. You can spend $$$ on protection 22 but it may be hacked in one week. If someone 21 wants to do reverse engineering of your 20 code then no one can stop it. My advice 19 to use simple methods that works.

Write a 18 string like:

Company X|10.2.2014|1.12.2015

where 17 10.2.2014 is current date and if the system 16 time is less then someone changed system 15 clock => we should not run

1.12.2015 14 - until what time the key is valid

and name 13 of company who bought/downloaded it.

that 12 string should be obfuscated with asymmetric 11 algorithm with private/public key and encoded 10 into string that you may send by e-mail, for 9 example.

you may also want to have some web 8 service for validation. when internet connection 7 is on you may validate the key, if it's 6 hacked and available for public in internet 5 you may ban it. Or if someone would write 4 key generator you may validate that key 3 is real.

you can add some PHP/java script 2 in your site to automatically send trial 1 codes.

IF you can guarantee an internet connection 9 you could implement an online scheme (check 8 a time server or your own authentication 7 server). Of course that introduces another 6 dependency - if the internet goes away, your 5 users can't work.

Ultimately I'd say buy 4 a third party licensing solution - it's 3 still not unbreakable but it will probably 2 be more robust than something you can do 1 yourself without a lot of time and effort.

Store the last run date, and whenever the 10 system date is before that, expire the trial.

The 9 only fail-safe method is to validate the 8 app against a service that you host, assuming 7 no one cracked your connection code ;)

As 6 long as they can clear the registry value/isolated 5 storage file/saved settings: they can just 4 restart the trial. There's not much you 3 can do about that. That's why people opt 2 for reduced functionality in trial software, in 1 addition to a time-based trial period.

If its acceptable to allow say 8 hours of 8 trial usage (instead of a 30 day trial), then 7 one way to remove the dependence on the 6 System DateTime is by using a timer in your 5 app which is fired say every minute. Count 4 these and so every time the app gets run, it 3 will accumulate a total usage minute count. You 2 can then store this count value somewhere, such 1 as in the registry.

It's simple store evaluation end date and 7 check for it every day. To avoid extended 6 usage by date manipulation, maintain an 5 hour count in the application; keep incrementing 4 and writing it to registry. Check should 3 be done against both the evaluation end 2 date and the hour count not to exceed 24 1 (may be 30 with some teolrence).

Think Also About :

Saving the DateTime of 11 the closing of the application, next time 10 it's lunched your application will be able 9 to detect if the Datetime setting was changed 8 or not (at least they can't change it before 7 to something before the closing time). Example 6 :

On Application Closing :

Saving The Time => 15:34 03/31/2014 (Saved)

Next Starting Of The Application :

Check 5 Datime.Now > 15:34 03/31/2014. (so they 4 can't go bellow that...)

ADDED :

Try somehow to integrate 3 the datetime settings of the system into 2 your application use : Generating Invoices, Tickets, Receipts... whatever 1 !