TugboatCaptain
TugboatCaptain

Reputation: 4328

How to fix the inconsistent naming convention of embedded resources in vNext?

As far as I can tell the project.json file has taken over handling the majority of properties for any given file in a project in VS2015. I've setup a project to embed files into my assembly as follows, however the resulting naming convention of the embedded resources is a departure from what is produced by the previous versions of the c# compiler.

In current state resources are embedded using the period as a separator and included the Assembly name at the beginning like: ClassLibrary3.Templates.dashboard.html

In vNext embedded resource names are produced using the forward slash as a separator and do not include the Assembly's name; well sometimes. See the accompanying picture below. .resx files seem to follow the old pattern while anything defined in the project.json is something totally new.

Can I control the naming convention with a setting somewhere? Is this a bug, feature, or a todo? I need something consistent.

{
  "version": "1.0.0-*",
  "description": "",
  "authors": [ "" ],
  "tags": [ "" ],
  "projectUrl": "",
  "licenseUrl": "",
  "resource": ["Templates/**/*.*"], // embed everything beneath this folder

  "dependencies": {
  },

  "frameworks" : {
    "dnx451": { },
    "dnxcore50" : {
      "dependencies": {
        "System.Collections": "4.0.10-beta-22816",
        "System.Linq": "4.0.0-beta-22816",
        "System.Threading": "4.0.10-beta-22816",
        "Microsoft.CSharp": "4.0.0-beta-22816"
      }
    }
  }
}

enter image description here

Upvotes: 0

Views: 515

Answers (1)

Victor Hurdugaci
Victor Hurdugaci

Reputation: 28425

That's a known issue for beta4 and below. It has been fixed in beta5. The names are now identical to the ones generated by MsBuild, with a few exceptions.

The most notable exception is that MsBuild ignores the "Resources" folder from the name. For example:

Class1/Resources/x.resx -> Class1.x.resources

while in ASP.NET 5 we have:

Class1/Resources/x.resx -> Class1.Resources.x.resources

For that, we've added support for named resources. They are useful in scenarios where you want to share resources between multiple projects, including the resource readers OR in PCL scenarios.

Upvotes: 1

Related Questions