Develop Reference

Centralized vs local string resource files

I am trying to figure out whether a global string resource file for the entire application or a local resource file for each small sub area would be a better choice.
It seems like a translator would appreciate the one file approach vs hundreds of them. It is also easier to write helper functions since there is only going to be one static resource class.
The downside is that the resource name might be really long to properly identify the place where it is suppose to be in and it might be hard to locate related strings when the file grows big.
Where as a local resource file would produce lots of duplicated strings or make it confusing if we need to use multiple instances of static resource classes because the strings are spread between multiple of them.
So what would be a better way to go?

Maybe you could break your resources into 3 files (depending on your application design):
ResourcesCore
For translated enum values and common expressions
ResourcesEntity
For strings related to translation of some entity properties (e.g. Person.Name)
ResourcesWeb (or ResourceUI)
For other UI related stuff (like strings on UI, labels, descriptions, etc.)
You could then use ResXManager extension for VS to manage you resource strings (way easier than native .NET ResX manager, at least for me).

Output one C# class per file with protogen?

Is it possible to have protogen output multiple files (one per class) based on a single .proto file?
I'm working with a very large .proto file that outputs approx 200 classes, currently all in a single file. One of the places where I need to use the generated classes is in a highly memory constrained environment (a Windows Phone background agent).
I'd like to be able to only include the necessary classes in the assembly loaded in the constrained environment but can't easily do this when the generated classes are all in a single file. If I could have them outputted to multiple files I could only link in the ones I need in the assembly for the constrained environment.
Is there a way to have protogen output the classes in separate files? I can't see an option for this and am currently only using the umbrella-classname option.
Manually editing the generated file is not an option so if protogen can't do it, is there another commandline tool available which can split up a file containing multiple classes? (To save reinventing the wheel.)
Update
I'm using Google.ProtocolBuffers.dll an inherited decision and not easily changable.
Editing/splitting the .proto file is also not a posibility. (Unless as a custom step.)

We have an option for this in csharp_options, but it's not implemented:
// Whether to generate a single file for everything within the
// .proto file (false), or one file per message (true).
// This option is not currently honored; please log a feature
// request if you really want it.
optional bool multiple_files = 4;
Given that you'd have to remove relevant files and make sure you got all the dependencies right it sounds like it wouldn't actually save you much work over the solution I'd suggest, which is to split your proto file into separate ones You say this is "also not a possibility" but basically that's all I can suggest at the moment - why is it not a possibility?
EDIT: I've just had another idea. You could potentially run the protoc step of protogen (which is now done automatically if you don't specify otherwise) to parse the .proto file into its descriptor. Then load the descriptor in another program, mutate it as you would any other protobuf message (create a builder from it, edit the message, build) and then save the descriptor. You can then use protogen on the remaining descriptor, and generate only the classes you want...

Best place to store static error strings

I was wondering if anyone had any input on the best practice of where to store static error strings in a C# application. I have a visual studio 2010 solution that has 5 projects and have defined several constant error messages to be returned via a WCF REST web service in the form of a message.
My current errors I have defined (hard-coded) are in the following format (CODE, MESSAGE):
999 - Your request could not be processed with the parameters specified.
I am not asking how to create custom classes derived from the Exception class because these errors are returned after corresponding Exceptions are raised to keep the AppPool from faulting.
Some ideas I was pondering storing the messages in: XML, Flat File, SQLite, and so on.
Does anyone have a preference and if so, why?
Thank you,
Jeffrey Kevin Pry

I personally store these things in the projects Resources file, and then retrieve them when I need them. Doing it this way also makes it a lot easier to change them, for example if you needed the system to use another language all you'd do is switch the resources file for one in another language and voila!

How to Make a "Dashboard" Utility that Accepts Modules/Add-Ins

I hope this question makes sense. Basically, I am looking for a set of guidelines, or even a tutorial, that will show how to make an application that can easily add and remove "modules" or "add-ins"
For example, in Microsoft Office, you will commonly see programs that you can download and install and they will just add an extra tab into Microsoft Word (for example) that will implement some new feature.
I have several applications that use basically the same data source, and I'd like to consolidate them and also leave open the possibility of adding more functionality in the future without 1. Requiring a brand new install and 2. Tweaking every piece of my code.
I'm looking for a place to start, mostly.
Thanks in advance.
**
Edit: To elaborate a little more...
The thing I have in mind specifically is an application that accesses a large set of data that is stored in text files and uses some of the data to create a few graphs and maybe some tables. I'd like the ability to add different graphs in the future using the same data. So, you can click Button_A and generate Graph_A, then a few weeks later, you can click Button_B and generate Graph_B.
It would be really nice if I could come up with a way that only required reading the data from the file(s) once, but I know that would involve having to adjust my DataReader class a bit.

