Embedded Resource Name Loses Extension When File is Nested

Question

I have some scripts stored in files that I've marked as Embedded Resource. I nest each of these files under their associated .cs file. Unfortunately, for some reason, when you nest a file this way, the embedded resource name loses the file extension. This means that at runtime I have no way to identify which embedded resources are or aren't scripts. What can I do about this?

One thing I tried that did not work: getting the ManifestResourceInfo object, which has a FileName property. Unfortunately this property is null.

Another thing I tried was doubling up the extension. (like: filename.ext.ext). This didn't work, and everything after the first . is still missing.

I tried naming the resource with something very different, and noticed that the resource name didn't even change. It seems that it is generating the resource name for a nested embedded resource file based off of the "dependent upon" file, which in this case is just a regular .cs file. I tried doubling the extension of the .cs file to filename.extrastuff.cs but the resource name still doesn't change. It insists on clipping everything after the first ..

No, ok, I see now that it is actually naming the resource after the type defined in the .cs file, not the filename of either file. This is why the extension makes no difference. This means there is nothing I can do to either filename to help find the resource.

Answer 1

I discovered that the reason the file loses its extension is because for some reason when the file is nested, VS is naming the resource after the type instead of after the file.

The only thing I've found to allow me to still have an extension when nesting is to manually edit the .csproj file and add a LogicalName tag, which allows you to override the resource name.

<EmbeddedResource Include="Path\To\NestedFile.ext">
  <LogicalName>NestedFile.ext</LogicalName>
  <DependentUpon>ParentFile.cs</DependentUpon>      
</EmbeddedResource>

Unfortunately, there is no IDE support for this, and the FileNesting extension I'm using doesn't support writing this tag either.

It's too cumbersome to have to do this for every file, so instead of relying on the file extension, I would have to do something like add an identifier inside my script files that identifies them as scripts.

Ultimately I realized that since in my case I'm validating script files from unit tests, I can simply scan the file system instead of the resource manifest and avoid this problem altogether.