tags:

views:

395

answers:

2

This may sound like an unusual question, but I am curious as to how i can add an additional column to the resx file setup (so i would have something like "name, value, comment, foo")

I've looked around online and haven't heard of anyone else trying something like this, but i think it might be possible to do this by writing a new resx reader and writer. Just wanted to know if anyone had any insight on this problem, mainly i intend to use this for storing messages and logging them with a priority stored in the resource file (column foo in this case)

+1  A: 

You can open the resx file with XML editor and modify the schema, but the built in resx editor in Visual Studio will remove any column that you add manually to the schema.

But by creating your own reader it should be possible.

[Edit] I duplicated the ResXResourceReader/Writer from the .Net framework, but when I add these to the .resx file the Managed Resource Editor in .Net throws an error. My best suggestion is to add a new column to the schema and use another editor like the one at http://madskristensen.net/post/A-NET-resource-editor-application-for-resx-files.aspx. Just modify the code to account for your extra column.

Mikael Svenson
is there any way to override the default Visual Studio editor? It would be nice to use the editor if possible, but i can write my own small application to handle the new column if need be. I am mainly concerned by the "Visual Studio will remove any column that you add" part, since i do not want it to just drop the logging priorities or anything else that may be added.
MicroPirate
I was a bit premature with my answer. They are removed due to the reference in the resx file to System.Resources.ResXResourceReader and System.Resources.ResXResourceWriter. If you inherit these or implement IResourceReader in your own reader/writer and put the dll in the GAC, I'm sure you can extend the schema and add another column.
Mikael Svenson
looks like i will have to get on this, and with any luck will be back in a couple days to check your answer.
MicroPirate
I looked at the current reader/writer via reflector, and I think you could extract the code and create your own based on it. Inheriting it seems harder since a lot of the methods you want to override are private. I might have time to look at it further this weekend, unless you decide to use something else than resx. Why do you need the .resx format?
Mikael Svenson
it's for simplicity purposes, the people i am working with on this project need to be able to edit informaiton/messages the stored information, currently a db is used, but it takes a while to get around our source control process to make changes. It was requested that I some how implement this via resx files, and i am going to need to use more than the 3 columns to make it work (while avoiding some nastier methods of implementation.)
MicroPirate
A: 

Try using a simple naming system to store the key-value pairs for your "name", e.g.:

name->"value"
name-comment->"comment value"
name-foo->"foo value"

This would let you store any number of name-key->value pairs for your "new columns".

If your requirements are more complex & subtle, then look into writing your own resource reader/writer.

Also, this sounds like you've got a requirement that more closely matches a database table. Look at using SQLite as a data store, possibly.

Mike Atlas
you are right on the database idea, i am actually trying to move away from that since it will make it harder to port the application to other machines that will need the stored data.
MicroPirate
SQLite is embeddable in your application. You can easily move it around between machines (or move its data file) without any kind of additional installation steps. However you lose all the nice stuff of using resource files... Stick with my first suggestion!
Mike Atlas
bear in mind the other reason for using resx files is because we want to internationalize our product.
MicroPirate
then go with the naming system i suggested. if msft updates resx functionality in the future you can be guaranteed it will be compatible with little upgrade effort on your end.
Mike Atlas
yeah unfortuneatly that was the solution I also came up with, it will work, I was just hoping I could establish some official column, which is proving difficult as I also need a custom dictionary classes to support additional value columns.
MicroPirate
You could write a small wrapper around the Resource class that restricts the "special column names" to some enum values limited to the ones you "know are good". A lightweight "type enforcement" so to speak. Eg: MyResource.GetComment("name") runs Resource.NameComment(...) sorta thing.
Mike Atlas