i have some variables in an app like :
public int temp = 10 ;
Is there a way that i can modify my temp variable so that my temp variable will contain on restart of the app the last value that was stored in it ? I would like to do this without a config file.
(i.e. i would like at some point to modify my temp like : temp = x; where x is an integer and after i close my app and launch it again,the temp variable should contain x and not 10 )
Well it doesn't have to be a "config" file, but it's clearly got to persist the data somewhere. Modifying the executable itself seems a rather drastic approach, to be honest... common storage options include the file system and the registry... what are you trying to do that wouldn't be adequately solved with those more conventional approaches?
You need to persist this value somewhere. Depending on the type of application you are developing (WinForms, ASP.NET, ...) this somewhere might vary. For example if this is a Windows application you could use the Application Settings.
I wouldn't recommend doing this for a production application but if it's just morbid curiosity then I suggest you have a read at this tutorial: Modifying the IL at runtime. It's not a tutorial that I've managed to get all the way through but a while back I was interested in playing with IL/CLR and tinkered with this.
Anything you want to use it for in production should persist in the variety of available storage options you can use: config files, database, file system, registry, etc. Modifying the executable is a big thing and shouldn't be considered lightly.
You can use the Settings object in the application to handy read/store values
It seems there's a security reason for your question.
If you don't want to have the data on disk (even encrypted) and the computer would not be restarted, another process can hold the value for you.
There are many options for inter-process communication but you need to pass data encrypted.
Sounds like you're looking for Orthogonal Persistence. There are very few programming languages that support such feature. And I think there is no mainstream languages that support Orthogonal Persistence. Ref: Orthogonal Persistence article.
For C#, you must at least use config files,registry, or database.
Related
I have a list of store information.
Each store has a region, a zone, and a store number.
The way I've been doing this now is:
I have a Store class, and a List with elements type Store.
In each application, I have to add this long list of StoreList.Add(new Store() { ... }), which looks bad, is sloppy, and totally not convenient. So I was looking for a way to use this information across multiple solutions/projects.
I don't want to use a database because I don't really want additional overhead in what could be simple scripts. Is a DLL something I would use in this circumstance?
You said you don't want to use database, but probably its not a bad choice. You can store the information in a XML file and read that on application startup. Having such information in a class and then dll, would complicate things. If you have to modify a store number, you have to deploy that dll on computers running your application, although modification in XML would be required on computers as well but it would be easier IMO.
Also if you have that information in some central database and loads up that information on application start event, it would provide you a much better option of maintaining your application and having lesser changes in client side / deployment.
The problem is not whether you want a database or not, but if you need to store your data once your application closes.
Now, you can use a database (could be an embedded one) or a file (xml most probably).
If all your data is stored in code (not the best option really) then yes, you can move that code to a class library project and distribute it wherever you need it.
But still, at the very least this is what i'd do
Move your list items to an xml file
Create a class that reads this file, and loads it into the list
Add the xml file to your project and mark it as an embedded resource (so it'll be packed with the dll)
You can read the xml file from the assembly directly (check here on SO how to do it)
Hope that helps
I have a C# app that uses a DLL I made and I have to store 3 variables inside the DLL that have to be constant so I can get them later even after the user closes the program (I need to get them every execution after I write the data to the DLL). I want to store them inside the DLL because I don't want to use the registry or use any external files so I was thinking of using a Resource file within the DLL to read/write my static data to.
Can anyone give me an example of how to use the resource data like this or suggest another way to do this without declaring hardcoded variables (which I cannot do), or using the registry/external data files to store the information.
I would suggest using Isolated storage to write your data. You can have a quick start here.
Use a regular memory mapped file. Writing to binary executables is bad practice and many (if not all) OS-es will prohibit that in all but the most promiscuous security policy settings.
PS. The popular term for this kind of storage is 'database' (or program database). This should help you get a few google hits.
Also, depending on your preferred method of implementation you can use memory-mapping to overlay your data-segment (so you can have your cake and eat it: keep you global static data where it is and easily commit them to disk). However, this is more in the C/C++ spirit.
In .NET you'd have to use a giant custom-layout struct (meaning, all reference types are out of the question - this is more unnatural in C# than it is in, say, C++)
So your best bet is probably to use an UnmanagedMemoryStream, serialize your data using builtin .NET System.Runtime.Serialization (of which the XML flavour is by far the more popular and easily copied from blogs and other sources).
Cheers
I am developing my first windows mobile application and would like some guidance on the best way to save and restore application state between invocations of the applications.
My application will have a small number of properties, between 10 and 20, that I wish to store when I exit the application and restore when I restart.
My options for doing this would seem to be as follows :-
Marshall in and out of XML
Use a SQL Server 2005 Compact edition database
Use a properties file with key-value pairs
Use the registry.
What would generally be considered to be the standard/best practice way to do this?
You should definitively use a properties file (option 3). Not reason to make life harder for yourself by using any of the other options. This way you'll also be able to easily tamper with the file and check its correctness.
You could also store it using Google proto buffers, but that doesn't make it that easy anymore to tamper with the file!
If you want to be able to edit the settings while your application is not running, then the key=value file makes the most sense.
But if you don't care all that much about having your settings be a text file, a really quick and cheap way to do it is to put all of your settings into a struct and then just write that struct to a file when your app quits and read the struct back into memory when it starts.
An even slicker way to do this is to to use
CreateFileMapping to map your settings file into memory in your applications. When you do this changes are automatically written back to the file whenever the struct is changed, so all you have to do is Close the mapping object when your application exits.
If you go this way, you should probably put a header on the structure so that you can detect version changes in the structure.
I am currently working on a large-scale website, that is very dynamic, and so needs to store a large volume of information in memory on a near-permanent basis (things like configuration settings for the checkout, or the tree used to implement the menu structure).
This information is not session-specific, it is consistent for every thread using the website.
What is the best way to hold this data globally within ASP, so it can be accessed when needed, instead of re-loaded on each use?
Any AppSettings in web.config are automatically cached (i.e., they aren't read from the XML every time you need to use them).
You could also manually manipulate the cache yourself.
Edit: Better links...
Add items to the cache
Retrieve items from the cache
Caching Application Data
It's not precisely clear whether your information is session specific or not...if it is, then use the ASP Session object. Given your description of the scale, you probably want to look at storing the state in Sql Server:
http://support.microsoft.com/kb/317604
That's the 101 approach. If you're looking for something a little beefier, then check out memcached (that's pronounced Mem-Cache-Dee):
http://www.danga.com/memcached/
That's the system that apps like Facebook and Twitter use.
Good luck!
Using ASP.NET caching feature is a good option I think. In addition to John's answer, you can use Microsoft's Patterns & Practices team's Caching Application Block.
This is a good video exploring the different ways to can retain application state.
http://www.asp.net/learn/3.5-videos/video-11.aspx
It brushes on the Application object which is global for the whole application, for all users and shows you how to create a hit counter (obviously instead of storing an integer you could store objects). If you need to make changes, you do need to use a lock for concurrency, and I'm not sure how it handles LARGE amounts of data because I've never had to keep that much there.
I usually keep things like that in the Application object.
If the pages are dependent upon one another and they post to one another, you could use the page's request object. Probably not the answer you're looking for, but definitely one of the smallest in memory to use.
I have run into the same situation in the past and found an interface to be the most scalable solution. Application cache may be the answer today, but will it scale to meet your needs?
If you need to scale up, you may find cookies, or some type of temp database storage to be the trick. Simply add a new method to your interface, and set the interface to choose the "mode" from web.config.
Is there a way at runtime to switch out an applications app.config (current.config to new.config, file for file). I have a backup/restore process which needs to replace its own application.exe.config file. I have seen this post but it does not answer how to do this at runtime.
Turns out I can swap the .config file for the new one and do a ConfigurationManager.RefreshSection(...) for each section. It will update from the new .config file.
Microsoft .NET's app.config is not designed for your scenario, as well as many others. I often encounter a similar need, so I have spent a lot of effort designing a solution.
Redesign to use app.config only as a configuration bootstrap: specify where to find the rest of the real configuration data. This information should almost never change, so there is no need to handle file watching or application restarts.
Pick an alternate location for the real configuration data: a file, a database, perhaps even a web service. I prefer a database most of the time, so I create a configuration table with a simple structure that allows me to store my data.
Implement a simple library to wrap your configuration access so that you have a simple API for the rest of your application (via dependency injection). Hide the usage of app.config as well as your real configuration storage location(s). Since .NET is strongly-typed, make the configuration settings so--convert each string retrieved into the most-specific type available (URL, Int32, FileInfo, etc.).
Determine which configuration settings can be safely changed at runtime versus those that can't. Typically, some settings need to change along with others, or it simply makes no sense to allow them to change at all. If all your configuration data can safely change at runtime, then that makes things easy, but I HIGHLY doubt such a scenario. Hide the changeability and interdependencies of the configuration settings to the extent possible.
Design the response to the unavailability of your real configuration data. I prefer to treat the absence of any configuration setting as a fatal error that aborts the application, unless I can identify a usable default. Likewise, I abort in the absence of the configuration storage container (file, database table, etc.).
Enjoy, and best wishes.
Are you able to restart the application when you detect that you need to switch files? If so, it's just a matter of switching the files and restarting. Now, the tricky bit is if .NET keeps the app.config file open while the program is running. I suspect it doesn't, but if the most obviously approach fails, I suggest you have a second application (cfgswitcher.exe) which waits for the process with a PID specified on the command line to terminate, then switches config files and relaunches the original process. Then your app would just need to launch cfgswitcher.exe (passing in its own PID as a command line argument) and terminate.
As I say though, it's worth trying the more obvious approach first.
EDIT: If you can't restart the application (or even part of it in a new AppDomain) then various aspects of app.config (assembly bindings etc) can't be changed. If you're only interested in your own configuration sections changing, then I suggest you store them in a separate config file and reload them whenever you want to.
Look at the events available to you on the ApplicationSettingsBase class. There are PropertyChanged & SettingChanging that may give you what you need.
You could also watch the file and if it has changed call the reload method to get the new settings.
I don't think it is possible at all to switch the configuration at runtime without restarting, so if you can't apply Jon's approach, you should try to come up with an other approach.
Anyway, maybe it's just me not having enough information about your scenario, but this kind of feels fishy.
Are you sure that swapping the configuration file is the best way to achieve whatever requirement you need to meet? I mean, this is quite an uncommon thing. If I were you, I would try to come up with some other approach.