I’m working on some funky embedded resource stuff where I’m embedding all nature of files into an assembly so I can extract and use them on the fly later. In doing that, I’ve come across an interesting behavior in Visual Studio.

Say I embed two .resx files. One will be called “Strings.resx” and one will be called “Strings.en.resx” - the former is the default set of resources, the latter is the English-specific resources. I set the Build Action on these to “Embedded Resource” to tell Visual Studio to embed them. That looks like this:

I build my solution and behind the scenes Visual Studio realizes the .resx file is actually resources, does a little resgen action on it for me, and links the generated resources into my assembly. In the build output, I’ll see that I have my primary assembly and a subfolder called “en” that contains an assembly with the English-specific resources I embedded. This is all as expected.

Now rename those files because you don’t want the behind-the-scenes-resgen thing to happen. In fact, let’s call them .js files, just to change things up. Leave them embedded, though.

I expect that when I build my solution, my final assembly will have two files embedded - Strings.en.js and Strings.js. You know what happens?

You still get two assemblies. The primary assembly has Strings.js embedded in it, and the satellite assembly in the “en” subfolder of your build output has the Strings.en.js file embedded in it, renamed to Strings.js. Not at all what I was expecting.

I suppose you might have thought you could infer that, maybe, from the .NET Framework Developer’s Guide on Creating Satellite Assemblies, but they only talk about the creation of .resources files and how that all gets linked into satellites. No one mentioned anything about a pseudo intelligence splitting things up for me.

I’m not sure I like it. For the project I’m working on, it’s really throwing a wrench in the works, I’ll tell you that.