Application Trial And StreamRead/Writer

Ben Magee

Hi, Im making a trial of one of my applications, and i want the user to only be able to run the application 5 times.. now, my original plan had been:

//WRITE VALUE TO TRIAL FILE
int numint = 1;
TextWriter trialWrite = new StreamWriter("oote.oost");
trialWrite.WriteLine(numint+1);
trialWrite.Close();

So it would add +1 to the value of numint each time the application loads, but its not working right, and it doenst add to the number inside the text (oost) file in question. I also tried +1 but that doesnt work either. Its in the form_load event. Can anyone tell me how to add +1 to the value of the number already in my text file? thanks, Ben.

Henry Minute

You need to set the value of numint by reading the value in "oote.oost" BinaryReader.ReadInt16/32/64(). To do this you will need to use a BinaryWriter (BinaryWriter.WriteInt16/32/64()) instead of your StreamWriter, but that is better since the file will be slightly obfuscated for casual meddlers.

Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”

Ben Magee

Ok, Can you give a code example please? Thanks, Ben.

Henry Minute

OK. This is to go in the Form.Load, as per your original question:

	private void Form1\_Load(object sender, EventArgs e)
	{
		string fileName = "oote.oost";
		int numint = 0;

		if (File.Exists(fileName))
		{
			BinaryReader binReader = new BinaryReader(File.Open(fileName, FileMode.Open));
			try
			{
				numint = binReader.ReadInt32();
			}
			// If the end of the stream is reached before reading
			// the four data values, ignore the error and use the
			// default settings for the remaining values.
			catch (EndOfStreamException ex)
			{
				// This is just for your info, should not get here
				MessageBox.Show("Unable to read \[numint\]", "File Read Error");
			}
			finally
			{
				binReader.Close();
			}
		}

		if (numint >= 5)
		{
			MessageBox.Show("Sorry too many runs", "Limit Exceeded");
			Application.Exit();
		}
		else
		{
			BinaryWriter binWriter = new BinaryWriter(File.Open(fileName, FileMode.OpenOrCreate, FileAccess.Write, FileShare.None));
			try
			{
				binWriter.Write(numint + 1);
			}
			catch
			{
			}
			finally
			{
				// Just to be sure
				binWriter.Flush();
				binWriter.Close();
			}
		}
	}

However, I do not like doing Application.Exit() from within the Form.Load handler. I cannot give any meaningful reason, it just seems wrong to me to do all the form loading and initializing stuff, if you aren't going to let them in. So as an alternative you can do pretty much the same in the Main() method of the Program class. Here:

static class Program
{
	/// /// The main entry point for the application.
	/// 
	\[STAThread\]
	static void Main()
	{
		Application.EnableVisualStyles();
		Application.SetCompatibleTextRenderingDefault(false);

		string fileName = "oote.oost";
		int numint = 0;

		if (File.Exists(fileName))
		{
			BinaryReader binReader = new BinaryReader(File.Open(fileName, FileMode.Open));
			try
			{
				numint = binReader.ReadInt32();
			}
			// If the end of the stream is reached before reading
			// the four data values, ignore the error and use the
			// default settings for the remaining values.
			catch (EndOfStreamException ex)
			{
				// This is just for your info, should not get here
				MessageBox.Show("Unable to read \[numint\]", "File Read Error");
			}
			finally
			{
				binReader.Close();
			}
		}

		if (numint < 5)
		{
			BinaryWrite

Luc Pattyn

Now all the user has to do to go beyond 5 runs is either completely remove the file, edit it with a hex editor, restore it after each run, or reinstall the program. this answered the question, however you are well aware is not the way to implement trial limitations. real solutions would use access to a web server, or a hardware dongle. :)

Luc Pattyn

:badger: :jig: :badger:

Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

:jig: :badger: :jig:

Ben Magee

I'm Aware of this fact, and I'm currently working on solutions to it :-) By hardware dongle do you mean memory stick? One of the solutions im looking at is creating the file with installation, then using a If statement to see if the file exists or not, if it does, then it writes to the file, if the file doesnt exist then the application will exit. True all the user would have to do then is make another file. But it should stop casual snoopers, All I really want it for is to make sure my friend doesnt leg it with a BETA release of some of my software, nothing too big. thanks All, Ben.

Henry Minute

Luc Pattyn wrote:

you are well aware is not the way to implement trial limitations. real solutions would use access to a web server, or a hardware dongle

Whilst this is true in almost all situations, the OPs method might be enough, depending on the location of the "oote.oost" file, the permissions for that location and the knowledge/skill level of the users. As I do not do commercial development I do not feel that I have the depth of knowledge to advise people on these matters. I restrict myself to trying to answer their questions. There are always people with working knowledge of such techniques that can advise the OP, if they feel it necessary. :)

Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”

Luc Pattyn

Ben Magee wrote:

By hardware dongle do you mean memory stick?

not necessarily. There are products (such as WIBU Codemeter) that use a special hardware device (nowadays usually USB) to protect your app, which gets modified obviously, in a way that is supposed to be not so easy to hack; the variable cost would be around 30 euro. for cheap software, it is possible to do it yourself e.g. based on a memory stick, as they AFAIK always contain a rather unique ID (from observation, and not guaranteed). both methods require the hardware to be present for the app to run, which is both a hard-to-copy way of protecting, AND a burden for the user. However it is much better IMO than relying on some built-in unique ID (baseboard serial number, disk serial number, MAC address, ...) as these are not always present, some can be changed easily, and users don't want licensing trouble when changing some hardware. :)

Luc Pattyn

:badger: :jig: :badger:

Have a look at my entry for the lean-and-mean competition; please provide comments, feedback, discussion, and don’t forget to vote for it! Thank you.

:jig: :badger: :jig: