I have a C# application (a VSTO office addin) running on clients' machines, and I need to make a setup project or any other EXE that can overwrite and update the user settings in the user.config files with my own values.
It seems that I can't know exactly where the user.config is- it seems to create different folders under AppData\Local\Microsoft_Corporation with different names and numbers. I can try to iterate every subfolder I find but I was hoping for something better.
I can't get the path by using ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal) because I'm not inside the application, and I tried it inside the application and it actually returned a different, wrong path.
I can overwrite the app.config because I know where the application sits, from the registry, but overwriting it doesn't change user settings if the user settings were already saved in user.config too.
Can I force .NET to write the user.config into a predetermined location and store it in the registry, so I would have it for my setup?
Any ideas how to complete this objective? Is there some common practice for this? Thank you
Don't update the settings from your installer. The installer can save new options locally (HKLM, local folder, etc.) visible to every local user. When your addin is loaded, it can grab the new settings from that location and update its local settings as necessary.
Related
I have a C# program with various setting stored in the program project settings. As it is a command line program, these settings will be changed by the user in the user.config file. I can't work out how to force it to save all the default values.
Calling Properties.Settings.Default.Save(); only seems to work when I update a property in the program, which defeats the point of a persistent settings file.
If I run
Properties.Settings.Default.SomeSetting = "Help";
Properties.Settings.Default.Save();
In the config file I will see something like
< setting name="SomeSetting" serializeAs="String">
<value>Help</value>
< /setting>
What I want to happens is if the config file doesn't exist, create it and store all the settings. Then the user can change them if needed.
The way I managed to solve it was by modifying some existing code I had in a different project to handle version upgrades.
When the program runs:
if (PropertiesSettings.Default.UpgradeRequired)
{
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.UpgradeRequired = false;
Properties.Settings.Default.Save();
reloadSettings();
}
// Assign settings to themselves and save
// This keeps settings the same as the defaults even when upgrading but ensures all settings appear in the config file
private void reloadSettings()
{
Properties.Settings.Default.Setting1 = Properties.Settings.Default.Setting1;
Properties.Settings.Default.Setting2 = Properties.Settings.Default.Setting2;
//etc
Properties.Settings.Default.Save();
}
The UpgradeRequired setting should be set to True by default, so a new version with no config will be forced to run the first if statement. The .NET Properties.Settings.Default.Upgrade(); should then take care of finding old config files and loading the old settings.
Settings are saved somewhere in user AppData folder specifically for a given process. For example, when the application is run under the debugger, you get different settings than when running stand-alone.
I would guess that there is no easy way to share settings across application using those properties settings. That code is quite old (.NET 2.0 or even before) so I think it is not designed to be easily customizable as it is often the case with more recent code.
I think that settings are good for things that are specific to a given application and if data need to be shared across application, then you should manage your own files.
Usually, one would use either XML or JSON based file and the data would be stored (by default) either under a subdirectory of My Documents if the data is intended to be visible to users or under a subdirectory of user application data directory if a regular user should not see those files.
I've noticed that if you move that application .exe file in another location the user settings reset.
In my understanding this happens because the location in the app data folder is based on the path of the .exe as well, which is taken into consideration when the hash is being generated.
I know there are different alternatives, either by using the registry or by creating manually a custom config file, but my question is, is it possible to retain the user settings when the application (.exe) is moved to another location with the default functionality Microsoft provides ?
For my tests I use a standalone application (one .exe file only). Simply moving the file to, lets say /Desktop/Test/ from /Desktop/ causes a new folder to be generated under C:\Users\<user>\AppData\Local\<company>\Appname_Url_<hash> with the default user.config in it. The old user.config is still available so if you move the .exe file back to its previous location then the previous settings get loaded again. This becomes troublesome not only because you lose the settings, but if you move the file 10 times in 10 different locations you end up with 10 new folders in the appdata.
This is in fact a security feature, related to assembly deployment and clickonce stuff.
I think you just need to add a strong name to the main assembly to overcome this issue.
If you don't have a strong name, the name will be something like this and it will change if the application path change (see the Url token):
%appdata%\WindowsFormsApplication1\WindowsFormsApplication1._Url_3pei3cdnq3srqpjiwh1qnf12ncsp5c2w\1.0.0.0\user.config
If you have a strong name it will be something like this and it will not change because your app origin is now identified, whatever its current location is (see the StrongName token):
%appdata%\WindowsFormsApplication1\WindowsFormsApplication1._StrongName_fe0ndyau2vlgeac4gmbg13u3q4jtyrqv\1.0.0.0\user.config
From this blog post, regarding the location of the configuration file:
If you need to store the settings in a different location for some
reason, the recommended way is to write your own SettingsProvider.
Which tells me that with a little bit of code, you could probably store the file right where you want it, and it won't move.
I would like to know how Windows generate folder, where will be ClickOnce application installed.
In Startmenu is "shortcut" to file, what is putted in some "startrek" folder like:
C:\Users\USERNAME\AppData\Local\Apps\2.0\GT??4KXX.PRJ\EGV???1G.??C\prin..tion_7???5a2?????74b6_0000.0002_1dae????89111c35
What does those folder names mean?
For example:
If i will have for example some settings.txt file where i want that user can change some parameters of the application. Is there way how to know, WHERE it will be installed and WHERE the file is? (Where user will find this settings.txt file).
I know that i can create the file for example in C:\ and after start the application i will modify the file in "strong" path. But i dont really like too much files, folders, whatever in C:\ and i prefer to have settings files in same folder like the application. But with ClickOnce installations is it really hard - impossible - to find that file.
It seems like when the "startrek" is something like hash of the project.
So i would like to know what does the folder means and if its some hash of the project or what is that.
To find the folder that contains your executable, you can use the Assembly.Location property.
For example:
string exeFolder = System.Reflection.Assembly.GetExecutingAssembly().Location;
However, if you want to store settings for your ClickOnce app, you shouldn't do it by writing a file to the .exe's folder.
Instead, you should use Microsoft's Application Settings support. Doing it any other way is going to be a lot of extra hassle, and Microsoft's support is very good. It does need half an hour to read through the documentation, but it's far and away the best thing to do, IMHO.
(I'm assuming that you only need the settings to be stored on the local PC for the same user to use later. If you want the settings to follow the user around (i.e. roaming settings), you can't use the Microsoft support.)
If you have more complex settings that you want to store in a file that you create directly, you should consider using the isolated storage that the answer from JRoughan mentions.
From inside the ClickOnce app you can find the default directory where files are stored using
ApplicationDeployment.CurrentDeployment.DataDirectory
Or you can use isolated storage and choose whether you want to save per application or per user.
I don't think it's possible to determine these folders from outside the app itself. If you need a known location you'll have to hard-code it.
Update
I also don't believe it's possible to infer what the install directory will be for an app. It would be unwise to use even if possible as updates to the app will not be in the same location.
If you have data that the user is modifying through your program, you will be happier if you don't leave it in the ClickOnce program directory. You can get completely messed up when there's an update. Check out this article about what to do with your data to keep it safe and be able to find it. It talks about putting it in LocalApplicationData, but if you want your user to be able to find it and edit it, just put it in MyDocuments/yourappname/settings or something like that.
I wouldn't use Isolated Storage; there are reported problems with that and ClickOnce.
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.
I need to store log files and configuration files for my application. Where is the best place to store them?
Right now, I'm just using the current directory, which ends up putting them in the Program Files directory where my program lives.
The log files will probably be accessed by the user somewhat regularly, so %APPDATA% seems a little hard to get to.
Is a directory under %USERPROFILE%\My Documents the best? It needs to work for all versions of Windows, from 2000 forward.
If you're not using ConfigurationManager to manage your application and user settings, you should be. The configuration toolkit in the .NET Framework is remarkably well thought out, and the Visual Studio tools that interoperate with it are too.
The default behavior of ConfigurationManager puts both invariant (application) and modifiable (user) settings in the right places: the application settings go in the application folder, and the user settings go in System.Environment.SpecialFolder.LocalApplicationData. It works properly under all versions of Windows that support .NET.
As for log files, System.Environment.SpecialFolder.LocalApplicationData is generally the place that you want to put them, because it's guaranteed to be user-writeable.
There are certainly cases where you wouldn't - for instance, if you want to write files to a network share so that you easily can access them remotely. There's a pretty wide range of ways to implement that, but most of them start with creating an application setting that contains the path to the shared folder. All of them involve administration.
I have a couple of complaints about ConfigurationManager and the VS tools: there needs to be better high-level documentation than there is, and better documentation of the VS-generated Settings class. The mechanism by which the app.config file turns into the application configuration file in the target build directory is opaque (and the source of one of the most frequently asked questions of all: "what happened to my connection string?"). And if there's a way of creating settings that don't have default values, I haven't found it.
Note: You can get the path to the LocalApplicationData folder in .NET by using the following function:
string strPath=System.Environment.GetFolderPath(System.Environment.SpecialFolder.LocalApplicationData);
For application settings - use System.Environment.SpecialFolder.ApplicationData - this is where a roaming profile data is stored, so it allows your user to log and work from different machines in the domain.
For log files - System.Environment.SpecialFolder.LocalApplicationData
The accepted answer notes that for log files the following is a good spot.
System.Environment.SpecialFolder.LocalApplicationData This equates to a path of C:\Users\[User]\AppData\Roaming which you can see is user specific. Like the accepted answer mentions this is a guaranteed user-writeable location and can be useful for certain situations
However in a web application environment you may be running your application under a network account and you or a coworker may need to try and track down where exactly those logs are going per application. I personally like to use the non user specific location enumeration of
System.Environment.SpecialFolder.CommonApplicationData which equates to C:\ProgramData. Yes, you will need to specify access rights for any folders you create, but it's usually a one time deal and then all of your application logs can live in one happy location.
Additionally, while looking around the Internet, there is a project out there to programatically set write access to folders you create within CommonApplicationData, Allow write/modify access to CommonApplicationData.
To be honest %appdata% is still the best place to place your config files and log files, as it serves the purpose of a placeholder to store your application data. It should not be that hard to access, just write %appdata% in explorer and you will be directed straight to your %appdata% directory.
Do not store config files in the application folder, Microsoft has stated this is NOT the ideal location. Windows has been moving towards blocking writing to C:\Program Files\ and you'll find in Vista any application that tries to write here, will fire up a UAC warning.
Windows 7 will allow users to customize what UAC popups they use (expect some power users to block most of them) and your app will fail/freeze if the user never approves this write attempt.
If you use the proper userprofile and appdata variables, then Win 2000, XP, Vista, and Win7 will map the data to the proper write friendly folder, with no UAC popups.
You can use SHGetSpecialFolderPath:
int MAX_PATH = 255;
CString m_strMyPath;
SHGetSpecialFolderPath(NULL, m_strMyPath.GetBuffer(MAX_PATH), CSIDL_COMMON_APPDATA, TRUE);
This will specify the 'special folder path' which you can safely write logs to for windows:
For XP: C:\Documents and Settings\All Users\Application Data
For Vista: C:\ProgramData
Check the MSDN page here: http://msdn.microsoft.com/en-us/library/bb762204(VS.85).aspx
The best answer depends on the nature of the logs and configurations. If they are program-wide, and don't need to survive uninstallation of the application, then I think they're fine where they are. If the logs and configurations are user specific, or need to survive uninstallation, then they belong somewhere under %USERPROFILE% - %APPDATA% being the 'proper' base directory for this type of thing.
I use the Isolation Storage for configuration. You can also use the Temp folder to store temporary information like log.