I have an app that has search functionality. The search algorithm is compiled to a separate dll. In the C# code for the search algorithm, I am using strings held in a settings file to point to the directory where the search index resides. But once the search code is compiled, the settings file is somehow incorporated in the dll. I want to have multiple versions of this code running on my server with each pointing to a different location for the index. And I want the operator to change a file to have each version point to something else as they find necessary. Both config files and settings files end up getting incorporated in the dll. How do I then accomplish this? What is the right industry standard way of doing this?
It's strange that the settings file is compiled... are you sure about that? Setting, config and resx files should be copied to the output directory, it's even a property you can modify on solution explorer. Then you should get it's values by doing
System.Configuration.ConfigurationManager.AppSettings.Get("YourKey")
But I think this won't know about user changes until app is restarted. If you want settings to be dynamic you should either store them on a database, or on a file that you open, read and close every time you need it.
Hope this helped!
Related
I have to open a process.exe from a button_click event by known only the filename and the .exe extension.
Is It possible? In two words i need to make a game.exe library ,and if the filename.exe will be found the process filename.exe,
need to be started.
I want to avoid to ask the costumer the full path of the program location, and i dont want to use OpenFileDialog()for browse. Im three days stuck here. So
filename.exe=textbox1.text
SystemDiagnostic.Process(..).Start(filename.exe)
this will open only the file if the file and the debug program are in the same directory.
Do i need a recursive search, and if the file is found open the process?How do i search for the filename.exe in all the #"C:\?
Thank everyone Sorry for bad english.
If that file is deployed by you, like it is up to you to make an installer for it, you can add the containing directory of that file to the PATH environment variable, then you can simply launch it by
Process.Start(“filename.exe”)
Without having to specify the full path to that file.
If it is out of your control, but there is some trace about the location of that file, for example, if it is from a known vendor and the file has a default location or there is something like “InstallLocation” in registry for that file, you can query registry to get the full path then launch it.
Your last resort will be scanning the whole disk for that file. But this is too bad, unreliable and slow...and things can go wrong easily. I strongly warn you against this approach.
If you have to choose the last approach, you might find this post useful. Remember to check other attributes like version number, publisher, etc., in case you end up calling a wrong file happens to have that name.
Not sure I have the best title for this question. Feel free to modify it or suggest a change and I will do the edit myself.
I have a standalone executable which wants to maintain a settings.bin file specific to the application. There are two obvious ways to do it:
1. Create/Read the file from the local directory where the executable resides
Positive: User can copy the exe and bin file to multiple directories and have multiple versions with different settings.bin files.
Negative: I don't want to polute executable directory.
2. Create/Read the file from a "hidden" location like the Local Application Data folder.
Positive: Not poluting the executable directory.
Negative: The settings.bin file will be shared amoungst any instance
of the executable regardless of where it is locaed.
I don't want to do either of these solutions because neither meet both of my requirements, which are:
Don't polute the executable directory (IE: don't create a local file).
The settings.bin file is different based on the location of the executable.
Any thoughts? I wanted to embed the settings.bin file as a resource but quickly learned you can't write to an embedded resource. I'm all out of ideas.
Use option 2 with a small modification that cancels your negative point (not shared)
You must have something that you can differentiate between exe files.
If all reside in different paths I would do the following:
1) Hash the location of the executable (md5 of the path)
2) Create a directory in the appdata with the hash
3) Store my files there
Else I would try to enumerate myself compared to other processes:
1) When starting check the app data.
2) Attempt to lock a file for writing at:[App Data]\1\sem.oi
3) If that failed attempt to lock a file for writing at:[App Data]\2\sem.oi
Use the settings in the directory that you were able to open the file in
Hope this helps.
Well, you can define your configuration data into the application resource file like a sequence key-value pairs. In this way that information will be embeded into the your binary file, so hopefully you will meet the both of your requeirements.
no file created specially for configuration
and every file can have it's own built-in configuration, which means you have to made different builds in this case.
What about do not creating a file, but having a flexible configuration on local machine based on the exe path, I think it's hardly possible, if not via some network acess, and some bizzar (in my opinion) architecture.
If you would explain why you have these kind of requirements, may be can give more suitable answer, in case if it's not as is now.
So for example, when I load word, if I go to save a file, it will default to the same directory that I selected last time...Also, it keeps track of the last 10 (or whatever) .doc files you opened
how does it do this? Right now for a program I am writing (in C#), I just save a text document which holds these kinds of settings...is this bad practice??
If not, where should I put this text doc. Right now I am just using:
Path.GetDirectoryName(Application.ExecutablePath);
as the directory where this file is held...its fine before I publish the program, because it just uses one of the folders in the solution directory...
But after I publish it, the directory is really weird:
C:\users\me\AppData\Local\Apps\2.0\J6AAL16C.2QW.....
and it goes on....So is this like a directory created for this program when I install it?? is this where it SHOULD be getting saved?
Thanks!!
The Application Settings feature of .NET makes this pretty simple, really. In particular I wouldn't use the registry if I were you - it makes it harder for users to copy settings from machine to machine, etc.
It does get a bit weird if you try writing your own settings providers though - I've tried to understand the overall design a couple of times, and always got lost. For simple applications though, it's easy.
So I recently updated my application to support a new feature. In the past if the configuration file was deleted by the user it wasn't a big deal. This new feature requires it to exist, and one of the requirements is that, the file exists in the application's installation directory.
I have notice when the file is deleted ( depending on variables I have not figured out ) I get a .NET notification that the configuration file is missing or corrupt. Currently my program then crashes ( I still have to figure out how to duplicate this behavior ) which is the reason for this question.
I am familar with ConfigurationManager. I am having trouble writting the file once the default values are loaded. Forcing a Save for some reason does not seem to recreate the file, at least not in the installation directory, which is a requirement.
I am looking for guidence on how to handle this corner case in an elegant manner. I would post code, honestly its just all failed attempts, which while my attempts do generate a file the contents are not the settings I am looking for.
I am willing to post anything that might be able to help.
Stop using the built-in config support and just use write/read to a file called something.exe.config using the standard XML classes and if that gets deleted, just re-create it from values hard-coded in the executable.
The config file support is supposed to make things easier, if you need to do stuff where it makes things difficult, don't use it.
Something like
var wcfm = new WebConfigurationFileMap();
Configuration newConfig = WebConfigurationManager.OpenMappedWebConfiguration(wcfm, "/");
newConfig.Save();
doesn't work?
You dont. Under normal conditions the program can not write into it's install directory - this is a standard windows security issue and the reason why app application data should reside ni external (from the exe's point) driectories.
If an admin deletes the config file, crash, ask for reinstall. There is nothing you can RELIABLY do, as you can not assume you can write into the folder at runtime. A message followed by an event log entry is the best approach here. Users are not supposed to delete parts of the application.
I can't see anything on here but I do remember being told that If you want an application to update a config file then it needs to be under ...
**C:\Users\Ibrar Mumtaz\AppData**
Well somewhere there, the reason being is that the user should have permisions to update a config file here and not under the applications install folder. This is the impression that I am under and I'm fairly certain that this is definately the case. As I think I read that on here = p
My question is, is there anybody on here that can shine some light on this as this is the last feature I want to implement before I give my application out to test.
1) First thing is, an installer is needed to set up the folder and then drop my apps config file into it. I already am using the visial studio installer so I have my app packaged up but this point is throwing me off? How do I do this then? I just need someone to show how to do this and I should be O.K reconfiguring my app to look for the new home of the config file.
2) I should be able to work out how to find the folder and locate the config file found within it. As once I know the installer is chucking the config file out into the right folder where the user has permissions then it should be straight forward from there.
Thanks for reading.
UPDATE:
It was pretty straight foward, as the VS Installer has an option to add a special folder so all that was left was to access the folder programmatically and read and write to the config file. ONE PROBLEM? The ConfigurationManager class which I have used to create my config file for my application expects my config file to be local to the application and not miles away in a completey different part of the local FileSystem? Errr help here Plz?
Ibrar
If you are using the VS Settings file to create application setting keys, and have values that the user might want to change in runtime, and save his preferences, just set the scope of those settings to "User" instead of "Application".
That way you will have a setter method for them, and you can edit the Settings.Default instance, and when you are done call the Save() method to persist them to disk.
The file will be saved in the user's "AppData" folder, wherever it is, under some cryptic folder. But you needn't worry about it's location most of the time, since it will be read automatically on the next execute, and persisted to the same location on subsequent runs.
Afaik the installer can be extended with classes that do things.
On INSTALL-action to do could be to
var path = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData),
"My app name");
if (!Directory.Exists(path)) Directory.CreateDirectory(path);
And vice-versa on uninstall.
App.config files are related to where the physical assembly is located I think.
Actually, if your app is running on the user's machine- it will have whatever permissions that user has. So most likely, you can expect to be able to write anywhere on the file system.
However it is possible the user would be running under a restricted acct, and thus not have the permissions. So you could just use the registry to store where your config file is (install folder), then when you try to update it, if it fails for permissions, ask the user to grant it.
Or you could use the Windows standard folders, as you were getting at, because doing so also separates out user data from application data.
Use the Environment.GetFolderPath () method to get the 'special folder' paths in your app.
http://www.programmersheaven.com/2/Les_CSharp_15_p2
http://msdn.microsoft.com/en-us/library/14tx8hby.aspx
If you are talking about application settings found on project Properties -> Settings tab, then there're two different types of settings: user-level and application-level.
If you need to change any settings in run-time, these would be user-level settings (http://msdn.microsoft.com/en-us/library/cftf714c.aspx) and all changes would be buried somewhere in the private folder in your user profile.
If you want to update application-level settings, your best shot would be to do that during software installation. In this case you don't need to look for the configuration file (YourApp.exe.config) anywhere but in the application folder. More likely you would need to create some sort of post-install event handler in your setup package and run some script or another application which would update data in YourApp.exe.config. Everything in the setup package will be executed with elevated priviledges and thus that configuration file would be writeable. BTW, this scenario applies to 2000 and XP, if the user is using limited user account type priviledges.
Because I did not technically find the answer I was looking for, after 6 months I have come back to my application and have managed to produce a solution that does not break my current architecture.
If you are implementing an application to make use of some of the features on offer by the ConfigurationManager then it offers a static method called:
ConfigurationManager.OpenMappedExeConfiguration(); // takes two arguements.
It can be used like this:
ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
fileMap.ExeConfigFilename = returnUsersAppDataFolderPath();
Configuration config = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);
e.g
fileMap.ExeConfigFileName = #"some file path external to your applications install folder."
remember to use '#' symbol in front to allow the compiler to literally treat the string on as is basis.
If the config file can be conveniently locally located then just use the:
ConfigurationManager.OpenExeConfiguration(string exePath)
Above is what you would typically use but for me i needed my config file to located under the users AppData folder so the first option is what I needed. And it does indeed work.
I hope this helps others as it does for me as I want to deploy my application to Win7 and vista environments therefore this question needed asking if I was to stick to using the ConfigurationManager it's a shame the method of choice in the end never really stood out in the first place = ).
If you want to read from your config file then leave a comment and I will show you how I managed to do that also.