Not really done this before so I wanted a few pointers.
In my app, users are able to pick a folder that the application looks in when it is started to pick up some input files.
What is the best way to save this information between sessions.
the old fashion way I would have done in the past would be to have a config.ini file and read and write to that the path. However I am sure there are better ways now.
I don't want to have to write to the registary as I want a app that can be installed and uninstalled simple by copying a folder or deleating the folder.
Is there any way to save configuration settings that the uesr can update and remian constant between sessions?
Cheers
Aaron
AFAIK, the way is done now, is by writing these values to the Application.Settings file; however, that's not too different than writing to any XML file and reading it on startup. Either alternative is almost equally simple.
As Icarus said, you need a .settings file. You can specify that settings be Scoped to the User.
You can also look into using IsolatedStorage ( http://msdn.microsoft.com/en-us/library/x7dzh4ws.aspx ).
Related
I have a scenario in my application is that i need to upload some files (Zip files) from the client to the server and in the server i want to extract the Zip file and replace those files which i getting from extracting the Zip file into some other folder.
The files which i need to be replaced is mostly dll files. So one thing that i need to ensure that either all files should be replaced or none of them get replaced.
Is there any way in C# to achieve this (like Transaction in SQL) ? If anything bad occurs while replacing files (Example: no memory space), every changes happened to the previous files should be rollbacked.
Hope you understand the problem.
Any help ?
NTFS allows file system transactions, see https://msdn.microsoft.com/en-us/magazine/cc163388.aspx
Having a quick poke around, only way I can see you doing this would be through https://msdn.microsoft.com/en-us/magazine/cc163388.aspx which involves some native code. Otherwise you could use a third party tool such as http://transactionalfilemgr.codeplex.com/
If you wanted to manage it yourself or go for a simpler approach, I would suggest backing up the existing files somewhere before trying to copy the new files. This could be in another folder or zipped up. Then if the copy fails, you handle this and revert all the files to their original state.
Whatever you choose, make sure you have plenty of logging so you can see what's happening and if/when something goes wrong :)
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 am new to C# , i wrote one application its contain directories and some file , i dont want to edit these file from outside of the program or manually , plz tell me how to do that if u provide the code that will be very usefull.
Thx
There is no real way to protect from within the application. If you're storing these files on a file system, they will be accesible based on file system permissions. You could store information in a password protected database or something similiar in order to make it only accessible to the application.
Actually on second thought, you may be able to save these files within a resource bundle. I'm not sure if that is entirely protected though.
You can set the read only attribute. It is only a minor inconvenience to someone who wants to edit a file, but you haven't got much control over what a user does outside of your program. At least if a user clears the read only attribute and changes your file you can blame them for it.
System.IO.File.SetAttributes("path\\file", FileAttributes.ReadOnly)
Are you just reading from these files or writing to them? If you're just reading them, you might embed them as resources in your compiled output rather than keeping them as files on disk.
http://support.microsoft.com/kb/319292
Is this even possible?
I realize that asking them to enter data when the program runs and saving it in the executable file itself is out. (Or is it?)
Right now I'm considering trying to build the program server-side with php and have it incorporate a separate text file which would contain the information. This seems marginally feasible, though I would have quite a bit of learning to accomplish it.
I was hoping for some other ideas of how I might accomplish this.
I am not interested in separate configuration or text files or putting data in windows registry. I am only looking for solutions where it can be quite-solidly a part of the executable.
Does anybody have any experience with this?
Thank you.
Its perfectly possible, that's how self-extracting zip files work.
Basically, you can add as much stuff to the end of the executable file as you want. Your program can then open its own file up on disk and read it back.
How about using Settings within your app? It depends on what you mean by "storing the user registration" as to how you would best achieve this, though. If you could give some more information about what you actually want to store, that would be useful.
An example would be to save a username, or an authentication token, and use that each time you need to check a "registration". As I say, though, the details of what to store would depend entirely on what you want to do it that data...
You could use it to embed in the unmanaged resources.
I want to store settings for my C# application, such that default setttings can be easily shipped with my binaries and the end-user can change them using a simple text editor(or in some other simple way).
I seem to face several alternatives : a .config file, .settings file or a .resx file. What are the pros and cons of these?
Edit1: End-users are computer professionals mainly, so editing these files should not be much of a problem.
Edit2: The settings are something like connection strings, and some other parameters (mostly one-time stuff). Building some kind of GUI/API for changing them is not really an option. Also my application will not edit any of these values, so persistence through code is not required.
Yes, Project + Properties, Settings tab was designed to do this. Add your settings here, change the Scope to Application. That generates a app.exe.config file in your build direcctory, deploy it along with your EXE. Use Properties.Settings.Default.SettingName in your code to obtain the setting value. Your user will normally need admin privileges to edit the .exe.config file on the target machine to change the setting value.
The small print: settings do not work well for DLL assemblies, you have to merge the .config files by hand. When using the debugger, settings are retrieved from the app.vshost.exe.config file.
The .settings file is a helper file used by the IDE, ignore it. .Resx files store resources, they get compiled and embedded in a binary form in an assembly. They are not editable by the user.
I think you can have two ways of doing this.
For regular users, you can make a custom GUI that will make it simple for them to use.
For advanced users, they can edit the configurations using a text editor if it's stored in a text file (ini file, config file, etc..) or you can make an API.
The .settings file is typically used for user-specific preferences and configuration information (whereas the .config file is used for global settings for the application or anything that modifies the .Net runtime. Simply putting parameters in a .config file can alter the behavior of your application even without you writing a single line of code for it).
Check out the Settings article on MSDN for more: http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx
Since the file will be modified by the users, I think using app.config is not a good idea. What if they break the file structure? Or set an invalid value? Probably your application will crash directly.
One of the solutions would be to use a custom XML file. You will then validate it when your application starts. XSD will probably be the more elegant way to do it, but you can also parse it directly and validate it in code. If the file is invalid, instead of crashing, you will try to solve the problem, and if impossible, display a pretty error to the user, explaining that there is an error in XML at line n, position n, which is [error description here].
If the end user is really going to be editing them, I'm not sure I would want them editing my app.config file.
You have another couple alternatives that you haven't included. You could use an old-school .INI file that is simpler for an end user to understand. You could also use the registry. I would recommend the INI file, unless your users are very savvy, in which case use the .config file.
The answer depends on the deployment method. For instance, if you are using ClickOnce and offer updates, you might encouter problems using Application Settings.
I believe the best way to go is to create a GUI, something that is most certainly suitable for novice users. Given that you already excluded that option, use John's suggestion (ini files).