One place to start would be to define an interface for your future modules, and build a utility that scans all the dll's therein, looking for classes that implement said interface.
Once you've found supporting classes you can create instances at runtime and add to your application. That's a common idiom in .NET for supporting "plug-ins"
The Activator class is a common way to create instances from a Type at runtime.
http://msdn.microsoft.com/en-us/library/system.activator.aspx
It's hard to give more details without more info in your question. Can you elaborate a bit?

Take a look at the Composite Application Library from Microsoft.
It is aimed at WPF but you could get some ideas from there.

As Adam said, the first thing to do is define the interface for your plugin modules - what can they expect to receive from the container, and what methods must the container be able to call?
As far as the container itself goes, I'm partial to MEF as a location technology; you can create catalogs and re-compose the system when new DLLs are added. I've built a similar system to this for parsing dissimilar files, and the composition capabilities of MEF are awesome for runtime discovery.

Plugin based application in C#

I have to make a graphical user interface application using the language of my choice. The application will run on Windows XP. It will be some sort of a complex windows form application.
I think and as per most suggestions, C# will be the best to use.
The tree structure on the left of the GUI will populate after reading from a configuration file which will be a binary file . (but initially I can work with a simple ASCII file to test my code.). The application will accept some inputs from the user through this GUI and will write the back to the same config file and will reflect the changes in the tree structure or the labels or any other pertaining field on the form.
There will be 3 tabs and 3 corresponding config files for each of the tabs.
I need some help designing the application for now. I am planning to make a host application (main application) and use the 3 tab controls as plugins. Is this workable ? If so can you please guide me on this. I mean how do I make 3 plugins in C# and how do I write the interfaces so that the main application knows which plugin to load and when to load it ? Will there be a separate “Plugin” folder under my project folder ? I hope you got my point though this is too little of an information for you to begin with.
Also there are some .cpp files already existing in the project. These files along with some .h files contain some important definitions and constants in them. These need to be integrated with my C# application. I have no clue how to do that but I am sure that it is possible by compiling the .cpp code in a .dll and then exposing the compiled .dll to my C# application. Please let me know if you need some more information for the top level design.
Thanks,
Viren

To implement a plugin interface manually, you will need a method something like this. I've left some TODOs in, where you would want to enhance the error handling and/or make the implementation a little more case specific.
public List<T> LoadPlugin<T>(string directory)
{
Type interfaceType = typeof(T);
List<T> implementations = new List<T>();
//TODO: perform checks to ensure type is valid
foreach (var file in System.IO.Directory.GetFiles(directory))
{
//TODO: add proper file handling here and limit files to check
//try/catch added in place of ensure files are not .dll
try
{
foreach (var type in System.Reflection.Assembly.LoadFile(file).GetTypes())
{
if (interfaceType.IsAssignableFrom(type) && interfaceType != type)
{
//found class that implements interface
//TODO: perform additional checks to ensure any
//requirements not specified in interface
//ex: ensure type is a class, check for default constructor, etc
T instance = (T)Activator.CreateInstance(type);
implementations.Add(instance);
}
}
}
catch { }
}
return implementations;
}
Example to call:
List<IPlugin> plugins = LoadPlugin<IPlugin>(path);
As for the c++ part of your question. There are few different ways you could approach this, though the correct choice depends on your specific situation. You can make a clr compliant .dll in c++, which your c# project could reference and call like any other .dll it references. Additionally, you could use P/Invoke to call into a native .dll.

One of the easiest plugin concepts I have ever used was certainly the Managed Extensibility Framework which will be part of .NET 4 (afaik). Unfortunately it is not yet finished and only a preview is available which may differ from the final version. That being said, we used MEF Preview 3 for a uni project and it worked without problems and it certainly made the whole plugin stuff a lot easier.

Look at the System.Addin namespace :
http://msdn.microsoft.com/en-us/library/system.addin.aspx
Otherwise you can do everything yourself. Before this namespace was available, I used a common interface "IPlugin" that every plugin/addin needed to use. I then had a loader which inspected all the *.dll in a folder then used reflection to check for the interface. I could then create instances of classes which implemented my plugin/addin interface
The cpp files will probably need converting to c#, or you could possibly create a dll to reference.

Take a look to Castle.

.NET Framework use COM model in its guts. See http://blog.caljacobson.com/2007/07/26/creating-a-plug-in-framework-in-c-resources/ for a list of plugin example using this techique.