I have a C# app with its corresponding setup program. It reads startup data from the registry and stores information under the "Environment.SpecialFolder.ApplicationData"\myapp folder.
My question is: If I make various changes to the code that include new registry keys, where should I reflect this in the new version so when re-running the setup it:
Keeps current registry keys/valuesAdds new Key/value to the registryLeaves "Application Data" untouched
The candidates are:
Assembly InfoFile Version
If there are others please let me know.
Thanks
I think your application should be able to create the regestry keys. You don't know if the user removes them manually to reset the settings to default. The Setup should only install and register components. (But the Uninstaller should ask the User if he want to remove the settings, or keep them.)
Solution A)
To avoid version-conflicts you can remember a extra version number for configuration. As an Example: Program Version 1.0 and 2.0 are using the configuration-set 1 while Program Version 3.0 uses a configuration-set 2, because there are obsolete/new settings. Just create a sub-key in your registry tree for every configuration-set.
"Application Data" can also include a subfolder with seperated configuration sets.
The major advantage is, that the user can downgrade without problems.
New versions can import old values from older configuration as default values.
Solution B)
Never delete (or change the type or range) settings. Just add new keys. Old program versions don't know them so they just ignoring it. This is very simple because there are no different configuration versions. But if your saving a lot of settings it can become complicated, because you cannot change the type of a setting. As an example you have to create a new key to change a setting from saving an integer to a long integer, because old versions don't understand long integers and will crash.
Related
My C# application uses the default C# settings mechanism. The problem here is, that everytime I change my application's version number, all settings are gone and reset to their defaults.
Thus I implemented the upgrade mechanism described here.
Problem 1:
The weird thing is, that this seems to have no effect. After the upgrade code is executed, all settings still have their default values and none of the old values have been loaded.
Does the upgrade mechanism not work?
Problem 2:
Also after saving the settings, a new settings folder is created in AppData/Local (the name differs in the URI part). So after a couple of versions there are dozens of these folders lurking around, which does not feel right.
Is it normal behavior that an application creates new settings folders for each version?
I have a C# application that uses several user settings to store its data. When I increase the version number of my application, those settings are lost and reset to their default values.
That's why I implemented the following code
if (Settings.Default.UpgradeRequired)
{
Settings.Default.Upgrade();
Settings.Default.UpgradeRequired = false;
Settings.Default.Save();
}
as suggested here.
The problem is: the call to Upgrade() does nothing. It does not throw an exception, but it does not load any of the old settings either. Every setting still has its default value afterwards.
Also my new application version stores its settings in a new folder, right next to the old settings' folder.
Am I holding it wrong? ;-)
PS: I checked that an old set of settings is stored on the disk with reasonable values. So there should be definately something to work with for Upgrade().
Seems I found the solution. Since my assembly was not strong named/signed, a new hash was generated every time I updated my application. Thus old settings were not found and the upgrade did not work.
To fix this I signed my assembly using a .snk file. This way the hash now stays fixed, and the upgrade works.
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.)
I'm using .NET user settings feature and I'm facing a problem.
When the application is uninstalled, then installed back, the user settings are lost.
I understand it's by design, and I want to be able to give the choice to the user in the installer.
Could you please give me some pointers to articles or documentation that will helps me?
Thanks a lot
.NET User Settings are not removed on uninstall. In fact the settings of all previous versions of the software are preserved in Local Settings directory.
When the new version is installed, a new version of the settings is created and default settings are used.
To ensure your application will merge new settings with previous configuration, you have to call Settings.Default.Upgrade() method.
So the solution is to manually remove settings on uninstall if we don't want to preserve them. Since what I needed was preserving previous settings, all I do now is creating a new setting called UpgradeRequired with true has the default value, then add this code at application startup:
if (Properties.Settings.Default.UpdateRequired)
{
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.UpdateRequired = false;
}
You could possibly write the settings you wish to save out to the registry or write them as an XML file to a location that won't be impacted by the uninstall.
If you want to keep using User Settings i would suggest writing a custom installer class, and implement the onUninstalling method, to go find the file and copy it to another location known to the onInstall method of your custom installer. So that the next time the installer runs it could find the file.
I don't think you want to actually persist data on the users machine after an uninstall. Leaving files around is an evil practice, a big no-no. You should expose a feature in the application itself to either export those settings to a location of their choice and to then import it again after re-installing the app or to synchronize those settings onto a server so they're automatically available upon re-install, etc. On an uninstall you should leave no trace behind.
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.