The use of resources has nothing to do with installation, essentially. We use them, basically, to isolate a mass of immutable parametric data from the application, and — very essential thing — to
globalize the application. This is some feature which you might be not familiar with, otherwise you would not have this question.
The .NET ways of application globalization is based on putting UI strings and strings formats (not only graphical UI but anything which could appear on screen in any mode, in console of windowed, or in output files, including exception messages) in the resources. A well globalized application is something fully ready for
localization without passing the kernel source code to the translators and without recompilation of the source code.
The localizing team only gets the resource part of the project, along with original documentation and appropriate number of copies of the working product. Those people translate all resources into a new resource-only project and put it in the working directory under a sub-directory named by a target culture. This part of project does not depend on original project and is simply added to it, without any recompilation of existing code. Such deployed additional localizing parts of the projects are called
satellite assemblies. When a resource is needed, the .NET resource managers inquire the current UI culture of a UI thread and loads corresponding satellite assemblies to replace original set of resources fully or partially, depending on available satellite assemblies. If some satellite assembly is not found for certain resource set, a closest possible culture is used. This search falls backs all the way down to the culture used in original product, which is called the
fallback process.
This way, the localized resources are added in non-intrusive way, without using the source code of original project and without recompilation of anything.
As to the deployment, installation is only one of the mechanism. You can use just the copy of the output directory with all satellite assemblies and let the user to select the UI culture dynamically at any moment, effectively switching the UI culture using any of the localizations available.
As to the installation, one can use different scenarios. It can be deployment of all satellite assemblies at once, configuring the application culture before execution or dynamically; or one can provide a mechanism for downloading of required satellite assemblies on request (please see the last link below).
There are a number of delicate aspect of globalization and localization, such as text direction and layout, but I explained the main idea. For further reading, please see:
http://msdn.microsoft.com/en-us/library/aa292205%28v=vs.71%29.aspx[
^],
http://msdn.microsoft.com/en-us/library/aa291552%28v=vs.71%29.aspx[
^],
http://msdn.microsoft.com/en-us/library/ms753931.aspx[
^],
http://msdn.microsoft.com/en-us/library/ms788718.aspx[
^],
http://msdn.microsoft.com/en-us/goglobal/bb688142.aspx[
^],
http://msdn.microsoft.com/en-us/library/21a15yht%28v=vs.100%29.aspx[
^],
http://msdn.microsoft.com/en-us/library/70s77c20.aspx[
^],
http://msdn.microsoft.com/en-us/library/70s77c20.aspx[
^].
—SA
Submit an article or tip