Is it possible to store a .Net object in the registry?
I want to store a generic List<> in the registry, and then retrieve it and parse it back to the List.
Is this possible, or do I need to manually serialize it and then deserialize it back?
[UPDATE]
Following the posted answers, I am going to serialize the object and save it in the Current User's AppData folder.
It's possible, if the type included in the list is serializable. If that's the case, you can serialize it and store it in a string value.
But it's probably a very bad idea. The registry gets big enough as it is. Instead, put this kind of thing on the file system, in the All Users Application Data folder.
Why the registry?
The appropriate place to store these kind of serialised objects is usually in the users' Application Data folder or Isolated Storage. Though of course the method of serialisation is up to you. XML, binary etc, it's essentially a file on disk.
You could consider things like "Local Database" or SQL Server Express, depending on your data and concurrency needs.
Some applications do store a Most Recently Used (MRU) list in the registry, but that's just by iterating all the values of a given key. I don't recommend that approach.
Yeah, I think you'd have to serialize and deserialize it yourself. But you could store it either as a binary block or text/xml. It's possible that there is a size limit to registry data...
The big question is "is this a good thing to do?"
You will have to serialize it yourself. Beware that there might be limitations on the amount of data you can store, depending on the Windows version.
http://msdn.microsoft.com/en-us/library/ms724872(VS.85).aspx
I'll just say this first: this sounds like a really bad idea.
If you insist on doing this, you're going to have to serialize it first. The registry doesn't support inserting .NET objects.
You would have to serialize it. The registry only stores primitive values.
You would need to manually serialize it.
Not quite sure why you'd want to store .NET objects in the registry, as there's already existing functionality in the BCL that allows you to do this with XML configuration files... but saying that, it is of course possible to store .NET objects in the registry. You'd probably only want to do it if the size of the object was relatively small, but it shouldn't be a problem anyway. I guess that the obvious way to do it would be to use XML Serialization (without formatting/whitespace) and store the object as a serialized string value.
Related
I'm trying to serialize an object cache to disk so it can be loaded the next time the program is loaded.
One of the features of the class being saved is it contains references to other objects.
For example:
I have a list of an image class that stores remote url, local filepath, if it's been downloaded etc.... I then bind visibility to downloaded and the source to the local filepath.
Other Objects have a reference to this image so when the image is downloaded it's updated once and all the bindings update across all items that are pointing at it.
As a quick fix I implemented a binary formatter and all is working correctly. All my lists are serialized to disk and when I reload them all the references remain (I.E 1 image object is created and everything that uses it has a reference as opposed to deserialisation creating a new instance of Image everytime it appears)
My question is what kind of Serialier I should be using to store to disk whilst not breaking my references? I've read that BinaryFormatter is a BAD choice for serializing to disk and expecting it to work across different releases. Although I've had no issues with it so far I don't want to run into problems a year down the road and force all my users so re-aquire all their cached metadata.
I'm not 100% sure how all the different serializers work but I presume I may need to write some kind of convertor if I were to use XML. If it helps, all of my image objects have a GUID assigned to them so I have something unique about every object.
UPDATE: I've just found the following question which looks similar Maintain object references through Serialize/Deserialize
Can anyone tell me if Datacontractserializer is a good choice for long term serialization storage across different versions of an applciation Vs the downsides of binaryformatter?
No need for any converters and stuff, just check this out:
http://www.switchonthecode.com/tutorials/csharp-tutorial-xml-serialization
SqLite may help in it, its easy to use.
MongoDb may be useful. See MongoDB for C#
or other type of DataBase: DB4Object
and seems be SQLite useful. use blobs for store images as binary.
I understand how serialization works and was wondering if there is a way to store an object on the disk and work with the object and save the changes.
I am trying to avoid directly doing this:
Opening the file
Deserializing the object
Changing the object
Serializing the changes by overwriting the old file
Is there a class that allows a file to be used as an object store, namely List<object> and working with it directly on the disk without having to complete the above processes?
Try DB4O. It seems to be a solution for your requirements.
I dont believe there is an out of the box solution for this. Just search on how to save arbitrary data in a file, and think up your own format.
You probably want to look at something like ESE which comes with Windows. There is a managed interface for it. Never used it though.
Either that or use a lightweight database e.g. SQLite, since effectively, if you want to add, remove and modify data on the disk, some kind of database is what you need.
Objectivity is another alternative. It supports computing across vast distributed networks or embedded in stand-alone devices that simply must not fail, enables persistent object management, virtually instantaneous traversal of complex, many-to-many relationships and graphs, and much more.
Im looking for a simple solution to serialize and store objects that contain configuration, application state and data. Its a simple application, its not alot of data. Speed is no issue. I want it to be in-process. I want it to be more easy-to-edit in a texteditor than xml.
I cant find any document database for .net that can handle it in-process.
Simply serializing to xml Im not sure I want to do because its... xml.
Serializing to JSON seems very javascript specific, and I wont use this data in javascript.
I figure there's very neat ways to do this, but atm im leaning to using JSON despite its javascript inclenation.
Just because "JSON" it's an acronym for JavaScript Object Notation, has no relevance on if it fits your needs or not as a data format. JSON is lightweight, text based, easily human readable / editable and it's a language agnostic format despite the name.
I'd definitely lean toward using it, as it sounds pretty ideal for your situation.
I will give a couple of choices :
Binary serialization: depends on content of your objects, if you have complicated dependecy tree it can create a problems on serializing. Also it's not very flexible, as standart binary serialization provided by Microsoft stores saving type information too. That means if you save a type in binary file, and after one month decide to reorganize your code and let's say move the same class to another namespace, on desirialization from binary file previously saved it will fail, as the type is not more the same. There are several workarrounds on that, but I personally try to avoid that kind of serialization as much as I can.
ORM mapping and storing it into small database. SQLite is awesome choice for this kind of stuff as it small (single file) and full ACID support database. You need a mapper, or you need implement mapper by yourself.
I'm sure that you will get some other choice from the folks in a couple of minutes.
So choice is up to you.
Good luck.
In Windows phone we can store and retrieve anything using
IsolatedStorageSettings.ApplicationSettings.Add("foo", bar);
IsolatedStorageSettings.ApplicationSettings["foo"]
Then why people are using "sharpSerializer" kind of things ?
The settings is a flat organization with key/value pairs. For simple objects that's not a problem but if you have rich collections and don't want the overhead of deserializing a list just to get to an element, the settings can be problematic. They also require the element to be serializable, whereas using the isolated storage file system you can control the serialization and serialize anything. Furthermore, you can choose the serialization strategy such as binary, JSON, XML, or otherwise. Finally, there is a limit to how effectively settings will serialize objects. I'm not sure what it is because it's not published but more than one developer has told me larger objects or large amounts of objects start to behave erratically, throwing exceptions or not persisting correctly, in the settings.
PS - also, since you mentioned Windows Phone 7, there are limits to settings whereas the file system does not have a quota.
The big problem with storing the objects in the ApplicationSettings is that the entire contents of the settings are serialized and deserialized together.
As soon as you access just one setting, all settings a deserialized and loaded in the Dictionary<string, object> that backs the ApplicationSettings. Hence its not good choice to store large number of settings or to store large objects that require significant serialization.
Off the top of my head:
IsolatedStorageSettings are typically slower to access and save to than IsolatedStorage files.
You can't save null in Settings, but you could create your own serialized representation of this.
The use of directories can make working with a large number of files much easier than requiring a long or complicated naming convention for the key to an object in Settings.
In some cases you may want to refer to an object stored in IsolatedStorage. You can't do this if it's saved in settings.
I suspect that objects added to Settings are still serialised in some way (in the background) - my guess would be binary serialization - as they need to be persisted to disk. By defining your own serializiaton you can be sure that this will work correctly/as expected. If you just rely on the system to do it you could end up with unexpected behaviour. If you have your own serialization you also have some guarantees on future and cross platform compatibility. (If that's a concern.)
Another important point that other didn't mention was that when you update your application by submitting a newer version to the marketplace, the entire ApplicationSettings get wiped off, as it is assumed that the new application will have its own defaults set. So it is always a good idea to serialize data in to the IsolatedStorage and not cram the AppSettings.
My question relates to the performance implications of reading application configuration data from an XML file.
I am building an application that lists information from a database and needs to know how to display the lists, depending on the types of data returned.
This is difficult to explain, but basically I would like to have an XML config file that lists the types and describes how to display them. This will allow me to change the display methods without re-compiling the application.
My question is really around performance. Given that my application will need to use this data many times during each page load...
Should I be reading directly from the XML file and parse it each time I need it?
Or should I cache the XML object and parse it each time I need it?
Or should I parse the XML once, generate some sort of object and cache that object?
My guess is option 3, but I'm basically fishing for best practice around this.
Thanks.
There is already a convention for this, called the App.config file.
It is XML, and Visual Studio has tooling support for it.
My suggestion is: Don't reinvent the wheel, if you can help it.
Now, given that your format is too complex for that, you probably want to go with option 3, but load it lazily.