Disallowing Updates

I can think of plenty of ugly workarounds, but I was hoping to find out that there was a simple and straightforward way to do this.

Sure, simply add license checking directly to wyUpdate. That is, modify wyUpdate to check the license (by confirming it with your server, or however you do it) and see if updating is still allowed.

If you're using LimeLM we'll be adding this ability to wyUpdate in the near future. If you're using in-house or some 3rd party licensing then I can give you some pointers if you specific help in implementing this.

Ah, so you're recommending putting this business logic into the wyUpdate.exe and compiling our own version? Since this file (wyUpdate.exe) was included in the original install, but not in any of the updates, will this cause any weirdness for existing customers if I start including wyUpdate.exe in the updates? I don't think it will.

I haven't looked at LimeLM. Last time I looked it wasn't out yet. I've been excited since it looks like it does exactly what I need it to do. My only concern is in how to migrate from our current scheme to LimeLM. I'll do some investigation.

Cheers.

Ah, so you're recommending putting this business logic into the wyUpdate.exe and compiling our own version? Since this file (wyUpdate.exe) was included in the original install, but not in any of the updates, will this cause any weirdness for existing customers if I start including wyUpdate.exe in the updates? I don't think it will.

You can't include wyUpdate.exe within your updates. wyBuild won't complain, but when wyUpdate is updating your app and it sees a file that tries to overwrite itself it just throws the file out.

That being said, updating wyUpdate is possible. See How to make a custom version of wyUpdate.

Simply modify the properties of your app's wyBuild project, and specify the new wyUpdate version on your servers. So wyUpdate will start self-updating to your custom versions.

I haven't looked at LimeLM. Last time I looked it wasn't out yet. I've been excited since it looks like it does exactly what I need it to do. My only concern is in how to migrate from our current scheme to LimeLM. I'll do some investigation.

You can migrate a few ways. You can use 2 licensing schemes at once - your old one and your new one. Or you can send out new licenses made with LimeLM to your existing users.

If you want to use LimeLM for update limiting, then we'll move it up the priority list for you. Do you want to go this way?

I'm guessing the disadvantage in building your modified version of wyUpdate would be that it wouldn't automatically update so you'd have to implement bug-fixes etc on your own. If I'm wrong about this, please just ignore the rest of this post. If you want to avoid doing that, then you could try not including the update server location while building wyUpdate, and adding it programmatically at run time using command line switches after checking for license validity from the server. You could make it more clever by dynamically changing the update location and obtaining that information from the server as well, or hosting the updates on an ftp server where you change the password regularly - and getting the password information dynamically from the server after it has checked license validity... Don't know if that'd help but seems simple enough to try.

I'm guessing the disadvantage in building your modified version of wyUpdate would be that it wouldn't automatically update so you'd have to implement bug-fixes etc on your own.

We covered this in the How to make a custom version of wyUpdate article. Yes, you can self-update your own custom build of wyUpdate.

You will, of course, have to maintain your branch of wyUpdate. This means pulling in our bug-fixes and features. But if you're familiar with subversion, this should be an easy enough task.

If you want to avoid doing that, then you could try not including the update server location while building wyUpdate, and adding it programmatically at run time using command line switches after checking for license validity from the server. You could make it more clever by dynamically changing the update location and obtaining that information from the server as well, or hosting the updates on an ftp server where you change the password regularly - and getting the password information dynamically from the server after it has checked license validity... Don't know if that'd help but seems simple enough to try.

We actually have a beta version of the LimeLM and wyUpdate integration ready. It doesn't involve any trickery or changing update locations. It's rather simple:

• wyUpdate sends the server your license details.
• The server confirms the details (namely that the license still has a valid update contract).
• The server either rejects the license and sends an error, or it sends the update file.

There's no need to hide the locations of the updates - either the updates will be served or they won't be. The server decides based on the license.

If either of you guys want to test this beta version of wyUpdate just say so.

Yeah, I'm definitely interested. Here is what we are currently doing:- All of our apps are desktop apps developed with .NET. We are migrating away from ClickOnce to wyBuild and perform frequent updates (each month or more frequently).- All of our apps require registration to use. This is how we are currently doing this: When the app runs, it generates a unique number (based on hardware). It checks with our server to see if that number is authorized. If it is authorized, the server returns information about the licensing (including which plug-ins are authorized, the date the licensing expires, and the date after which the user may not receive automatic updates). The app then responds accordingly. If the license does not exist, the app prompts them for user information and creates a license. For apps for which we offer a limited-time trial, the server creates a license with a set expiration date in the near future. For other apps, it creates a license that is not activated.- When licenses are created/requested, the server email sales, support, and the customer with the appropriate info.- We use a web interface to manage the licenses. We can activate/deactivate, change expiration dates, add/remove the authority to use various plug-ins, etc.- Each time the app runs, it checks in with the server. So we can easily activate/deactivate licenses and even app plug-ins on individual computers.

So, I developed the license management site, but don't really have time to support it. It is also pretty anemic. I knocked it out in a couple of days just to have a way to manage licenses for an app we were releasing.

If LimeLM could handle these use cases, we would almost definitely switch. This is actually a great time for us to make the switch. We are planning on moving one of our apps from ClickOnce to wyBuild, and we are discontinuing updates for the app that currently uses wyBuild. It will be replaced by another app which is currently in development.

Yeah, I'm definitely interested. Here is what we are currently doing:- All of our apps are desktop apps developed with .NET. We are migrating away from ClickOnce to wyBuild and perform frequent updates (each month or more frequently).- All of our apps require registration to use. This is how we are currently doing this: When the app runs, it generates a unique number (based on hardware). It checks with our server to see if that number is authorized. If it is authorized, the server returns information about the licensing (including which plug-ins are authorized, the date the licensing expires, and the date after which the user may not receive automatic updates). The app then responds accordingly. If the license does not exist, the app prompts them for user information and creates a license. For apps for which we offer a limited-time trial, the server creates a license with a set expiration date in the near future. For other apps, it creates a license that is not activated.

wyUpdate, wyBuild, and the AutomaticUpdater satisfy the first point. LimeLM satisfies the second point.

- When licenses are created/requested, the server email sales, support, and the customer with the appropriate info.

We have a web-api that you can integrate directly into your order process. That is, generate a product key on the fly and email to the customer and/or your separate departments.

- We use a web interface to manage the licenses. We can activate/deactivate, change expiration dates, add/remove the authority to use various plug-ins, etc.

We have the ability to "revoke" and "reenable" product keys remotely, and change expiration dates (in our beta version - we'll be released this weekend). Features licenses (e.g. licenses for plugins) should be coming this weekend as well.

- Each time the app runs, it checks in with the server. So we can easily activate/deactivate licenses and even app plug-ins on individual computers.

TurboActivate (the client side of LimeLM - the part that integrates with your app) can do this. However, we recommend you give users a bit of a grace period. For instance your user might be working on a plane. Or maybe their internet drops out at their office (some parts of America have spotty internet).

However, if you want to be strict that's your prerogative.

So, I developed the license management site, but don't really have time to support it. It is also pretty anemic. I knocked it out in a couple of days just to have a way to manage licenses for an app we were releasing.

If LimeLM could handle these use cases, we would almost definitely switch. This is actually a great time for us to make the switch. We are planning on moving one of our apps from ClickOnce to wyBuild, and we are discontinuing updates for the app that currently uses wyBuild. It will be replaced by another app which is currently in development.

Send me your email (wyatt@wyday.com). Also, when is your deadline for full license & update limiting within your app?

We've uploaded a new help article SaaS and time-limited licensing that describes how to do this.