Project-system: ResXFileCodeGenerator does not emit GetTypeInfo()

[fubar-coder]

How to reproduce

I have a project that targets both net451 and netstandard1.3 with:

    <TargetFrameworks>net451;netstandard1.3</TargetFrameworks>

Expected

The code should be compilable.

What happened instead

The ResXFileCodeGenerator doesn't emit GetTypeInfo().

Workaround

I have to move the target framework netstandard1.3 to the first position to get the expected behavior:

    <TargetFrameworks>netstandard1.3;net451</TargetFrameworks>

Additional info

This seems to be related to #747.

[davkean]

No, this is different to #747 and a limitation in how the RESX designer queries the project. it's not aware of multiple frameworks - so it gets what we consider the "active" one which is the first one in the list. We'll need to think about how we solve this particular issue (in some cases - it's impossible to generate code that works everywhere).

As a workround, put netstandard first, reload the project and modify the designer to get it to regen the code.

[AArnott]

I just hit this and discovered the workaround by accident as well. The workaround is fine. But its discoverability is poor. Let's at least fix that.

[cyrilcathala]

Please note the workaround doesn't work if netstandard is the only target:
<TargetFramework>netstandard1.4</TargetFramework>

Tested on Visual Studio for Mac 7.0.1.

[execjosh]

Please note the workaround doesn't work if netstandard is the only target:
netstandard1.4

Tested on Visual Studio for Mac 7.0.1.

I am experiencing the same thing on the same Visual Studio for Mac Professional 7.0.1 (build 24).

Our project has only one target framework, and uses project.json.

...
  "frameworks": {
    "netstandard1.3": {}
  }
...

[jorgeyanesdiez]

I can confirm this still happens with Visual Studio 2017.2. and .NET Core SDK 1.0.4

[shibaev]

Please note that workaround does not help if one of the target platforms does not support Type.GetTypeInfo(). For example, <TargetFrameworks>netstandard1.3;net40</TargetFrameworks>

[dmonroym]

@ocallesp There might be no-action here but it's worth taking a look if there's a fix. The workaround in this issue seems to be doing its job for now