We have a program that is used in one specific industry and has strings that are specific to that industry. We now have the situation where it can be used in another industry and we want to customise the strings for that industry without duplicating our code base.
The problem space appears very similar to localisation. Are we going to have a separate resource assembly for each industry? If so when would we choose which assembly to use, could we do this at install time or would it need to be at compile time?. How do we keep the separate resource assemblies synchronised, so that the same keys to messages appear in each one?
What is the best way to do this?
Let me re-phrase it: you have an industrial application which could be used in various industries and the only things that are different are resources (that is strings, layout, maybe images and sounds). The other code stays the same.
In such case your problem is not just similar it is actually identical to Localization. And as such you can use Satellite Assemblies.
Now, it is up to you if you want to package such created applications separately or distribute one application with both problem spaces.
The first seem more realistic scenario to me - you would need to decide on which .resx file to include at compile time (i.e. during project preparation you would overwrite existing resources with problem-space resources and then proceed with compilation, that should give you different flavors of your application; I would also modify their names in such case).
The latter would require you to manually instantiate ResourceManager at runtime to read from valid satellite assembly - it could be based on some configuration file. It means more work (you would need to actually modify your code) and you will end up distributing both flavors of your application at once, that is you won't have control over how your customers will use it. From the business perspective it could be a little dangerous.
EDIT (Note to self: read whole question carefully)
Somehow I managed to miss install time vs. compile time. I believe compile time is the answer because of the same reason I gave in config-driven switch section: you would package the resources and you won't have any control on how customers use it. Some clever guy would figure it out, that is for sure.
I would recommend having a properties file with key value pairs. Where you currently have industry specific strings, replace them with calls to the properties file. Obviously you would cache these strings in some container. I don't know the C# container - Java would use java.util.Properties.
aerospace.props:
INDUSTRY_NAME=aerospace
INDUSTRY_START_YEAR=1903
manufacturing.props:
INDUSTRY_NAME=manufacturing
INDUSTRY_START_YEAR=1600
Related
Does anyone have any idea of the pros and cons of using resx vs json files for some enums (that will be possible values for attributes)?
I'm not sure what to use. And to use a database system for this would be overkill, as I'm just talking about a few lists of enums.
Small update
At the moment , the only difference I can see is that with JSON storage I'm not limited to changing those lists at compile time, but they are not going to change very much over time so that is a negligible factor.
Resx file is good if you want some capabilities of localization, like to store your enums in different languages and so on. Json format is much more flexible and it is not depend on the .Net environment.
From this link
Resource files give you an easy way to localize/internationalize your
.net applications by automatically determining which language resx
file to use based on the user's locale. To add more languages, simply
add another translated resource file.
Resource files give you a
central location to store your strings, files and scripts and refer to
them in a strongly-typed manner (so the compile will break if you
reference them improperly).
Resource files can be compiled into
satellite assemblies, making it easy to change up the resources in a
production application without having to recompile the whole thing.
I have a C# app that needs to be localized. I can use the RESX .NET MUI strategy to do that. Now, I have a separate team that is providing additional localized resources (XML files) post build/compile time. I'd like to take advantage of .NETs MUI strategy which provides a nice fallback mechanism, but I can't seem to find a way to make that happen.
Note, I have thought about adding the localized file names (which I know) in my App's string resources file. However, if at runtime the file doesn't exist, then I'll have problems (and no way to automatically fallback).
So, is there a way to utilize the .NET MUI strategy in this scenario?
Option 1:
You can store the XML files in a resource, and then get a stream object to read it, which uses the same approach as is done with strings, etc. See http://msdn.microsoft.com/en-us/library/zxee5096.aspx for that.
Option 2:
You can also apply the same basic approach as that used by resources yourself. I've found it convenient with web applications which are often based on a lot of files (.aspx, .html, .css, .js, .png, etc) anyway. Say you've got a bunch of directories like:
localised/en/SomeFile1.xml (and etc....)
localised/en-US/SomeFile1.xml (and etc....)
localised/en-GB/SomeFile.xml
localised/fr/SomeFile.xml
I come along with my en-IE prefernces, and you don't match that, but you do match en and that's good enough (okay ideally you should pick up that en-IE is closer to en-GB than en-US, but that's totally into the bonus-credit territory and much better than .NET will do with resources).
Your matching algorithm should be:
Try to find a match for the locale sought, return if found.
Drop off the end of the locale, so en-GB-OED becomes en-GB, en-GB becomes en- and so on. If that doesn't remove the whole thing, go back to step 1 with this new locale.
Try zxx (zxx isn't used by .NET afaik, but it is used with BCP 47/RFC 4647 and ISO 639 for items with no lingual content - e.g. a passport photo of you is locale zxx because it's just as appropriate to go with a French document as a Yoruba or Welsh one).
Try a "default" locale as defined by you (or error if your application promises to make a good match).
At that point, you'll be doing slightly better than what resource files do. Still, mostly option 1 is a lot simpler and is far more self-contained.
I have a few questions regarding the structure of a Portable Executable.
Now, I found a great start through a couple of well written articles both here and here; however, I still do not quite have my answer.
I believe, and please, correct me if I'm wrong here, that data in a certain section of the PE structure is what's loaded and run by the operating system. For example, take the .text and the .data sections.
Based on what I've read, the .data section holds instrunctions of some sort, while the .text section holds the actual data to be run.
I'm curious to know whether or not it's possible to store a file's data in the .text section, and dynamically move it over to the .text section which would then automatically (load/launch/run) the file's data which is now in the .text section.
If you are confused about what I'ma asking, allow me to paraphrase.
Where (in what section) is the main data of a file stored?
How would I go about moving data between sections in C#? I'm assuming I'd have to use pointers for this.
Am I correct in thinking that such a functionality would even work?
Am I correct in thinking that such a functionality would even work?
No :)
It's not clear to me at all what you want to accomplish - you sound like you're talking native PEs because .NET PEs don't really have anything other than data in the PE.
In any case, the PE is mapped by Windows while the module (EXE or DLL) is loaded, so you can't really modify it on the fly.
For native code PE or PE+ files these questions would be answered a lot different, and these things would be plausible.
However, for a .NET assembly encapsulated in a PE, things change a lot. The PE/PE+ is just a storage container barely referenced by the OS loader.
You can load into memory an assembly and execute it, so therefore what you propose is theoretically possible. HOWEVER, it has nothing to do with moving code from one section of a PE to another.
You would dynamically allocate read+write virtual memory, write your code to it, change the attributes to read+execute (adding execute, removing write), then invoke the appropriate .NET assembly loader code. Lookup the various Invoke methods for that.
OK so that title sucks a little but I could not think of anything better (maybe someone else can?).
So I have a few questions around a subject here. What I want to do is create a program that can take an object and use reflection to list all its properties, methods, constructors etc. I can then manipulate these objects at runtime to test, debug and figure out exactly what some of my classes / programs are doing whilst they are running, (some of them will be windows services and maybe installed on the machine rather than running in debug from VS).
So I would provide a hook to the program that from the local machine (only) this program could get an instance of the main object and therefore see all the sub objects running in it. (for security the program may need to be started with an arg to expose that hook).
The "reflection machine" would allow for runtime manipulation and interrogation.
Does this sound possible?
Would the program have to provide a hook or could the "reflection machine" take an EXE and (if it knew all the classes it was using), create an object to use?
I know you can import DLL's at runtime so that it knows about all sorts of classes, but can you import individual classes? I.E. Say I have project 'Y' that is not compiled to a DLL but I want to use the "reflection machine" on it, can I point at that directory and grab the files to be able to reference those classes?
EDIT: I would love to try and develop it my self but I already have a long list of projects I would like to do and have already started. Why reinvent the wheel when there is already a great selection to choose from.
Try looking at Crack.NET. It is used to do runtime manipulation and interrogation on WPF/WinForms but the source is available and might be a good start if it already doesn't meet your needs.
It sound as if Corneliu Tusnea's Hawkeye might be close to what you're looking for runtime interrogation of objects/properties/etc. He calls it the .NET Runtime Object Editor. I'm not sure if the homepage I linked to above or the CodePlex project is the best place to start.
It's a bit out of date now, I think, but there's an earlier version of it on CodeProject where you can see the source code for how and what he did.
Powershell actually does nearly all of this, if I properly understand what you are saying.
See this answer on how to build a "reflection engine".
All you need to do is to drop that set of machinery in the your set of available
runtime libraries and it does what you want, I think.
(It might not be as easy as I've made it sound in practice).
My guess is you'll also want a runtime compiler, so that you can
manufacture instrumented/transformed variants of the program under inspection
to collect the runtime data you want. You may find that such
machinery provide static analysis results that let you avoid
doing the runtime analysis in many cases.
I'm using Visual Studio (2005 and up). I am looking into trying out making an application where the user can change language for all menues, input formats and such. How would I go on doing this, as I suppose that there is some complete feature within .Net that can help me with this?
I need to take the following into account (and fill me in if I miss some obvious stuff)
Strings (menues, texts)
Input data (parsing floats, dates, etc..)
Should be easy to add support for another language
I'm not an expert with .NET by any means but Localization is never just as simple as "swapping out String values" or "changing date formats". There is much more to be taken into consideration such as layout, proper text placement.
Take Chinese for example. The way you read is top to bottom not left to right. If properly localized the app should take that into account.
http://msdn.microsoft.com/en-us/library/y99d1cd3(VS.80).aspx seems to be a good start though if you're dealing with Windows Forms.
The classic recipe is: design the app with no native language but a localization facility, and develop an initialization into one language (e.g., English). So you build the app and localize it into English every night; without the localization step it would not be usable. Do that well, and the resources for the initial sample localization can be replaced with those for any other language. Take into account non-roman scripts from the beginning. It's much cleaner to have a no-language app that always requires localization rather than a language-specific app that needs to have its native language subtracted and a replacement added.
For strings you should just separate your strings from your code (having an XML/DLL that will transform string IDs to real strings is one way to go). However you do need to make sure that you are supporting double byte characters for some languages (this is relevant if you use C/C++).
For input data what you want is to have different locale's. In Java this is relatively easy, and if you use C# it probably is quite easy also. In C/C++ I don't really know. The basic idea is that the input parsers should be different based on the locale selected at that time. So each field (textfield, textbox, etc.) must have an abstract parser that is then implemented by a different class depending on the locale (right to left, double byte, etc.).
Check the Java implementation for details on how they did it. It is quite functional.
You definitely need to be using the .NET ResourceManager and the resx file xml format, however there are a number of approaches to using this.
It really depends on what you are wanting to achieve. For me I wanted a single xml resource file (for each supported language) that could be modified by anyone. I created a helper class that loaded the global resource file into ResourceManager (once only) and I had a helper function that gives me the required resource for a given name. The only disadvantage in this approach was that I could not leverage dynamic binding of resources to properties.
I found this better and easier to manage than multiple or embedded resource files for every form. Additionally exactly the same approach can used in an ASP.NET application. I also found this approach means that outsourcing translation of resources and shipping language packs to customers much more manageable.
Microsoft's recommended approach is to use satellite assemblies, as described in Packaging and Deploying Resources. If you're using a ResourceManager to load resources, .NET will load the correct resources for the CurrentUICulture. This defaults to the user's current UI language setting in Windows.
It is possible to localize Windows Forms either through Visual Studio or an external tool, WinRes.exe. This article describes WinRes and how to use Visual Studio to localize the form.