I am building a C# windows application.
I want it so whenever I click the update button in my form the application will Start looking for whether there is a new version avaliable on my Server.
If there is then proceed to update the Software.
How is this usually handled?
Take a look at Click Once. This thread might also make an interesting read.
Let me start by saying we offer a complete updating solution which includes:
An open source updater, wyUpdate, written in C#
The free AutomaticUpdater control that you can just add to your .NET app's form
wyBuild is used to build patches and manage your versions
wyUpdate handles all of the Vista/Windows 7 UAC problems and all the file permission problems that inevitably pop up when you're trying to update complex software.
That being said, if you want to build your own updater here are some tips:
Building your own updater
A good place to start is the wyUpdate C# source code I mentioned above. You can cannibalize it and use it for your own purposes. Some of the algorithms it contains:
Full Windows Vista / Windows 7 UAC support
Ability for limited users to check and then update if they have credentials
Support for wonky corporate inernet. (If you've ever worked with a corporation this is a real problem).
Quick extracting, patching, and installing of files.
Registry support.
Roll back files & registry on error or cancellation by the user
Self-update (no files left behind)
We also have the file specifications here.
Automatic updating
Since being automatic is a requirement let me tell you how we do it with our AutomaticUpdater control.
We use named pipes to communicate between the standalone updater (wyUpdate) and the Automatic Updater control sitting on your program's form. wyUpdate reports progress to the Automatic Updater, and the Automatic Updater can tell wyUpdate to cancel progress, to start downloading, start extracting, etc.
This keeps the updater separate from your application.
In fact, the exact named pipes C# code we use is included in an article I wrote a little while back: Multi-process C# app like Google Chrome.
If you want your app to be updated automatically from a website and handle the code by yourself do the following steps:
Create an XML file with a unique name for example help.xml and build a structure to specify the list of files to be updated in specific directories and version and etc. Then upload them on your website.
App after connecting to website downloads this help.xml file and reads the content to make sure there are any
new files (update files) on the website...
If a new version of files was existed so start downloading from URL specified in help.xml file!
Other answers look great.
However, if you're looking to hand-roll your own for whatever reason, simply put an XML file with information you need for your update process (e.g. description and version number of currently available version) somewhere on a webserver and use an HttpWebRequest (or HttpWebClient?) to download this file and process like you would any XML.
I use this simple method in peSHIr Tweets and it works great. Just update this file after you put a new version online for download and your update check will find it. Anything about this process is changeable the way you like, as you wrote it yourself.
Unless this is a private project for your own amusement/use/learning - like in my case - do look if anything already available suits your needs though!
Take a look: Update Checker, I have wrote it to show the easy way to implement this feature in C#.
This XML file manages the updates:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<myCoolApp>
<currentVersion>
<major>9</major>
<minor>1</minor>
<build>5</build>
</currentVersion>
<path>http://TestApp.exe</path>
</myCoolApp>
The main funtion Check4Update() reads the XML file and parse it:
XmlDocument oDom = new XmlDocument();
oDom.Load(_sXmlConfig);
string str = oDom.SelectSingleNode("//currentVersion/major").InnerText;
Int32.TryParse(str, out _nMajor);
str = oDom.SelectSingleNode("//currentVersion/minor").InnerText;
Int32.TryParse(str, out _nMinor);
str = oDom.SelectSingleNode("//currentVersion/build").InnerText;
Int32.TryParse(str, out _nBuild);
_sNewVersionPath = oDom.SelectSingleNode("//path").InnerText;
Related
Just as the title states, is there an Adobe equivalent to the Java deployment.properties file?
I am writing a c# application to test installations of application in our network. The top three on my boss's list are java, flash, and reader. I need to be able to find out what versions of each application are installed on a machine for the reports im going to generate (force the user to update/etc).
I know i can check version number and confirm the ability of IE to access my JRE by checking "\Sun\Java\Deployment\deployment.properties". What file would I check to confirm the same for adobe reader and flash?
Thanks in advance for any help given or links provided to more info.
edit: I need to do this from the browser.
This is not a very clean solution, but since the only "official" way seems to be to check it from the Windows registries perhaps this will help:
We know that the flash files are located are in the (windows directory)\system32\Macromed\Flash (or SysWow64\Macromed\Flash on 64 bit systems).
Each time a flash updates it keeps the track of the progress in the log files. Depending on the flash version you will either have a) install.log (very old versions of flash) or b) FlashInstall.log
a) If you browse through the file you see various entires and one type goes like this:WriteRegStr: "HKEY_CURRENT_USER\SOFTWARE\Macromedia\FlashPlayer" "FlashPlayerVersion"="10.0.45.2".
Now you can just go through that file bottom-top and match the "FlashPlayerVersion"= string to get the most recent version.
However, this is for a really old versions of flash and the install.log file never got deleted from this directory, so make sure you check for the FlashInstall.log too!
b) Use a similar approach, except the new install logs don't keep the "WriteRegStr" information. Now you can instead look for the dll file name itself, for example my last update created an install log 0009 [I] 00000014 C:\WINDOWS\system32\Macromed\Flash\NPSWF32_11_5_502_146.dll, meaning my flash version is 11.5.502.146
another options are to
check the plugin core files creation date and compare with the versions release dates (quite unreliable in case someone somehow manages to install an older version)
check the actual property of the NPSWF[..version..].dll file. You can see all the complete and precise version details in the "Version" tab. however, I don't know how to access the rightclick->properties from inside a script, so you'll have to find out by yourself if you decide to go for this option
ask the unicorns
I want to make my software autoupdate itself, but I don't have extensive webdesign skills, nor any available website/online hosting. I want to do it in C#/WPF.
So I was wondering if there could be a way to make an autoupdate service using google code, something clean. I'm guessing I'm not the first one to think of it.
I'd do it this way:
1) Use a WebBrowser (silently) and navigate to my google code page. On that page I'd put a field where I enter the latest version number. (I need to somehow find that number in the page's content).
2) I compare that number to the version currently installed (I could put the CURRENT_VER_NUMBER in a *.txt in the software's folder for example).
3) If I conclude that a new version is available, I download it from the "Downloads" tab of my google code project, unzip it, overwrite the files in the installation directory, and restart the app.
First of all, would that work fine? When I imaginate it, it sounds like dirty code.
Then, I wouldn't know how to navigate to the downloads tab, even less how to select the latest version there (maybe by doing a very strict file naming), and download it.
And last but not least, If the application is already running in order to perform the update check, I couldn't overwrite the files without quitting the application, does that mean I have to make some kind of "master app" that performs the check before starting my software? Sounds dirty too =/
Any input is very welcome,
Have a nice day.
I suggest you take a look at ClickOnce. It doesn't require you to create a webpage. You only need to host 2 files: a .manifest file that contains information about your app (version, name and a link to the package that contains your application) and the latest version of your application package. The only thing you need to do is host those 2 files and put a link on your Google Code page to that .manifest file. Users click that link and .net will automatically install or check for the latest version and update if necessary.
You may want to have a look at a library I wrote and released as open-source to do just that transparently - including an external update application to do the actual cold update. See http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/
The code is at http://github.com/synhershko/NAppUpdate (Licensed under the Apache 2.0 license)
I ran into a few problems, but overall it was not so hard. I think the approach is clean so I'm putting it out there if anyone ever wants to achieve something similar.
You'll have to check out: https://code.google.com/p/theomniscientchimp/ where the full source is available, and of course adjust it for your project.
Thanks for the comments on my original post, made me feel confident i was doing it right =)
Greetings,
I'm sorry if this question has been asked already. I've tried using the search function but couldn't find any answer that suited my situation.
I have a real simple C# form application of only 1 file, a exe.
I distributed this currently by 4shared where people can download it as pleased.
However, every time I make changes to the program people will have to download the new version from 4shared.
Now this isn't a ideal situation and I'm a noob when it comes to creating upgrade but the situation I wish is that the program looks at a website / ftp server where I deploy a new version.
I'm looking for a way inside my program to look at the file on that website / ftp server and decide wether there's a new version available.
If there is a new version available in the website / ftp server I would like for the program to update itself to the newest version.
Hope you guys can help me out with this and I hope I explained my situation enough !
NetSparkle is a nice alternative to click-once with more deployment options. http://netsparkle.codeplex.com/
Have a look at ClickOnce. It will do this for you.
When I'm developing and publishing such applications, I usually do it the following way:
Develop a .NET Windows Forms application
Develop a tiny ASP.NET application with an ASMX web service.
Publish the ASMX web service to my public web site.
Add a WSDL reference for the web service to my Windows Forms application.
Create a setup (I prefer Unicode NSIS over ClickOnce).
The logic I implement in the SOAP web service is basically a single function:
[WebMethod]
public string CheckUpdateAvailable( string currentVersion )
{
...
}
The Windows Forms application calls this method (e.g. from a background thread upon program start), passing its current assembly version as a string to the function.
The WSDL function in turn checks the passed version against the newest setup version (e.g. being stored inside web.config or extracted live from the setup.exe on the server). If a newer version exists, it return a string with the URL to download from; otherwise it returns NULL.
When the caller of the WSDL function gets a non-NULL string, it can show a message to the user, asking whether he wants to download and install the executable and then simply execute the URL (via Process.Start).
WyUpdate is the way to go here. We've been using it for over a year with great results (they have excellent support too).
It actually uses patches to update files so that when a 5MB executable only has a small change, the client only has to download a file in the order of kilobytes.
They supply an automatic update component for either Windows Forms or WPF that looks nice and works great.
You can host the update files on either an FTP server or a normal website without any server-side configuration.
There's plenty more to it, and the best place to start is with their video tutorial of how to set up an update.
Here's an open-source library I wrote to address specific needs we had for WinForms and WPF apps. The general idea is to have the greatest flexibility, at the lowest overhead possible. All you'll have to do is create an update feed and reference the library from your app.
So, integration is super-easy, and the library does pretty much everything for you, including synchronizing operations. It is also highly flexible, and lets you determine what tasks to execute and on what conditions - you set the rules (or use some that are there already). Last by not least is the support for any updates source (web, BitTorrent, etc) and any feed format - whatever is not implemented you can just write for yourself.
Cold updates (requiring an application restart) is also supported, and done automatically unless "hot-swap" is specified for the task.
This all boils down to one DLL, less than 70kb in size.
More details at http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/
Code is at http://github.com/synhershko/NAppUpdate (Licensed under the Apache 2.0 license)
I plan on extending it more when I'll get some more time, but honestly you should be able to quickly enhance it yourself for whatever it currently doesn't support.
I have a system with two web applications, one web service, one Windows service and a WPF application running 24 hours a day on a touch screen. All of them are connected to a database.
I want to be able to upgrade all of those applications by uploading upgrade files to the database and set the date and time for the upgrade to occur.
I have one idea on how to do this.
An application has a thread running to look for available upgrades.
When an upgrade is found, the file is downloaded to the application's computer.
When download is complete, the applications triggers a restart.
When application starts, it looks for an upgrade file on the local computer.
If upgrade is available, the application upgrades itself.
I'm not really sure how all these steps should be done yet, especially the last one. But I want some comments about this. Is this completely wrong? Am I on the right track? Any tips on how to do it like this or in another way?
I think you're going down the right lines here. A polling application to check the database for the existence of a new update followed by an xcopy deployment script would do it.
This might be doable from a PowerShell script too, that runs on a schedule, say every 10 minutes. It could check the database, close the process and service, xcopy the application (from a shared source) and restart the said service and app.
All this assumes that you are not using Windows Installer to package and deploy your application initially. Although an xcopy to directly replace binaries wouldn't hurt an MSI package, it's not recommended. We use AD MSI deployment at work and it's a pain at the best of times!
MSDN contains references for MSI vs XCopy deployment for WPF applications (as well as the security requirements).
This was the first link I found for querying SQL from PowerShell: http://elegantcode.com/2008/03/27/discovering-windows-powershell/
Good luck!
You will have trouble doing this with ClickOnce. ClickOnce would only work for your WPF app, it can't do anything with the services or web application. You could write a separate ClickOnce-deployed "Updater" app whose job is to update the other apps, but that still seems a little iffy.
It may sound stupid, but I'd start with the simplest thing I could think of. How about using Dropbox to push your update files; then an AutoHotKey script that runs on startup, watches the Dropbox folder for new updates, and runs them?
Sounds hokey, but it's something you could prove out in an hour or two.
Microsoft have an Updater Application Block which might be what you are looking for.
Do you really want to run an update from the database or is this just a possible solution? You are reinventing the wheel.
Have a look at ClickOnce deployment, everything you need is already done for you and integrated into VisualStudio. If you use something that already exists you have the benefit of existing documentation, helpful blogs of people who have already gone through the pain points and updates and fixes.
ClickOnce Deployment
ClickOnce Deployment in .NET Framework 2.0
How you want to use ClickOnce depends on what you want to get out of it. Out of the box you can very easily create a deployment that checks for an upgrade every time you run the application but you can also with a little bit of code have the application check for updates whilst it is running.
The Updater Application BlockVersion that Dominic Zukiewicz mentioned is the pre cursor to ClickOnce.
EDIT
ClickOnce provides a roll-back scenario on both the Server and Client end. The client can roll back to a previous version using the normal add remove programs dialogue and you can easily republish a previous version.
You could create another Windows Service that does the updates on a daily basis. The service would look on a specific folder if there are any updates to be process. For example it could look for an xml file which tells it the new version of the application and what the files to update are. It would shut down the application/services, backup the files that it needs to update, start the application/services, and clean up backup files keeping at least three backup files. The service should keep track of the last and current version installed so that when it reads the xml file it can check if it is a new update or not or you can simply delete the xml file when it completes.
How about Google Omaha? It's an open source tool, currently used to push updates of Google Chrome and Google Earth. Omaha can handle application installation, too. A high-level design overview can be found here.
I need to create a patching routine for my application,
it's really small but I need to update it daily or weekly
how does the xdelta and the others work?
i've read around about those but I didn't understand much of it
the user shouldn't be prompted at all
Ok this post got flagged on meta for the answers given, so I'm going to weigh in on this.
xdelta is a binary difference program that, rather than providing you with a full image, only gives you what has changed and where. An example of a text diff will have + and - signs before lines of text showing you that these have been added or removed in the new version.
There are two ways to update a binary image: replace it using your own program or replace it using some form of package management. For example, Linux Systems use rpm etc to push out updates to packages. In a windows environment your options are limited by what is installed if you're not on a corporate network. If you are, try WSUS and MSI packaging. That'll give you an easier life, or ClickOnce as someone has mentioned.
If you're not however, you will need to bear in mind the following:
You need to be an administrator to update anything in certain folders as others have said. I would strongly encourage you to accept this behaviour.
If the user is an administrator, you can offer to check for updates. Then, you can do one of two things. You can download a whole new version of your application and write it over the image on the hard disk (i.e. the file - remember images are loaded into memory so you can re-write your own program file). You then need to tell the user the update has succeeded and reload the program as the new image will be different.
Or, you can apply a diff if bandwidth is a concern. Probably not in your case but you will need to know from the client program the two versions to diff between so that the update server gives you the correct patch. Otherwise, the diff might not succeed.
I don't think for your purposes xdelta is going to give you much gain anyway. Just replace the entire image.
Edit if the user must not be prompted at all, just reload the app. However, I would strongly encourage informing the user you are talking on their network and ask permission to do so / enable a manual update mode, otherwise people like me will block it.
What kind of application is this ? Perhaps you could use clickonce to deploy your application. Clickonce very easily allows you to push updates to your users.
The short story is, Clickonce creates an installation that allows your users to install the application from a web server or a file share, you enable automatic updates, and whenever you place a new version of the app on the server the app will automatically(or ask the user wether to) update the app. The clickonce framework takes care of the rest - fetching the update , figure out which files have changed and need to be downloaded again and performs the update. You can also check/perform the update programatically.
That said, clickonce leaves you with little control over the actual installation procedure, and you have nowhere close to the freedom of building your own .msi.
I wouldn't go with a patching solution, since it really complicates things when you have a lot of revisions. How will the patching solution handle different versions asking to be updated? What if user A is 10 revisions behind the current revision? Or 100 revisions, etc? It would probably be best to just download the latest exe(s) and dll(s) and replace them.
That said, I think this SO question on silent updates might help you.
There is a solution for efficient patching - it works on all platforms and can run in completely silent mode, without the user noticing anything. On .NET, it provides seamless integration of the update process using a custom UserControl declaratively bound to events from your own UI.
It's called wyUpdate.
While the updating client (wyUpdate) is open source, a paid for wybuild tool is used to build and publish the patches.
Depending on the size of your application, you'd probably have it split up into several dll's, an exe, and other files.
What you could do is have the main program check for updates. If updates are available, the main program would close and the update program would take over - updating old files, creating new ones, and deleting current files as specified by the instructions sent along with a patch file (probably a compressed format such as .zip) downloaded by the updater.
If your application is small (say, a single exe) it would suffice to simply have the updater replace that one exe.
Edit:
Another way to do this would be to (upon compilation of the new exe), compare the new one to the old one, and just send the differences over to the updater. It would then make the appropriate adjustments.
You can make your function reside in a separate DLL. So you can just replace the DLL instead of patching the whole program. (Assuming Windows as the target platform for a C# program.)