Jakub,

O.k., now I begin to understand what your intentions might be. In an application which comprises several different components (like
Forms, DLL libraries, separate Controls) you would like to gather ALL resources together within ONE additional Satellite Assembly.

I hope I am understanding this correctly up to here.

Well, this might be achieved if in your separate project (a "Resources project") you create various .resx-files for your various
other components, let's say they might be named

MyForm.resx
MyForm.en-US.resx
...

MyDLL.resx
MyDll.en-US.resx
...

MyControl.resx
MyControl.en-US.resx
...

It would be best if you give your "Resources project" a distinct default namespace in the project's settings, let's call it
"MyResources". The Satellite Assemblies created out of your .resx-files will then all be named "MyResources.resources.dll" and will
be put below the output-folder of your separate project.

Within each of your various components you first need to create a REFERENCE to your "Resources project" via Solution Explorer.

Then e.g. in your Form "MyForm" you go like

using System.Globalization;
using MyResources;

ResourceManager rm = new ResourceManager("MyResources.MyForm",System.Reflection.GetExecutingAssembly());

Or in your DLL you go like

using System.Globalization;
using MyResources;

ResourceManager rm = new ResourceManager("MyResources.MyDLL",System.Reflection.GetExecutingAssembly());

As long as your components contain a reference to a separate assembly and you use the "using" statement, you can of course make use
of resources embedded in this separate assembly.

But, after all explanations, allow me the question: What is the reason for this approach?

The "normal" Satellite Assemblies which are created automatically along with your Form can be exchanged or extended just as easly.
O.k., in case of a DLL-library you would anyway have to go the way I described because outside of "System.Windows.Forms" the
automatical procedure of Satellite Assemblies is not present.

Do you plan to "centralize" all resources for your various components within ONE Satellite Assembly? This might indeed be senseful
for a lager and heterogenous project.

On the other hand, regarding your Form (or Forms), you then let go the extreme simplicity of creating Satellite Assemblies via the
IDE Designer. You will have to do it all manually for every Form.

Regards

Rolf

Jakub,

to be fully clear, I make one more explanation.

In my last post I stated that in case of Forms (or, as I might add in case of Controls) according to your approach (extracting ALL
resources to ONE separate Satellite Assembly) you will have to do it all manually.

Let me explain in more detail what it would mean for you to do it ALL manually.

Well, in the first place this of course means creating key/value-pairs for EVERY ELEMENT in EVERY Form or EVERY Control of your
application. You will have to create

MyForm1.resx, MyForm1.en-US.resx,...
MyForm2.resx, MyForm2.en-US.resx,...
...

MyControl1.resx, MyControl1.en-US.resx,...
MyControl2.resx, MyControl2.en-US.resx,...
...

But this is only the FIRST part of your labour to come.

Consider, that the IDE will by itself create .resx-files for every Form or Control you add to the application. And consider further,
that - within the various "InitializeComponent()"-routines of the Forms or Controls the parameters for the localizable values will
initially be fetched via the automatically created ResourceManager-objects.

Example:

Within "MyForm1" there will be automatically created a ResourceManager-object like

ResourceManager resources = new ResourceManager (typeof(MyForm1));

(A different usage of ResourceManger which can be used - as far as I have found out - only by the IDE).

The parameters for ALL elements within your "MyForm1" will be fetched via this ResourceManager in the
"InitializeComponent()"-routine of "MyForm1".

To deflect this behaviour to your "private" Satellite Assembly, you will have to change ALL these statements within the
"InitializeComponent()"-routines of ALL your Forms or Controls.

Having the effort of creating key/value-pairs for ALL elements of ALL Forms/Controls of your application in mind, and adding the
additional effort of changing ALL respective statements within the "InitializeComponent()"-routines of ALL your Forms/Controls, you
might want to balance this immense labour against the simplicity of making use of the automatic creation of Satellite Assemblies for
each Form/Control.

If you made use of this simplicity all you additionally would have to do was creating Satellite Assemblies for the DLL-libraries.

The resources of your complete application then would not be "centralized" within ONE Satellite Assembly but each Satellite Assembly
of each Form/Control/DLL could as easily be exchanged as your original intention was.

Regards
Rolf

But consider this additional

And let me add just one or two other (more general) thoughts regarding your intended approach:

Suppose, your application is large, complex and heterogenous (Forms, DLLs, Controls).

Will it really help you as a developer to comprise all localized key/value-pairs of all elements of all components of your
application within ONE Satellite Assembly?

On the one hand this will lead to tremendous work you will have to do (as I described before).

Furthermore you will have to do a good job to identify the key/value-pairs of a single element's property belonging to one of the
various  Forms/Controls within your huge application.

On the other hand, from a viewpoint of structure: Is it really helpful to centralize information which belongs to completely
different parts of your application?

CENTRALIZING is a viewpoint of developing which goes more in the direction of database- or directory-focused programming. It mostly
makes sense where COMPLETELY DIFFERENT APPLICATIONS have to rely on the same set of information. As far as I have understood your
intention we don't talk about different applications.

Now chaning the focus to ONE application:
Don't forget about the advantages of OBJECT-oriented programming and its various advantages. The motto here is: Keep information
where it immediately belongs to, make ways of information short. This in turn will help you as a programmer to keep an overview of
all information spread througout your application.

Regards
Rolf

Bob,

you are right: MSDN unfortunately is not very clear (not to say misleading) about this important issue. When I myself had to deal
with this it took me indeed some DAYS to correctly find out everything, within the boards I did not find a suitable explanation as
well.

During my efforts which after some time degraded to a kind of "Try and Error" I think I sent more curses to Redmond than Bill earns
bucks a year :-)

So, I think it is the right way to share what I have found out and to save others from this torture of uncertainty where you doubt
all the time if you will EVER find a way.

Regards
Rolf