Retain paths to embedded resources

[Alxandr]

Currently, if I do k build on a project with a few embedded resources, it doesn't care where those resources are. So if I have

• project.json
• source.cs
• index.html
• js/
  • app.js
  • lib/
  • jquery.js

And my project.json has

{"resources":  ["index.html", "js/**"]}

The result ends up with 3 resources.

• index.html
• app.js
• jquery.js

All the path-information is lost. I haven't tried to see what would happen if I were to add multiple files with the same name in different folders, but I can't imagine the result would be good.

[Eilon]

Are you looking for it to generate something like js.lib.jquery.js? I think VS does something like that (though in VS it's overridable with the "Custom Tool Namespace property).

[Alxandr]

No. As I was talking with @davidfowl over at JabbR, the most useful (and probably simplest) thing to do would simply be to shove the relative path as the name. So I'd get js/lib/jquery.js. That way, I know it's not js.lib/jquery.js for instance. The important thing is consistency though. If foreslash is used to separate directories, it should be so on all systems. Same goes for backslash.

[Eilon]

js.libjquery.js?

[Alxandr]

Lolwut? Is that image some github markdown I don't know about, or was that on purpose?
Anyways, what's wrong with just using paths? It allows for easy doing an Owin module that takes requests and maps them to embedded resources (should you ever want to do such a crazy thing (hint; I did it)). But as long as it's reasonable I'm ok with most formats. Just don't prepend it with default namespace as VS does, cause as far as I know there's no way to get that at runtime.

Also, for those wondering, there's no problem with having a / in the name of an embedded resources. I've tried this, it works just fine.

[Eilon]

It's Slash from Guns N' Roses 😄

[Alxandr]

Oh. Right. The point was, imagine if I have this stupid setup:

• js/lib/jquery.min.js
• js.lib/jquery.min.js
• js.lib.jquery/min.js
• etc.

How on earth would you tell them apart if you just translate directory separator into a .?

[Alxandr]

Though, that's ofcause highly theoretical (and moronic thing to do). A benefit of having the actual paths is that it allows you to actually "unpack" the embedded resources from a .dll.

[Eilon]

Yes I agree with this, I was just reverse-trolling 😄 The embedded FS is a reasonable scenario and I think we'll want to do things to support that.

For example, here's Katana's "embedded file system" implementation, which is one possible direction we could go in for ASP.NET vNext:
https://katanaproject.codeplex.com/SourceControl/latest#src/Microsoft.Owin.FileSystems/EmbeddedResourceFileSystem.cs

[davidfowl]

Yar, gonna assign this one to myself, as it's an easy fix. Will need to notify some other project owners about changes

[Alxandr]

@Eilon As far as I can tell, if you take the function https://github.com/aspnet/KRuntime/blob/dev/src/Microsoft.Framework.Runtime/NuGet/Utility/PathUtility.cs#L63 and plug it in https://github.com/aspnet/KRuntime/blob/dev/src/Microsoft.Framework.Runtime.Roslyn/EmbeddedResourceProvider.cs#L16, you would get something that'd work with the EmbeddedResourceFileSystem you linked. And it requires 1 line of code change.

[davidfowl]

We need to think about this a bit. The slashes would need to be consistent cross platform. I should be able to write an app that runs on both x-plat with the same logic for accessing resources

[Alxandr]

Then use forslashes and treat them as urls?

[davidfowl]

So we're going to hard code /. The default resource path is compiler/resources/**/*.*.

Example code for accessing a resource:

assembly.GetManifestResourceStream("compiler/resources/foo.jpg")

[Eilon]

Seems like a lot of cruft...

[davidfowl]

We could do, resources/*/ instead, we went with compiler instead to not conflict but I'm fine reverting that decision

[Eilon]

Yeah the compiler thing is a boring implementation detail of ours...