-
-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Razor/Blazor Support #249
Comments
We are currently working on a big refactor of the rules on the Keeping this open as a tracking issue for Blazor/Razor |
The problem with blazor (as described in another issue thread) is tight integration of blazor code generator with msbuild. I have opened an issue regarding decoupling those: code generator, after all, is a separate, albeit totally undocumented binary. Alas, they don't want to do it, as they believe their code generators to be an "implementation detail" of a general, msbuild based system. To this end, I have made myself some custom rules invoking msbuild with specially crafted csproj files (and a go helper to work around msbuild idiosyncrasies). Accommodating something like this in a general "rules_dotnet" setup will be rather tricky. :-) |
@oakad Interesting, can you link to the issue you mentioned? |
This one: #260 :-) |
My attempt at getting some docs. |
I'm wondering if it's possible to support use-cases like Razor and RazorLight but adding support for I just tried to use razor with runtime compilation
|
Razor support needs 2 obvious issues resolved:
p.2 here is a nastier problem than it may seem, because some of these assets are critical for things like Blazor/WASM; WASM simply won't work unless that stuff is copied over to a deployment bundle. It will also be a problem for runtime compilation of any sort, unless the user feels like maintaining appropriate copies of those elsewhere. |
I did a bit of a dive into this and here's what I found for Razor specifically:
the analyzer config can be found in a traditional csproj/msbuild the only part of the analyzer config that seems to matter in my testing is the following section
The $ echo 'VGVtcGxhdGVzL0V4YW1wbGUuY3NodG1s' | base64 --decode
Templates/Example.cshtml The source generator requires this config else the cshtml will be ignored when the analyzer runs: https://github.com/dotnet/razor/blob/main/src/Compiler/Microsoft.NET.Sdk.Razor.SourceGenerators/RazorSourceGenerator.RazorProviders.cs#L73-L81 The metadata is managed by msbuild: https://github.com/dotnet/sdk/blob/main/src/RazorSdk/Targets/Microsoft.NET.Sdk.Razor.SourceGenerators.targets#L48 Finally, the consuming project needs an assembly attribute otherwise MVC will not attempt to load templates from the assembly; this is added by msbuild: https://github.com/dotnet/sdk/blob/main/src/RazorSdk/Targets/Microsoft.NET.Sdk.Razor.GenerateAssemblyInfo.targets#L59 Seems like a bit of work is needed to replicate what msbuild does in the bazel rules; but might be helpful to support source generators in general because they can be used for other things as well like GRPC. |
Thanks for looking into this @Place1! This looks like it should be decent amount of work but nothing crazy. I think the first step could be to get source generator support in place. I have limited time on my hands currently so I don't think I'll be working on an implementation anytime soon but I can help with this if anybody is up to the task. |
I'm still quite interested in this but I'm not particularly confident with bazel rule implementations. @purkhusid would you be able to write up some guidance for implementing this feature?
|
I'm not too familiar with Razor nor Blazor but I think we need to do the following:
I unfortunately don't have time to do a deep dive on how the Razor compiler works but I can do my best to review. |
Hi I think I can add a little context on whats happening under the hood in blazor, or other source generators. The nice part of whats happening with the blazor source generator is that it behaves just like any other source generator. And has the same constraints. In fact a lot of the way source generators were designed was driven by blazor tooling which was apparently very complicated before. In a source generator you get access to compiled c# and additional files. For a custom generator, you would be adding those additional files explicitly in the csproj. For blazor, it seems those are all implicitly included. So, the source generators are all technically analyzers and get registered as such (like this, might be this lib specifically Output below is from @purkhusid I'm just getting oriented to bazel, but I see you already have
|
One issue i've run into while hacking on this is the editorconfig file which needs to be passed to the In my previous comment the path was The absolute path requirement seems to be by-design for analyzer config files: dotnet/roslyn#47707 (comment)
|
I think the compiler wrapper scripts we already have in place could be used to read the file that is passed to the |
I would like to build a small blazor server using bazel. The server itself builds just fine, but ends up broken, because razor, cshtml.cs and various data files are not added to the target as required.
Is building blazor servers supported at all? If yes, may there be an example somewhere on how to build those?
If not presently, may the support for those be added in the near enough future?
The text was updated successfully, but these errors were encountered: