# Using wyUpdate to update a plugin system

### Using wyUpdate to update a plugin system

Hi Wyatt,

Firstly, I have to give credit where it's due! The wyBuild and wyUpdate releases are excellent. I've been struggling for a long time to find something to do updates this well and this simply. And your open source extras are really fantastic icing on the cake.

I'm in the process of testing out the wyUpdate system to see if it can fulfill all our quirky requirements, and it obviously does cover most right out of the gate. I want to ask you about a specific scenario though and see what ideas you can give me.

Just to quickly explain our system. We have a website and executable that tie together with a plugin system. Each plugin obviously has a specific job, and consists of an assembly containing the plugin class, and a usercontrol that the website displays to configure the plugin class. Once plugins are configured, the "executer" executes each one in turn, using the data gathered by the usercontrol.

wyBuild is perfect for updating the "executer" itself, but I'm trying to work out a system for updating the plugins individually. Would I be able to build update packages that target one dll assembly as the main item, instead of an executable, and then use the wyUpdate API to update each one in turn? Secondly, can the wyUpdate classes be used to update a package without a UI, as in the case of the website?

Just in case I'm not being clear I'll spell out my desired execution...

In the global.asax of the website we look for all plugins registered. What I would like to do is then check for, and update if required, each plugin at this stage, before the website starts executing directly. Obviously there is no UI available here as we will be executing in the IIS worker process.

Then on the executer side, the executer will start, and do it's own update check using the Automatic Updater component. Then, just like the website, it will check for the list of plugins available, and update each one if required, before starting the main execution (obviously here the UI would be fine, as long as I can do it without user interaction).

In case you're wondering, I want to keep the plugin updates separate as the plugins are developed by a range of developers all over the place, so the more separated and autonomous the system for those developers and me, the better.

Assuming in advance, thank you so much for taking the time to read this.

Thanks,

### Re: Using wyUpdate to update a plugin system

Adam wrote:Firstly, I have to give credit where it's due! The wyBuild and wyUpdate releases are excellent. I've been struggling for a long time to find something to do updates this well and this simply. And your open source extras are really fantastic icing on the cake.

Thank you.

Adam wrote:wyBuild is perfect for updating the "executer" itself, but I'm trying to work out a system for updating the plugins individually. Would I be able to build update packages that target one dll assembly as the main item, instead of an executable, and then use the wyUpdate API to update each one in turn?

As you've likely realized, as of version 2.5 both wyBuild and wyUpdate view your product in a holistic sort of way. That is, your main program and all plugins are "your product" as a whole. There's no way to break your product into "packages" and only deliver updates to packages that are old.

However, there are 2 hacky workarounds.

Hacky workaround #1

You can create a separate wyBuild project for each separate plugin. Build your updates and build wyUpdate for each plugin project.

Collect the each "client.wyc" file from each plugin project. You can rename them to whatever you want (e.g. plugin1.wyc).

Now, to check for updates to this plugin you can use that same wyUpdate that's included with your main executable. But you have to pass to arguments to wyUpdate:

Code: Select all
wyUpdate.exe -cdata:"C:\path\to\plugin1.wyc" -basedir:"C:\path\to\plugin1\directory"

Then you can silently check for updates to each of your plugins. See How to Silently Check for Updates.

Problems with Hacky workaround #1

For every plugin that has an update available a new wyUpdate window will appear telling your user about the update. This will annoy the hell out of your users.

Hacky workaround #2:

Not a great option either.

Best option:

The best option - the one that will require the least amount of hassle for yourself and your users - is to simply collect the "official" plugins with your product. Then, just update all the plugins along with your executable.

The great thing about this option is that even if you release a new update every day the patching algorithm included with wyBuild will generate tiny update files.

Adam wrote:Secondly, can the wyUpdate classes be used to update a package without a UI, as in the case of the website?

Yes, and no. The trouble here is user permissions. Servers are typically configured such that all executing scripts are run as a limited user (or on Vista, 7, Server 2008 R1 & R2, as an Admin without elevation). This coupled with the fact that the 'wwwroot' folder is almost always protected as if it were a system folder. This means that wyUpdate can check for updates perfectly fine, but it's going to need to show a UI to prompt for Admin privileges.

See How to Silently Check for Updates, specifically read the section "Silently Checking without using the AutomaticUpdater control".

This way wyUpdate completely autonomously (and silently) checks for updates. If updates are found it shows itself. If no updates are found it exits immediately and returns 0.

Adam wrote:In case you're wondering, I want to keep the plugin updates separate as the plugins are developed by a range of developers all over the place, so the more separated and autonomous the system for those developers and me, the better.

As I mentioned above in "Best option" you should collect the plugins and create updates to your whole product. I'm not just saying this because it works around limitations in wyBuild and wyUpdate.

I'm making many assumptions about how your team is set up, so what I'm about to write may be way off the mark. As the owner of the product it would be best if you confirmed the plugins work as expected before they reach your users. This way you can confirm "plugin X" works as expected before your users ever see it.

If you're suggesting keeping the plugins separate merely as a workflow optimization, then ignore the above paragraph. You might also want to check out automating the update build within wyBuild (see: Build Updates from Commandline)

I hope I've answered all of your questions. If I misunderstood you, or if you have followups, I'll be glad to answer them.

Wyatt