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 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.
Hide the slow steps
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.
Going against better advice: completely silent updater
You've read the previous 3 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.