Skip to content
This repository has been archived by the owner on Dec 19, 2018. It is now read-only.

Resolving TagHelpers from an assembly that only has runtime TagHelpers creates an error at design time. #1145

Closed
NTaylorMullen opened this issue Mar 29, 2017 · 5 comments
Assignees

Comments

@NTaylorMullen
Copy link
Member

NTaylorMullen commented Mar 29, 2017

If an assembly (Microsoft.AspNetCore.Mvc.Razor) only contains TagHelpers that have editor browsable never then we log an error in our binder syntax tree pass stating that no TagHelpers exist in the assembly.

@NTaylorMullen NTaylorMullen added this to the 2.0.0-preview1 milestone Mar 29, 2017
@NTaylorMullen NTaylorMullen self-assigned this Mar 29, 2017
NTaylorMullen added a commit that referenced this issue Mar 29, 2017
- Prior to this if all instances of `TagHelper`s in an assembly had editor browsable never we'd log an error saying that no TagHelpers were found for that assembly. Until we can evaluate a better fix for this issue I've removed the logic that logs those errors and its corresponding tests/resources.

#1145
NTaylorMullen added a commit that referenced this issue Mar 29, 2017
- Prior to this if all instances of `TagHelper`s in an assembly had editor browsable never we'd log an error saying that no TagHelpers were found for that assembly. Until we can evaluate a better fix for this issue I've removed the logic that logs those errors and its corresponding tests/resources.

#1145
NTaylorMullen added a commit that referenced this issue Mar 29, 2017
- Prior to this if all instances of `TagHelper`s in an assembly had editor browsable never we'd log an error saying that no TagHelpers were found for that assembly. Until we can evaluate a better fix for this issue I've removed the logic that logs those errors and its corresponding tests/resources.

#1145
@NTaylorMullen
Copy link
Member Author

NTaylorMullen commented Mar 30, 2017

I temporarily worked around this issue to unblock tooling folks in this commit. We never used to validate that an assembly had TagHelpers in the old world so my temporary workaround might be an ok fix. However, the error was definitely intentional so it means there was a drive for it. Other fixes could be:

  1. Have a property on descriptors, descriptor.EditorBrowsable, and then filter them out before returning any to the editor.
  2. Leave the error but conditionally add Mvc.Razor tag helper bits based on if design time or not. This would result in the MvcRazorTemplateEngine signature changing to include a design time parameter.

Looking for opinions @rynowak / @pranavkm / @ajaybhargavb

@ajaybhargavb
Copy link
Contributor

Have a property on descriptors, descriptor.EditorBrowsable, and then filter them out before returning any to the editor.

Will doing this make it so that we create descriptor only for this error check and the ones with EditorBrowable set to false will be pretty useless otherwise?

@NTaylorMullen
Copy link
Member Author

Will doing this make it so that we create descriptor only for this error check and the ones with EditorBrowable set to false will be pretty useless otherwise?

yar

@rynowak
Copy link
Member

rynowak commented Mar 30, 2017

Close? I like the solution we ended up with.

@NTaylorMullen
Copy link
Member Author

dd9eab5

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants