Changing update server

Yes, this is possible. Change the server site, rebuild wyUpdate (which will give you a new client.wyc file), include this client.wyc file in your update.

Now, when the user updates to the latest version the new servers will be used.

excellent - i was hoping that was the case!

Can this be changed programatically?

For example, can you pass in an alternative update server at runtime when calling wyUpdate.exe. I am testing out your software this week. My challange is that I distribute my software as a webapplication with a rich client. I want each rich client to know which webserver it belongs to. To have to build a new wyUpdate for each distribution would be too much of a burden.

On another note, can you pass in the EV (end version) from wyUpdate? For example. I only want to update from version 1.2 to 1.4 when versions 1.5 and 1.6 may also be available. This is in order to give the webapplication administrator a degree of control when updates are distributed to end users, especially if I can't pass in or easily change the update server. Then I can use a global update server and allow the local administrator determine what version they update to. Primarily to stay in sync with the version of webcode that they may be running.

Thanks.

Can this be changed programatically?

For example, can you pass in an alternative update server at runtime when calling wyUpdate.exe. I am testing out your software this week. My challange is that I distribute my software as a webapplication with a rich client. I want each rich client to know which webserver it belongs to. To have to build a new wyUpdate for each distribution would be too much of a burden.

Passing the alternative server isn't possible at runtime (at least not currently). But I want to get a better sense of how you're distributing your software.

Are you dynamically creating unique software per customer? And then each unique software bundle has its own updates? Is that why creating a new *.wyc file is too much of a burden?

