how to get filename of embedded resource of an dll(assembly

[danmoseley]

@tukzer commented on Sun Jun 10 2018

Issue Title

I'm working on a project where i'm trying to involve a plugin system on aspnetcore2.0 , i want to load views and controllers in seperated assemblies dynamically, thus, load static files in assembly using relative path. I implemented a EmbeddedResourceFileProvider based on IFileProvider, but failed to load resource file names.

General

I use code like below to find all the resource files embedded in assembly, which translates resourceName like "App.NYMC.UI.Views.Account.Register.js" into relative path like ''Views/Account/Register.js" which can be used in views while accessing that javascript file;

` internal virtual void AddResources(Dictionary<string, EmbeddedResourceItem> resources) { foreach (var resourceName in Assembly.GetManifestResourceNames()) { if (!resourceName.StartsWith(ResourceNamespace)) { continue; }

            using (var stream = Assembly.GetManifestResourceStream(resourceName))
            {
                var filePath = RootPath + ConvertToRelativePath(resourceName);

                resources[filePath] = new EmbeddedResourceItem(
                    CalculateFileName(filePath),
                    stream.GetAllBytes(),
                    Assembly
                );
            }
        }
    }

` Then i can reference file like this in .cshtml:

<script src="/Views/Account/Register.js"></script>

The problem is that the filePath is invalid when the file name include ".". For example, file "Views/Content/js/site.min.js" got a resource name as 'Views.Content.js.site.min.js'. So i was not able to discover its orginal file name via resourceName. I tried to get file name like this, but it returned null. var resourceInfo = Assembly.GetManifestResourceInfo(resourceName);

It seems like that the "." symbol in file name is used to be convert to "_" in .net framework, will we able to do something like or beyond that so we can identify the file name part in resourceName.

---

@leecow commented on Mon Jun 11 2018

@natemcmaster @danmosemsft

[danmoseley]

closing per discussion in other issue