Using 1.x tag helper in net core 3

[Muchiachio]

Describe the bug

While upgrading our applications to net core 3 we noticed that none of our tag helper libraries written in core 1.x work on net core 3. Updating them to asp net core 2.2 version seems to fix the problem. Did something changing in how tag helpers are resolved or is this a bug?

To Reproduce

1. Checkout repro
2. Run master branch
3. Email tag helper is not being run
4. Checkout and run working branch which uses 2.2 packages
5. Email tag helper is run

Expected behavior

1.x version tag helpers referenced from net core 3 are discovered and run

Additional context

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100
 Commit:    04339c3a26

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18362
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.0.100\

Host (useful for support):
  Version: 3.0.0
  Commit:  7d57652f33

.NET Core SDKs installed:
  3.0.100 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[javiercn]

@Muchiachio Thanks for contacting us.

Do the tag helpers light up in visual studio? Have you checked you are using @addTagHelpers to bring them into scope?

Can you provide a minimal repro project so that we can investigate?

[Muchiachio]

They don't light up. I did provide a repro in the first step 👍

[javiercn]

Thanks, I missed the repro.

@NTaylorMullen @ajaybhargavb Ideas?

[mkArtakMSFT]

@ajaybhargavb can you please look into this to understand why this isn't working? Let's have a conversation then.

[davidfowl]

cc @DamianEdwards

[NTaylorMullen]

@mkArtakMSFT i'm taking a look now, re-assigning.

[NTaylorMullen]

The gist: So I looked into this and what's happening is that the Roslyn compilation that we're operating on at tooling time and at runtime have two different symbols for ITagHelper, one that comes from the 1.0 version of Microsoft.AspNetCore.Razor.Runtime and another that comes from the 3.0 variant.

Details: When we try to detect that the 1.0 projects(1.0P) TagHelper(Foo) "is a TagHelper" we compare Foo's interfaces against the 3.0 ITagHelper interface. We find that Foo's interface looks like the 1.0 ITagHelper symbol and then fail our "is a TagHelper" check because it's not the 3.0 ITagHelper interface. Foo's ITagHelper interface is definitely odd though because it says that it's containing assembly is the "3.0" assembly; however the properties of Foo's ITagHelper interface say different. For example we added ITagHelperComponent as an implemented interface in 2.0 and that doesn't exist on Foo's ITagHelper symbol leading me to believe it's interpreting the symbol from the 1.0 package.

Also, for what it's worth, the deps.json (not sure how much it has to do at design time) looks to have thrown away the 1.0 projects reference to Razor.Runtime and is using a lifted version (in my case it's lifting it to 2.0 because the parent project is referencing a 1.0 and a 2.0 TagHelper project).

Sooo, it looks like something funky is going on with the way Roslyn's compilation is interpreting the projects? @jasonmalinowski @agocke can you both take a look? If needed I or @ajaybhargavb can help you get yourself setup into a good debugging environment for this.

Lastly, @Muchiachio would you mind pushing the master branch to that repo? I was able to reproduce but had to re-create the 1.0 project. It'd be nice if others looking at this had the master branch to work from.

[NTaylorMullen]

I forked @Muchiachio's repo and pushed a notworking branch: https://github.com/NTaylorMullen/Taggy

[Muchiachio]

Sorry, didn't notice that github client didn't push master branch (it's one commit back), should be fixed now.

[rynowak]

@NTaylorMullen - would check if the SDK/RAR is unifying assemblies properly - ie, are there two versions of Microsoft.AspNetCore.Razor.Runtime that are being passed to the compiler.

[mkArtakMSFT]

@JunTaoLuo can you please work with @ajaybhargavb to get your fix validated.

[ajaybhargavb]

Verified with a private build from @JunTaoLuo that it fixes this issue. 👍

[ajaybhargavb]

@JunTaoLuo assigning this to you. Please close this issue when your fix is in.

[mkArtakMSFT]

@JunTaoLuo I know you've been working on this. What's the latest on this?

[JunTaoLuo]

This was fixed in #14538. We have not yet gotten a build of it for verification though.

[pranavkm]

@JunTaoLuo moving this out to 3.0.x for further verification. I verified that TypeForwardedTo attributes show up correctly in ref assemblies of 3.1.0-preview2 builds.

[JunTaoLuo]

I've verified that the 3.0.1 build's ref pack now contains assemblies with the expected typeforwardedto attributes.