(By the way, the client.wyc file is the file that's modified. So the wyUpdate.exe would be constant across your product line, the client.wyc files would be different)

On another note, can you pass in the EV (end version) from wyUpdate? For example. I only want to update from version 1.2 to 1.4 when versions 1.5 and 1.6 may also be available. This is in order to give the webapplication administrator a degree of control when updates are distributed to end users, especially if I can't pass in or easily change the update server. Then I can use a global update server and allow the local administrator determine what version they update to. Primarily to stay in sync with the version of webcode that they may be running.

Thanks.

No, it's not possible to do this dynamically. You can do it manually on the Build screen in wyBuild by selecting a version range you want to build:

[attachment=0]wybuild.version.range.png[/attachment]

But to allow administrators to choose which version they want to update to currently isn't possible.

Wyatt,

Thanks for the quick response.

Our software is distributed on appliance. The industry we work in often has limited internal technical support often relying on contract labor for IT maters. In order to have a tight control over the information we distribute our appliacation on appliance. This keeps our code and their data safe and secure without any "cross polination" on shared database servers. We include the Operating System, SQL embedded licenses, BizTalk embedded runtime and other features. So it is truely a turn key solution for the customer. The appliances come to the customer direct from the wherehouse with the drive image of everything preloaded. We then run scripts from pre-installation survey templates to populate their data. In the future we are going to work on a distributed version that is a virtual image but still includes all the same software.

Since the rich desktop client (a WPF program) is installed from the web application it is pre-loaded with the web application. We could still do a wyc update on a per install basis as this is often a workflow change or our customers and we are onsite for installation. However, depending on the size of the corporation they may have multiple facilities which are configured on a single appliance and each one may have different WPF client update needs in terms of the timing and training related to the rollout. Someday we will also offer an ASP model in which none of this will really be an issue.

I can easily get ahead of the wyUpdate.exe in the rich client code and check a webservice or database value before triggering an update to run (to the latest as it stands now), so I could allow them to not update but stay on the previous in this fashion and let the administrator have some control. I can also prgrammatically re-write the wyc file with the appropriate update server during installation and hope it doesn't get overwritten during subsequent updates.

I suppose I could have the webapplication move the current update folder to a different location and then have the code re-write thw wyc file on the rich client dynamically based on a database setting and so it would then find the desired version instead of the latest version... but being able to pass the value seems a bit easier. I just started to look at the wyUpdate source code posted on Google and it seems this may be possible.

However, passing in an override for the update server and desired version would be a cleaner option.

Thanks again.

So if we implemented an argument to wyUpdate like:

wyupdate.exe -server="http://example.com/server.wys"

To add "http://example.com/server.wys" exclusively to the server list, would this work for you?

Yes, that would work. I hope you would give a targeted upgrade version some consideration as well.

such as: wyupdate.exe -version="1.7" -overwriteversion

obviously this would need to work in conjunction with a server argument as well.

This would be used in a situation where you are running version 1.5 and want to go to 1.7, but 1.8 and 1.9 are available. This could be for any number of reasons, like you don't want certain users to go to that release yet (lack training, require other prerequesites, etc.) This would allow us to release major code updates to our appliances without having to worry about the indivdual user. That can be controlled by local application administrators.

Thanks for your consideration. I look forward to testing your software the next few days.

Yes, that would work. I hope you would give a targeted upgrade version some consideration as well.

such as: wyupdate.exe -version="1.7" -overwriteversion

obviously this would need to work in conjunction with a server argument as well.

Actually, once we add the -server argument to wyUpdate (which we will add in 2.0.5) you can do this on the server side. That is, build updates from each version range you want (1.0 to 1.1, 1.0 to 1.2, 1.1 to 1.2, etc) and a separate server.wys file is created for each.

Then, on the server, put them in separate folders, e.g. http://example.com/updates/1.1, where you'll store the server.wys file along with all the updates to 1.1.

It's just a matter of passing the server file to wyUpdate, then:

wyupdate.exe -server="http://example.com/1.1/server.wys" -overwriteservers

Great, I see your point.

Not pressing; because I have been impressed with your responsiveness, but what is your release cycle? What is your ETA for 2.0.5? It isn't too big a rush for me, because we are just finishing our Beta testing at a partnering facility, but this is one of the issues that has come up and it now seems you will have a good solution for my case. You can glean a bit more of our situation from my other post.

Thanks for your help.

What is your ETA for 2.0.5?

Likely by the end of next week. Around July 10th or July 13th.

Wyatt,

I've gone ahead and purchased 2 licensed copies of wyUpdate, and thank you for your product. I greatly appreciate your quick addition of the update server arguments to the wyUpdete code, that really sealed the deal.

I am looking for a suggestion on an issue however. In all my testing everything went fine with passing the update server argument. I do this all in C# and call the update process from my code; and it works very well. However, what I noticed is that once I got to an update that I applied to a pilot site server, but hadn't deployed to our main server; the update got through the information about the latest update (loaded wyserver.wys) then failed to find the file, because the wyserver.wys file told it to go back to the main server. You see, I had only been building the patches with the main server URL, but then had been deploying the updates to individual servers. My application would pass in the update path from database values using the wyUpdate.exe arguments and it would hit those servers wyserver.wys file and then redirect to the main server, as long as I was putting the updates there too everything worked fine.

I suppose that this can continue to work for me, I just need to publish the updates on the main server and not the client servers. Putting the wyserver.wys file on each server works, but is in fact not even necessary at this point either; because they always end up pointing to the main server, and I can still control the version they can update to in the database of each individual client. There are a number of reasons why keeping it all localized is a good thing including reducing update traffic to my main server site and adhering to corporate policies related to individual computer updates through corporate firewalls.

That all said, is there a way to allow wyupdate to overwrite the path to the server update files in the wyserver.wys file the same way it is doing to the client.wys? Without the later, the feature you've added really has limited purpose.

I would think that this is possible considering you download the wyserver.wys file on each update prior to calling the update file path. Perhaps this can be accomplished by recording the file names relative to the passed URL or writing a generic root relative path as a "server" similar to adding multiple update servers.

Thanks

I think I understand what you're saying. It's that you want to host your *.wys files on a separate site than your host your *.wyu files.

If that's what you mean, then we already have that ability cooked into wyBuild:

[attachment=0]wybuild.distribute.png[/attachment]

You can specify which sites are which directly within wyBuild. This way wyUpdate check for updates by downloading the file from the "http://example.com/%file%" server. Then, if updates are found, the updates are downloaded from the "http://server2.example.com/%file%" server.

You can change your servers to be whatever you want, obviously.

Is this what you're looking for?

Sorry for the confusion I was describing too much in my previous post (and I'll probably do it again here).

Thanks for the screen shot. I hadn't used that menu yet so it is good to know about, but NO; that IS in effect what I am doing now by using the overwriteservers argument. The problem is the ability to pass in the wyUpdate event arguments to override the server gets trumped for my purposes if the same argument is not handed off to the downloaded server.wys file.

If I run:

wyupdate.exe -server="http://example.com/server.wys" -overwriteservers

it correctly points wyUpdate to http://example.com/server.wys, but when the actual server.wys file is downloaded to the client to process the update paths, the update paths are still directing to the original location. In a corporate environment the server that the original server.wys file may have been built against is not necessarily accessible due to proxy and other firewall settings. Having the overwriteservers argument is great to be able to direct users to their correct server on the fly, but it only is viable if the server.wys file can also direct them to updates on that same server.

If it would be possible for the same -overwriteservers command to work on the server.wys file that would be awesome. Maybe if in creating the server.wys file you introduced a new variable like %url% where you could create a download server that is http://%url%/updates/%file% where the %url% is going to be equal to -server (host URI only) of the overwriteservers argument.

I tried to do string substitution with C# on the "0" file in the server.wys, on the fly, but I ended up getting some other strange error about a newer version being available (it was), but not having an update available for the version I was running (which there was). There are other issues with this as well like keeping on top of it for future updates.

What do you think? Is this possible, or do I just need to beg the network admins to let the network traffic go out to a centralized server on the Internet?

BTW: even if there is nothing else that can be done now on this option, having the -overwriteservers is a life saver for me because individual admins can now set the update path in my web application and it allows for them to control which version their desktop client users update to; which is stellar!

The first thing I want to say is that you don't need to add the "-overwriteservers" flag. It doesn't do anything. I know I mentioned it in another thread, but I was just throwing out ideas.

You can just use:

wyupdate.exe -server="http://example.com/server.wys"

And the server overwriting will be implied.

Also, I want to clarify how the server files work. The unzipped server file (the "0" file) contains a list of the location of update files in the range you specify, along with a checksum of each update file. It's not in text format, so a search & replace won't work. (If you're really interested, we have the file specs).

So if you build the updates from version 1.0 to version 1.3, with intermediate versions 1.1 & 1.2, and a "catch all" site like this:

[attachment=2]simple-server.png[/attachment]

Then the server will be hardcoded in the client as: http://example.com/server.wys. You can override this using that -server switch on wyUpdate.

The update files will be hardcoded in this server file as something like:

• http://example.com/yourproduct.1.0.to.1.3.wyu
• http://example.com/yourproduct.1.1.to.1.3.wyu
• http://example.com/yourproduct.1.2.to.1.3.wyu
• http://example.com/yourproduct.all.to.1.3.wyu

I'm still a little foggy on how you're building & distributing your updates. Let me describe your process as I see it:

• Building sets of updates, each set goes from 1.0 to X (where X is the variable of the future update version)
• Uploading each separate set of updates to its own server (or at least want to) along with the server file.

For example you want to build 2 sets of updates

• Set1: build one set of updates from 1.0, 1.1, 1.2 to 1.3
• Set2: build one set of updates from 1.0, 1.1, 1.2, 1.3 to 1.4

Let's also say you want the Set1 update files on server1.com/%file%, and Set2 update files on server2.com/%file%. Before building anything, you need to modify the sites:

[attachment=1]updates-to-1.3.png[/attachment]

First thing you should notice is the icons. The server file icon is used for the server-only site, and the update file icon is used for the update-only sites.

Also note that since you're overriding the servers anyway, it doesn't matter much what you put in there. Just remember to always override wyUpdate with the -server switch.

Now you're ready to build the 1.0 to 1.3 updates. The built "server.wys" file will point to the updates located on the "http://server1.com/%file%" site.

Now you're ready to build the second set of updates (1.0 to 1.4). First edit the update site to point to server2.com/%file%:

[attachment=0]updates-to-1.4.png[/attachment]

Now build your updates to 1.4.

Then, of course, upload Set1 to server1.com, Set2 to server2.com. Put the server files wherever you want and make sure to use the -server switch on wyUpdate.

Is this what you're looking for, or am I completely misunderstanding you?

P.S. Sorry it took so long, it took about an hour to think this all through and type it up.

No you understand me. I am deploying the files in incremental and catch all forms to each of the appliances. I am using the -server override to pass in the argument of where the server.wys file is. The server.wys file itself has the paths to my primary server in them, which ultimately will work as long as the network bosses let the traffic go out for my clients. However, my experience has been that once the server.wys file comes to the client and the update version information is displayed the wyupdate program attempts to download the file from the original location not where the arguments are pointing to. I wonder if this is due to my mistake of passing the -overriteservers at the end of the command. I never caught that it no longer applied and it seemed to be working how I had it. At any rate I'll change my command and test a few more times. No I shouldn't need the spec for the file format, but thanks, you are saying it should work, so I am probably doing something wrong.

Wyatt you said: "First edit the update site to point to server2.com/%file%:"

To me this sounds like that once the server.wys file is created it is static. I can work around that but that is not what I was trying to accomplish.

Per your example:

I create server.wys file that points to http://example.com/

The update files will be hardcoded in this server file as something like:

http://example.com/yourproduct.1.0.to.1.3.wyuhttp://example.com/yourproduct.1.1.to.1.3.wyuhttp://example.com/yourproduct.1.2.to.1.3.wyuhttp://example.com/yourproduct.all.to.1.3.wyu

I deploy the client.wys file and wyupdate.exe with my software on a client computer that connects to a client network bound web application server. Let's call it http://clientserver.com

On each client server I drop off multiple server.wys files in an update directory. This makes sense when you consider I am updating all the web application servers each with unique names pretty much at the same time. Please note that the web application is not being updated by wyUpdate, only the companion desktop application is.

http://clientserver.com/update/1.0/server.wyshttp://clientserver.com/update/1.1/server.wyshttp://clientserver.com/update/1.2/server.wyshttp://clientserver.com/update/1.3/server.wys

Now remember that the server.wys was built against http://example.com, so each client getting an update gets the following argument passed to it.

wyupdate.exe -server="http://clientserver.com/update/1.3/server.wys"

the server path is determined by settings in the database set by the local application administrator so they can control which version their users are updated to.

then when the server.wys file comes back to the end user and the update paths are unpacked from the zip file the get directed back to http://example.com/yourproduct.1.2.to.1.3.wyu which will work as long as I've put updates on example.com and the users computer isn't blocked from going out to the internet or having other proxy interference.

You see what I am suggesting is that the update path be altered the same way the server path can be altered with command arguments. -

e.g. wyupdate.exe -server="http://clientserver.com/update/1.3/server.wys" -update=http://clientserver.com/update/yourproduct.1.2.to.1.3.wyu

Otherwise I'll just have to make it a system requirement that client computers be able to access a centralized update server and bear the burden of all the update traffic myself.

No you understand me. I am deploying the files in incremental and catch all forms to each of the appliances. I am using the -server override to pass in the argument of where the server.wys file is. The server.wys file itself has the paths to my primary server in them, which ultimately will work as long as the network bosses let the traffic go out for my clients. However, my experience has been that once the server.wys file comes to the client and the update version information is displayed the wyupdate program attempts to download the file from the original location not where the arguments are pointing to. I wonder if this is due to my mistake of passing the -overriteservers at the end of the command. I never caught that it no longer applied and it seemed to be working how I had it. At any rate I'll change my command and test a few more times. No I shouldn't need the spec for the file format, but thanks, you are saying it should work, so I am probably doing something wrong.

Adding "-overriteservers" doesn't do anything good or bad, it's just dead weight. wyUpdate just ignores it.

I don't think I explained the different type of sites correctly. I'll start by telling you how files are downloaded.

Building wyUpdate - Server Sites

When wyUpdate is built (after clicking "Build wyUpdate") the location to the *.wys file is stored in the *.wyc file that you distribute with wyUpdate.exe. In this example, the first two sites are embedded in the *.wyc file:

[attachment=1]server.png[/attachment]

The first site is always checked first. If there's an error (404, corrupt file, etc.) the second server site is tried. These sites can be overridden (as you know) using the -server switch.

Also note that the 3rd site, the update site, is ignored in this step. It's not built into the *.wyc file & wyUpdate doesn't know or care about it.

Building Updates - Update Sites

When you build your updates the *.wys file is generated alongside the many *.wyu files. The locations to the *wyu files are stored in the *.wys file. In this example the first and last sites are included in the *.wys file:

[attachment=0]updates.png[/attachment]

That is, if you have only one update (e.g. yourproduct.all.to.1.1.wyu), the two sites that will be included in the *.wys file are:

• http://generalsite (aka. wys & wyu files)/yourproduct.all.to.1.1.wyu
• http://updatesite (aka. just wyu files)/yourproduct.all.to.1.1.wyu

The first site will always be downloaded first. If an error occurs (404, corrupt update, etc.) the second site will be tried.

Putting it all together

What's my point? You're not limited to keeping the *.wys & *.wyu files on the same server. Just delete the general site, and include only a server site & an update site.

• Specify the server site (the site that's built into the *.wyc file, a.k.a where wyUpdate will look for updates) to point to your main server.
• Specify the update site (where the *.wys file will point to your new updates, *.wyu) to point to your auxiliary server.

I really hope I'm understanding your problem.

I completely understand what you are saying. You can't change the path to the update files, except when creating them and making a build.

However, what I am saying is that it would be nice if you could do that on the fly, just like you do it for the server.wys URL. This would allow folks to keep traffic internal to a corporation and not have to worry about proxy or egress rules. I can certainly work with what I have, but I won't ever be able to create update sites for each server that gets deployed, nor would I want to.

Oh, I see. That's a bit beyond the scope of wyBuild & wyUpdate. I think if we were to add ability to make an update switch for wyUpdate (e.g. -update="") it would add unnecessary complexity.

This is a problem that can be solved server side. It almost sounds like you're looking for load balancer. Or at the very least a 301 redirect.

It isn't for the purposes of load balancing or redirect. Think of it as a distributed update model (think WSUS); but one where I don't want to have to create all iterations of the update server on the front end but rather let it be data driven from the application. I can work with this limitation. The default may actually be better until I have a case of blocked internet access at a client site. Perhaps someday you will have time to revisit this question. I'll personally take a closer look at the wyupdate source in Google and see what may be involved to dynamically substitute the update path for the wyu files at the time the wys file is read. If I work something out, I'll share it with you. Thanks for all you patience in answering these questions.

It isn't for the purposes of load balancing or redirect. Think of it as a distributed update model (think WSUS); but one where I don't want to have to create all iterations of the update server on the front end but rather let it be data driven from the application. I can work with this limitation. The default may actually be better until I have a case of blocked internet access at a client site. Perhaps someday you will have time to revisit this question.

We probably will. Maybe in the 3.0 range of wyUpdate & wyBuild. Automatic updating is taking priority, though.

I'll personally take a closer look at the wyupdate source in Google and see what may be involved to dynamically substitute the update path for the wyu files at the time the wys file is read. If I work something out, I'll share it with you.

You might want to start at the LoadServerFile(bool) function in frmMain.cs. It's around line 805. Just set a breakpoint there and step through the loading of the server file.

Also, you might be interested in the Parse Variable functions in InstallUpdate\InstallUpdate.cs (starting around line 883).

Thanks for all you patience in answering these questions.

It's no problem at all. If you have any more questions I'll be glad to answer them.