Frequently asked questions
Below are some of the more frequently asked questions about wyBuild, wyUpdate, and the AutomaticUpdater control.
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.
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.)
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:
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.