I was thinking about how to create a program that would only be valid for X period of time, (within a C# app).
What I was thinking was that you would have the curren
I would go with the "Phone home"-variant. And make that call important. ;) I mean, some important function in your program (some calculation maybe?) will take place on the server. So if the user decompile the program and remove that "call home" it will render the program useless.
I know that not all programs have those specifications that makes this possible but more than you think in general.
Check out AssemblyInfo.cs file in the Properties folder in your project:
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
Change this to:
[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.0.0")]
Then, elsewhere in the assembly, use this:
System.Version MyVersion = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version;
// MyVersion.Build = days after 2000-01-01
// MyVersion.Revision*2 = seconds after 0-hour (NEVER daylight saving time)
DateTime MyTime = new DateTime(2000, 1, 1).AddDays(MyVersion.Build).AddSeconds(MyVersion.Revision * 2);
return string.Format("Version:{0} Compiled:{1:s}", MyVersion, MyTime);
Precompilation directives are your key here. You could create a constant in your application and have it set when you compile.
Make sure you obfuscate your code, however. Someone could disassemble it easily and tamper with the constant. Another solution is to have your software "phone home" to register itself. That way, the registration info is stored on your server and not their machine. There are also third party packages that perform the same security as you're looking for, but they are expensive!
I'd suggest that you have the date in a separate, strong named assembly - then at least the malevolent user will find it hard to disassemble, edit and get your program to use it. Is there a way to have two assemblies validating each other based on strong names?
We kind of use this as a first step in our license control for one of our components. If the calling assembly has the same fingerprint as the license controlled one, we assume that it's being used within our own software and licensing is bypassed. If the calling assembly has a different fingerprint or no print at all, normal license checka are carried through. When I come to think of it, our users could probably disassemble, compile without strong naming and bypass licensing. But then again, all our assemblies are shipped as x86, not CIL - would that change anything?
Our experience is that if you're dealing with corporate customers, no-one can bear the hassle of tampering with your stuff, especially since there is a risk in getting caught. A little goes a long way, our current licensing solution is pretty outdated (the package includes examples for VC5!) but has been a high enough hurdle so far. With consumers, on the other hand, I can imagine that it's a bigger threat.
My initial suggestion seems to spawn more questions that answers - perhaps not that helpful after all. :)
I know this is a 3 year old question, but just to add my 2 cents. We use a "DateLimit" hard coded in a structure as suggested by James Curran.
But we also use that same "Date" as a simple key to "crypt" and "Decrypt" (more Code and decode) all strings, labels, messages. If some people (We call them Cheaters) want to change the expiration date, They will have to go thru the whole assembly to reenter all those string correctly for the new expiration date. It's not perfect, but the cost to us is now near zero and the cost for the Cheaters is high.
The problem with .Net is that it would be easy to decompile and change the date you want to use has constant. You might need to think to something else.
You could write it in the registry but then the people will edit this value.
They aren't a perfect solution but to have an account that validate with an external (web) server is a good idea.