Develop Reference

Get version information for C# application with InstallSheild LE installer

I have a C# program that I want to deploy with InstallSheild LE. I know how to make a setup.exe file to install the application and I know how to create a new installer that can upgrade a current installation.
Currently, I have my application get its version number from the installation log. It checks its version number (which is initially and empty string). If the version number is a an empty string, the application goes to the %TEMP% directory and reads the newest installation LOG file looking for the line that states the installation was successful and the line with the version information. The version information is saved in the application settings and used to detect if upgrades are available. To detect an update, it compares its version number to the version number of the setup.exe in the update location (on a network drive).
This implementation works, however, there are a few aspects of this that worry me and i would like to know if there is a better way to tell the application what version it is and saving this information (preferably not in a file that can be deleted). Obviously, the information would need to be update-able and preserved between runs. Ideally, I would like to be able to internally set the version number in my C# application without having to make assumptions about files being created, or file locations, etc to get it.
Thoughts??
I appreciate your suggestions!

I found that the easiest way was to hardcode the version number in the application. I then would preform a check, during program execution, for the version of the installer in the update location on the network drive. If the version of the installer in the network drive was greater than the hardcoded version in the application, the program would download the new installer, execute it via another process, and close the application so that the necessary files could be updated.

In order to do this you pretty much have to hardcode something in addition to the update location. The question then becomes what's best to hardcode. Here are some ideas, assuming that your installation's ProductVersion property contains the version you need to compare:
The version in question, per your answer
The ProductCode of your installation
A registry location (specific to major versions)
The UpgradeCode of your installation series
A registry location (independent of major versions)
Those, in order, are each less likely to change than the one before it, and it should be trivial to have the installer write its version into a chosen registry location (put [ProductVersion] in a registry key's value) so that's my recommendation. Then the only required update is to change ProductVersion when you update your installation.
There is one other approach that could work without any special a priori knowledge. I'll sketch it out in Win32 API because I'm not familiar enough with the DTF wrappers:
Use MsiEnumComponents or MsiEnumComponentsEx to look at all the installed components on the machine - this could take a while
Use MsiEnumClients or MsiEnumClientsEx to identify the product (or products) that installed each component
Use MsiGetComponentPath or MsiGetComponentPathEx on each product-component pair to identify whether that pair installed your exe file (the location from which you are currently running)
Use MsiGetProductInfo or MsiGetProductInfoEx to retrieve the ProductVersion; if there was more than one client, you'll have to decide how to handle it - perhaps by using the largest version
(If you hardcode the UpgradeCode you can use MsiEnumRelatedProducts in place of steps 1-3; if you hardocde the ProductCode you can jump directly to step 4. Typically you only need to call the Ex variants if you need to search per-user installations.)

AutoUpdate using Google Code

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

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?

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

Updating a desktop application without touching the attached .mdf

Just a quick question:
I'm in the finalizing state of my current C# project, and I'd like to send a version out to people that has 90% of the features initially requested, but it'll be a version of the software that will do all they need - they need the software as soon as possible, basically.
Therefore I'm going to be using the online install option in VS2008 that will use updating to add the final few features, as well as additional things, later. What I'm wondering is the following:
The program will come packaged with a .mdf file. When I create a new version of the program however, I don't want to change all of the data that has been added to the database already. My question is how do I go about doing this?
Thanks!

How are you planning to distribute the update? An installer will have flags indicating when a file should be replaced. (Date, version etc)
One-Click installation has the ability to check for changes on program startup.