TagHelper and RazorPreCompileModule don't work in the same project and reference projects

[Tragetaschen]

I have a TagHelper in the web project itself (not as a reference) and I want to use RazorPreCompileModule in that project. This throws during compilation because the preprocess step tries to load the assembly that is currently created and cannot find it (yet).

[Tragetaschen]

Here is a dark-magic-workaround:

• Instead of @addtaghelper "MyWebProjectAssembly", add @addtaghelper "MyWebProjectAssembly!preprocess"
• Drop a copy of the TagHelper class into Compiler/Preprocess (compiler/preprocess in beta1)
• Use the RazorPreCompileModule as always

That way, the Preprocess-Razor has the !preprocess-Assembly to find and reflect on the metadata of the TagHelper. It can then construct a syntax tree, and this syntax tree is compiled together with the remaining code using and binding against the real TagHelper.

It's important, that the file is a copy, since KRuntime cannot use the same file for both preprocess and normal compilation (one excludes the others).

Since the copy in the !preprocess-Assembly is only there for reflection, there is no need for any implementation. You can remove any Process or ProcessAsync implementations and strip the type to its metadata (properties, attributes, base class, etc.) and it still works.

[pranavkm]

Thanks for the analysis @Tragetaschen. One option we could explore is looking at the syntax trees in IBeforeCompileContext to extract TagHelperDescriptors from. This might avoid having to rely on the files being part of precompilation.

cc @davidfowl

[Tragetaschen]

It's probably easier to just drill into all the INamedTypeSymbols from context.CSharpCompilation.GlobalNamespace with GetTypeMembers and GetNamespaceMembers (maybe, there is a visitor, I haven't checked). This already traverses all referenced assemblies as well as the available parts from the current assembly, so there is no need to load assemblies with the ILibraryManager.

Hmm… You wouldn't even need @addtaghelper. Is there a reason to not use precompilation?

[yishaigalatzer]

For the @addtaghelper comment - We want to add tag helpers explicitly, so you can opt in/out.

Compilation is not necessary available at pre compilation, so you can't just consume it. It is not always available as sometimes you just have the compiled assemblies that contain the tag helpers. So this needs so more thought.

For now your best bet is to create custom tag helpers in a separate project you reference (its also making them a hell of a lot more reusable).

CC @davidfowl @NTaylorMullen @DamianEdwards

[pranavkm]

FYI - we do Assembly.Load to load tag helper assemblies. During precompilation, the AssemblyResolve event is not hooked up by KRE so you don't get any of the KRE behavior for assembly loading. Essentially even if you do have TagHelpers in a separate assembly, we fail to load it.

We should consider using the IAssemblyLoadContext to load tag helpers assembly. However this does not get flown from the KRE into the application today (both during runtime and precompilation).

cc @davidfowl

[NTaylorMullen]

Note that changing to IAssemblyLoadContext goes hand in hand with these two issues:

1. Add a first class extensibility point for assembly resolution of exported types Razor#254 - Add a first class extensibility point for assembly resolution of exported types
2. Tag Helpers: Investigate Assembly.Load vs. IAssemblyLoader.Load in DTH / Runtime Razor#230 - Tag Helpers: Investigate Assembly.Load vs. IAssemblyLoader.Load in DTH / Runtime