Why doesn't the C# compiler accept /resource:*.resources?

Well, here I am finally getting back to this.

In my previous post on resources, I glossed over one issue.  Not all managed resources are exactly what they seem.  Specifically at the metadata/compiler level, there is a table that simply points to the resource and gives it a name.  This is very similar to how Win32 native resources work.  A lot of managed code assumes that data stored there is a .resources file.  There is actually a magic cookie value that is at the very beginning of the header for .resources files, but that's not exactly a guarantee that what follows really is a .resources file.  That is why the compiler and ALink allow you to embed anything you want as a resource.  Likewise Assembly.GetManifestResourceStream, returns just a stream.  You have to know what data is in the stream.

As a side note, given this architecture, it seems like the metadata for 'managed' resources adds no value over the existing native Win32 resource format.  So it seems like another case of NIH.

Way back before we actually had a good idea of what an assembly was (and before we had any tools that created them) the frameworks team just used raw .resources files sitting on the disk in the application directory.  When they moved over to real assemblies, they decided to keep the same naming scheme.  This led the compiler team (well basically just me) to come up with the novel idea of using the resource's filename as the default name for the resource.  That way they didn't have to type the filename twice.

The problem here is that we weren't thinking about the big picture and how this would look to an end user who hadn't seen the intermediate steps.  As a convention most people name their source files according to the class inside it.  Thus it would make sense to name a .resource file after the resources inside it, but that doesn't mean we should default it.  In fact if I were to do it all over again I would make 2 big changes:

1. Never default the name, always make it explicit.  However, place the name of the resources somehow in the .resources and .resx file itself, rather than on the command-line.  Then the designers could do proper code-spit without relying on things like the default namespace or the hidden correlation between the class name and the .resources name.  Also we wouldn't have to have a long ugly command-line option to specify the name.
2. Get rid of the metadata for managed resources, and just use native Win32 resources.  Yes the .resources file would still be embedded in the .rsrc section, but we wouldn't need all new tools and APIs to deal with managed resources versus native resources.  You also wouldn't have ugly discrepancies like when you set the icon for your main form, but forget to set it as the application icon (which gets it into the Win32 resources, which is where the OS/shell looks).

I still think it would be possible to have managed resource embedded into the .rsrc section, but since they store things in different formats (like icons) it wouldn't help much.

Basically given the fact that I wanted resource names to be explicit, thats the main reason I pushed for not allowing wildcards.  There was also the confusion about whether wildcards should be applied recursively.  So I guess the end result was that nobody foresaw a huge customer demand, and the few people that cared (like me) seemed moderately opposed.

--Grant