- Getting Started
- Install wyBuild
- Video Tutorial
- Step-by-step walkthrough
- New release workflow
- Basics
- FAQ (Frequently asked questions)
- Executing files
- Registry changes
- Distribute wyUpdate
- Translate wyUpdate
- Silently Check for Updates
- Silently update Windows Services
- Requirements
- Automatic Updater
- AutomaticUpdater intro
- Tutorial for Windows Forms apps
- Tutorial for WPF apps
- Tutorial for Windows Services
- AutomaticUpdater Members
- Translate the AutomaticUpdater
- About
- Changes in 2.6.18
- Advanced
- Build from Commandline
- Encrypting updates
- Commands and Variables
- COM dll registering / unregistering
- Custom wyUpdate Version
- Download sites
- Limit or prevent updates
- Offline updates
- Override the Server Site
- Proxies in wyUpdate
- Services (start / stop)
- Signing Updates in wyBuild
- Version Numbers
- wyUpdate Commandline
Frequently asked questions
Below are some of the more frequently asked questions about wyBuild, wyUpdate, and the AutomaticUpdater control.
How wyBuild compares versions of your software
Let's say you have 2 versions in wyBuild: "1.0" and "2.0". There are some files that are the same between versions, some files that have been updated, some files that are new in version 2.0, some files that have been removed in version 2.0, and some files that you don't want updated at all. Also, let's say you correctly followed the step-by-step walkthrough and added all files from each version into wyBuild.
When you click "Build updates" in wyBuild, it scans all of the files at the byte-level to create the smallest possible patch. This is what it does in the different cases:
Unchanged files
When wyBuild detects that the same file is unchanged between versions it doesn't include the file (or a patch of the file) at all as part of the update. wyBuild knows nothing has changed with the file and knows not to waste space on it.
Changed files
When wyBuild detects that the same file is different between versions it generates the smallest possible patch to go from the file in the previous version to get to the file into the newest version. It does is by comparing the files on a byte-by-byte level (sometimes called delta compression). This is roughly what it looks like when behind-the-scenes:
When wyUpdate installs the update, and if the file that is to be patched has been modified by the customer from the "original old version", then wyUpdate won't be able to patch the file, and thus use the catch-all update instead (if you've allowed catch-all update files to be built).
New files
When wyBuild detects that a file exists in the new version that didn't exist in the old version, then wyBuild includes the file as whole (since there's nothing to generate a patch against).
Removed files
When wyBuild detects there's a file in the old version that doesn't exist in the new version then wyBuild includes instructions in the update patch to delete that file when updating to the latest version.
Files you don't want wyUpdate to touch
If you have a file that you don't want changed, then remove the file from wyBuild in all versions of your app.
So, for example, if you have a "Configuration.xml" file in version 1.0 of your app, that you don't want wyBuild to touch at all, then remove the file from both versions 1.0 and 2.0 of your app. This way, when wyBuild is creating the patches for your application, and when wyUpdate installs the patches, the "Configuration.xml" file will be completely ignored.
Also see FAQ: What's the best way to update config files?
Where is the version number stored?
The version number for your product is stored in the client.wyc file (see below). wyUpdate doesn't parse your exe's or other files for the version number. Every time you app is updated wyUpdate updates the version number stored in the client.wyc file.
Also see the new release workflow.
What's the best way to update config files?
Configuration files are a special case inside wyBuild. You should exclude configuration files altogether so that they're not touched at all (not added, removed, or patched), and instead handle configurations (and their defaults) directly inside your application.
The reason you'll want to exclude config files altogether from the updates is because, by their very nature, configuration files are meant to be changed by the customer. That means a patch file that wyBuild generates to go from an old version of the config file to the new version of a config file won't be able to be applied to the customer's version of the config file because it has been changed from your version of the old version of the config file. And, as described in "FAQ: How wyBuild compares versions of your software", when wyUpdate fails to apply a patch to a file because it has been modified by the customer to a file that wyUpdate cannot patch, wyUpdate then just rolls-back the update and tries to install the catch-all update (the larger update file), and thus over-write any customer changes to the config file.
There is absolutely no way wyUpdate can "use intuition" to apply patches to config files such that your new defaults are applied while simultaneously keeping the user-made changes to the file. It's an impossible problem to solve in a universal manner.
There are 2 ways to handle configuration files:
You can generate / update / apply new defaults directly within your application. Merge defaults and user configurations however you'd like. This is the best approach.
Or you can take the approach many open source projects take and provide a "config-defaults.xml" file that is never loaded by your app, but is instead copied by the customer to a "config.xml" file where they can make their changes to the file. So, you provide updates to the never user-changed "config-defaults.xml", and the user is responsible for migrating any new configuration options over to their own "config.xml" file.
wyUpdate says "You already have the latest version" when it isn't. What's wrong?
The current version number is stored in the "client.wyc" file. wyUpdate doesn't try to parse your files to find a version number, it just looks at the version embedded within the "client.wyc" file.
When you click "Build wyUpdate" the latest version of wyUpdate.exe is copied to the folder and the latest version of your app is embedded in the "client.wyc" file. Or you can choose another version to embed in the "client.wyc" file by clicking the drop down control:
The reason why wyUpdate might say "You already have the latest version" when it isn't is that you might have been testing your updates while reusing the same "client.wyc" file. You shouldn't do this. Every time wyUpdate updates your program it also edits the "client.wyc" file with the newer version of your app.
The simple fix: rebuild wyUpdate and include the client.wyc with the correct version.
What's the "catch-all" update? Why is it so large? And why is it being downloaded?
When you build your updates in wyBuild you'll see there are a number of files being generated. A "wyserver.wys" file, and a number of "*.wyu" files. The *.wyu files are the actual updates. You'll see they're in the form "yourapp.OldVersion.to.NewVersion.wyu". These are the small patch files that patch your old versions to the latest version.
In addition to these patch files you'll also have a larger *.wyu file ("yourapp.all.to.NewVersion.wyu". This is the "catch-all" update. Instead of containing small patch files to get from a specific old version to the latest version, it instead contains full files necessary to update any of your versions to the latest version. This is why the file is so large.
Why is the "catch-all" update being downloaded?
The catch-all update is downloaded when a file fails to be patched. That is, the "old version" of the file is not what wyUpdate expects and thus wyUpdate can't patch your file to the new version.
How to detect which file is failing to be patched
The first thing you need to do see which file is failing to be patched is to disable the catch-all update. In your wyBuild project, go to "File -> Properties -> Update & server files" then uncheck the "Create a catch-all update" checkbox. Press OK on that window.
Then rebuild your updates (click "Build Updates"), upload the updates to your server again (if you're not using the upload functionality included in wyBuild then make sure you also upload the *.wys file along with the *.wyu files).
After you've done that re-run wyUpdate it will tell you exactly which file fails to be patched.
Why is the file failing to be patched?
The reason a file fails to be patched is always because the file that you've referenced in wyBuild (in the Files & Folders section in your project) doesn't match the file you've actually distributed to your customer. So, in wyBuild, in the old version tab (the version that's failing to update because of the patch failure), click the file that is failing to be patched. Look at the "Path on disk" and make sure the file being referenced is the exact same file that was used in your installer that you distributed to your customer.
Another reason a file fails to be patched is the file was modified by the customer.
What does the "client.wyc" file contain?
The "client.wyc" file contains all the details about your application. This includes the following:
- Product name
- Company name
- Your branding images for wyUpdate
- The XML translations of wyUpdate
- The sites to find your server files (the server.wys file). For example: http://example.com/updates/server.wys
- The current version of your software (the version string, e.g. "1.5 beta 2", not the list of files).
- The public sign key used for update signing verification.
Rebuild wyUpdate every new version
Everytime you create a new version, rebuild wyUpdate and include the newest "client.wyc" and wyUpdate.exe in your installer.
You should not include wyUpdate.exe in your updates — wyUpdate self-updates. The client.wyc file, however, can be included with your updates (especially if you change any of the fields listed above).
Why do I get a "404 not found error" when downloading wyserver.wys?
If you're using Microsoft's IIS (Internet Information Services) server, then you need to configure your server to send the ".wys" and ".wyu" filetypes with the MIME types of "application/octet-stream".
See "Do I need to configure my server?" to learn how.
If this doesn't solve the problem then make sure your updates are uploaded to your server in the correct folder.
Do I need to configure my server?
If you're using Apache, NGINX, or any other open source server, then no. By default the major open source servers deliver unknown file types as "application/octet-stream".
If you're using Microsoft IIS, then you'll need to configure it to deliver *.wys and *.wyu files as the MIME-type "application/octet-stream". To do this double click the "MIME Types" icon in the IIS manager. Then click the "Add..." link and enter the MIME type info for the .wys and .wyu files:
Afterwards you should have both the .wys and .wyu MIME types in the list:
Or, if you can't reconfigure your IIS server, you can change the file extensions to something your server can deliver. To do this open your wyBuild project, click "File -> Properties", then go to the "Update & server files" tab and change the file extensions from ".wyu" and ".wys" to ".zip":
What does "failed signature validation" mean?
When your user downloads your update they might get the following error:
The downloaded file "[filename].wyu" failed the signature validation: Verification failed.
This is the result of 1 of the following things:
- The file is corrupt on the server or was corrupted during the download.
- You rebuilt your updates but only uploaded the *.wys file or only uploaded the *.wyu files to your server. Upload all changed files.
- You built your updates with one project and built wyUpdate with another project.
The solution to the 3rd cause is to build wyUpdate and the updates with the same wyBuild project file. The reason you're getting this error is that you've built the updates with one signing key and the verification is done with another signing key (see: Signing Updates in wyBuild).
Can I update databases (Microsoft SQL Server, MySQL, etc.) as part of my update?
Yes, see the "Executing files in your update" article to learn how.
How can I completely hide the updater (wyUpdate)?
The short answer is you can do this but you shouldn't. For instance, let's say it takes just 40 seconds to update your app. If you start the updater hidden before your application starts then you'll confuse the user. The user will double click your app's icon then they won't see anything for 40 seconds because your app is updating without any user feedback. They'll be angry and will think your application is buggy, slow, or broken.
If we replay that scenario except this time the updater is visible and showing the user the progress of the update then the users will be well informed and glad you're updating your app for them.
Option 1: Hide the slow steps using the AutomaticUpdater
There are valid reasons to keep the slow steps of the updating hidden. For example, if your update is large or your customer's download speed is slow then you'll want to do the downloading in the background. This is where the AutomaticUpdater comes in. The AutomaticUpdater integrates within .NET apps and Windows Services to do "the slow parts" of updating in the background (checking, downloading, patching, etc.). Then, when the update is ready for the final installation steps, the wyUpdate wizard is shown and the update is completed.
Option 2: Eliminate user-interaction when using standalone wyUpdate
If you're not using the AutomaticUpdater — that is, you're using wyUpdate as a standalone updater — you still have the option of skipping past steps that require user intervention. We cover this in detail in the "How to Silently Check for Updates" article. For absolutely no user intervention the following 5 things must be done:
Install your app to a location limited users have read/write permission (e.g. the AppData folder, desktop, documents folder, etc.)
When checking for updates in your application use the "/quickcheck" argument along with one or both "/noerr" and "/justcheck". For example:
wyUpdate.exe /quickcheck /justcheck /noerr
You can read the exit code of wyUpdate to see if you're up-to-date, there's an update available, or an error happened. See "How to Silently Check for Updates" for a full example.
When you run wyUpdate, pass the "/skipinfo" commandline argument:
wyUpdate.exe /skipinfo
This skips the update information screen and immediately starts the update process.
- In your wyBuild project file, click File -> Properties -> wyUpdate, then check the "Close wyUpdate on successful update" check box:
- Select your application exe file to be executed after the update. Uncheck the "Wait for execution to finish before continuing" checkbox.
If you follow all of these steps then your update process with require absolutely no user interaction. Plus you have the side benefit of the user being well informed about the update process.
If you choose not to follow the first step (but follow all the others) then your customer might be asked for admin user credentials (or UAC elevation) if the user doesn't have the necessary permissions.
Option 3: Going against better advice — completely silent updater
You've read the previous paragraphs and you're still determined to completely hide the updater — what's next? You'll need to make a Windows Service that will handle the updating. See one of the following articles:
"But Google Chrome does completely silent updates without using Windows Services, why can't you do that?"
Google Chrome's updater, Omaha, is tailored just for Chrome and it's a fantastic updater for that specific app. However, as a "general purpose" updater it's pretty lousy.
The reason the Chrome auto-updater is able to install a new version while an old version of Chrome is running is that they install it to a completely different folder. Then, the next time you start Chrome the new version starts immediately (because it was already installed).
The reason we can't mimic this behavior with wyBuild, wyUpdate, and the AutomaticUpdater is that we can't make the same assumptions about normal apps. For instance, let's say your app is installed in C:\Program Files\Your App\. We can't just silently install updates to that same folder while your app is running (Windows doesn't allow it — not without a computer restart). Neither can we install the new version of your app to a separate folder (e.g. C:\Program Files\Your App 2\) because your app might be dependent on your original installation location. For instance, if you use registry, COM registrations, Windows Services, or a hundred other features in your app then you can't just install your app to another folder.
"OK, so what's the best way to update our app completely silently? We don't want the user to even know there's an updater for our app."
The best way to do completely silent updating right now is to make a dummy Windows Service in either C# (see AutomaticUpdater tutorial for Windows Services ) or any other language (see How to Silently update a Windows Service). The service doesn't have to do anything except update. We have an example Windows Service written in C# included in the AutomaticUpdater source code.
Coming in wyBuild 2.8 will be a fully written Windows Service that handles all the details of silent updating.