How to restrict the update elligibility period?

This is an interesting problem.

As I understand wyUpdate now, even if we use the UpdaterControl to gain some control over managing whether and when to check for updates, nothing can prevent the user from running wyUpdate.exe from the application folder even after his free update period is over.Should we delete the client.wyc file together with wyUpdate.exe from the application folder?

No, don't delete the client.wyc file.

Do you have a solution for this problem?

There are a couple of ways you can do this.

Quick & dirty method

wyUpdate support client.wyc files that are not in the same folder as wyUpdate.exe. So if the user double click wyUpdate.exe they will get an error. But if you launch wyUpdate with the -cdata commandline option:

wyupdate.exe -cdata:"C:\location\to\client.wyc"

Then wyUpdate will start correctly. This is hardly secure, but it will stop 99% of your users from bypassing the update limitation.

You can take it one step further by randomizing the "client.wyc" location on installation. Then your program will start and you can find the file and start wyUpdate if their support contract hasn't expired.

Elegant method

Features like this are on our roadmap for full proper support. Plus we plan on fully integrating with LimeLM.

However, if you don't want to wait, the wyUpdate C# source is available for hacking & modifying. We'll help you find your way in the source.

Just a note: some people get offended when we show them the source code. I'm not saying that the only way the features will be implemented is if you code them, rather that we haven't implemented them yet (we will). Plus, if you do code up a solution you can submit it back to us or not (no obligation). Then we can fully support your solution and bake it right into wyBuild.

Tell me if this is helpful.

Thank you, I will have a look at the code to see what can be done. I guess that except from integration with an advanced licensing scheme, nothing will be more efficient that the client file in a different directory.

While it would stop most normal users, my only concern is how easy it would be to crack - I can already foresee "hackers" on forums posting a crack for free updates in form of a simple .bat file or an advice to locate any .wys file on their computer and move it to the app directory 🙂

In case I will create an extension to wyUpdate, what will happen to this code? Are we "guaranteed" that the modification will stay in the code base? I am asking because a generic extension that would allow any licensing mechanism to be plugged in to the application from outside (think an event raised) may get a little tricky as this is a standalone exe. I will go through the sources and try to figure something out.As I understand it, wyUpdate updates itself automatically (in the background?), so having a separate custom build of wyUpdate.exe would not help...or would it?

I would prefer using the programmatic approach instead of launching wyUpdate with parameters - I guess I would need to modify the updater control sources as well...or can this be accomplished purely with the wyCommandLineArgs (sorry if I remembered the name wrong) property in the updater control? If yes, I would love to learn how.

While it would stop most normal users, my only concern is how easy it would be to crack - I can already foresee "hackers" on forums posting a crack for free updates in form of a simple .bat file or an advice to locate any .wys file on their computer and move it to the app directory 🙂

That's true. Without proper server-side integration this can be thwarted by a clever cracker. It's on our todo list.

In case I will create an extension to wyUpdate, what will happen to this code? Are we "guaranteed" that the modification will stay in the code base? I am asking because a generic extension that would allow any licensing mechanism to be plugged in to the application from outside (think an event raised) may get a little tricky as this is a standalone exe. I will go through the sources and try to figure something out.As I understand it, wyUpdate updates itself automatically (in the background?), so having a separate custom build of wyUpdate.exe would not help...or would it?

Sure, you can do a separate build. You'll have to host your own copy of the wyUpdate updates so the self update algorithm with update to your copy of wyUpdate rather than our copy of wyUpdate.

Then change the wyUpdate server file in your app's project by going to File->Properties->wyUpdate and changing the site "http://wyday.com/files/wyupdate/updates/client.wys" to "http://yoursite.com/whatever/server.wys".

We're writing documentation on how to properly maintain custom builds of wyUpdate, but I can give you a quick and dirty guide in the meantime if you need it.

I would prefer using the programmatic approach instead of launching wyUpdate with parameters - I guess I would need to modify the updater control sources as well...or can this be accomplished purely with the wyCommandLineArgs (sorry if I remembered the name wrong) property in the updater control? If yes, I would love to learn how.

Yes, just set the "wyUpdateCommandline" property to pass arguments to wyUpdate.exe:

string secretClientFileLoc = @"C:\location\to\client.wyc";


automaticUpdater.wyUpdateCommandline = "-cdata:\"" + secretClientFileLoc + "\"";

Just a note: you can see the all the AutomaticUpdater members here.

Thanks for your response, this was my last conceptual issue with wyUpdate, I will see what I will be able to do with the source code to restrict the update eligibility and if everything goes well, we should be able to replace ClickOnce with wyBuild/wyUpdate.