Develop Reference

autoupdate c# program

Suppose i have a program.. how can i accomplish this?
i want the program to have an update feature. so its like,, when i posted a new version in the ftp server, the old program searches the ftp server and if theres a new version, it will download the new program and delete the old ones.
thank you
PS: it can be the user presses the update button, then the program will download the contents to one temp directory, then deletes itself and transferring the new files to the current folder
or it can be an auto update, like the program checks every 12 hours.

You can achieve this using ClickOnce.

You could end up using a pre-executable that performs the update. Starting the application not with the main exe, but with one that performs the update and then launches the main app. The main app checks for update and downloads it, but actually is not doing anything more than that.

Your options are either ClickOnce, which is the superior option of the two, or create a windows service that does the updating for you. The service runs all the time and pols for updates, downloads any and installs them. The reason this is superior to a preloader as suggested by Sascha is that in an environment where users log on with low level privileges the service will have admin privileges and be able to update the application.
Having said this, ClickOnce is the way to go.

C# Cannot write to Application.ExecutablePath, some boxes i can some i cannot? uninstall from this

So I have been writing to
Environment.SpecialFolder.ApplicationData
this data file, that upon uninstall needs to be deleted. I am using Innos Setup to build my installer. It works great for me. So my data file hangs out in the above path and I do that cause when I used to try to write it to
Application.ExecutablePath
certain boxes I tested it on would throw a nasty error at me trying to write data there. I do research and somehow its not always writable and its how i came up with the Environment.SpecialFolder.ApplicationData
That is why my data file now resides in the SpecialFolder.ApplicationData. Trouble is if the user uninstalls and reinstalls I need that file gone. It might be a short coming of my knowledge of Innos but I cannot figure out how to know where that file will be to tell innos that.
So then I thought I had a clever solution: Innos can run a file when its done uninstalling, so I had my program create this file "uninstallData.bat" that says:
del "the file in my special folder application data path"
and I wrote it out to drumroll
Application.ExecutablePath
(yes it was a while in development and I had forgot it was't doable.)
So of course I am back to square one, I need to write a file to a path Innos knows about {app} and I need it to be able to delete my data file in the SpecialFolder... i don't care how I do it i just need that file gone.
Are there other Environment. or Application. approches I have missed? Maybe somewhere that is viewable by an uninstaller AND can be written to?
As an aside, I am not sure why my box I develop on can write to the application folder no issue, but it cannot on other boxes... weird.
Any input would be great sorta lost as to how to crack this nut.

The environment location is in the user profile. If there are multiple users on the machine, and they all run the application then a copy of the file will be in each profile.
The path also depends on the OS.
Regardless, the current user's app data location is pointed to by %APPDATA% and %LOCALAPPDATA%. These Windows environment variables should be available within Innos.

Appliccation.ExecutablePath is not writable per standard defintions - the program files folder should never be manipulated by running applications. Ther area number of special folders for that. Nice that you finally found.... what is properly documented by Microsoft for a LONG time now (minimum 10 years).
I suggest you get a proper installer - WIX comes to my mind. Your problem is totally unrelated to C# - it seems to be totally a "crappy installer" issue. Or provide a PROGRAM (not bat file) to run at uninstall. What exatly is your problem there?

Automatic update

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.

Patch an application

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.)

How can I make my C# application check for updates?

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;