search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.29k stars 4.74k forks source link

Equivalent for System.CodeDom configuration element? #1434

Open hippiehunter opened 4 years ago

hippiehunter commented 4 years ago

Under .Net Framework I used to register my CodeDomProvider in machine.config. It looks like the build targets for aspnet core have a hard requirement that languages have a CodeDomProvider, but I don't see a way to register it in netcore. Poking around in https://github.com/dotnet/runtime/blob/master/src/libraries/System.CodeDom/src/System/CodeDom/Compiler/CodeDomProvider.cs makes it look like everything is hardcoded to only support C# and VB.

danmoseley commented 4 years ago

like the build targets for aspnet core have a hard requirement that languages have a CodeDomProvider,

@anurse do you support building an ASP.NET Core app without VB/C#?

https://github.com/dotnet/corefx/issues/12180#issuecomment-366542284 tells me that ASP.NET Core does not use CodeDOM at all.

@hippiehunter what are you trying to do -- do you have a custom language?

Generally we would recommend that new code use Roslyn API's, rather than the very old CodeDOM API which (as you point out) are not as extensible in .NET Core via config files.

hippiehunter commented 4 years ago

Yeah I have a language. Historically there hasn't been a problem building Controllers, but it seems like Razor has been injected as a non optional part of the build system in 3.0/3.1. There is a carve out in their targets file to prevent this from burning F# specifically, but that doesn't really help me.

The task that appears to have a requirement for a CodeDomProvider is WriteCodeFragment and its getting called from Microsoft.NET.Sdk.Razor.MvcApplicationPartsDiscovery.targets and that appears to be brought in by the Microsoft.NET.Sdk.Web sdk.

danmoseley commented 4 years ago

Makes sense. The right answer here is likely for them to provide a general non codedom path rather than reinvent config files for this. @anurse can advise.

analogrelay commented 4 years ago

ASP.NET Core doesn't use CodeDOM at all AFAIK. And Razor pages always include C# syntax, but should work in a F# project, I believe. cc @rynowak @NTaylorMullen @mkArtakMSFT

hippiehunter commented 4 years ago

To be clear, I'm not actually trying to do anything with Razor pages and I'm a custom language not F#. My mention of F# was only because it looks like someone noticed this problem for F# and put in an explicit workaround in the targets file when the language name equals 'F#'.

danmoseley commented 4 years ago

@anurse apparently you are indirectly, as @hippiehunter points out, this build task you are calling uses CodeDOM unfortunately. (oddly enough I believe I implemented it in a previous life...)

https://github.com/dotnet/aspnetcore-tooling/blob/master/src/Razor/src/Microsoft.NET.Sdk.Razor/build/netstandard2.0/Microsoft.NET.Sdk.Razor.MvcApplicationPartsDiscovery.targets#L65

analogrelay commented 4 years ago

I think someone on @mkArtakMSFT 's team is going to have to look deeper here. I don't really have any context on the Razor SDK.

rynowak commented 4 years ago

@hippiehunter - can you be specific about what we can do to help? This code generates attributes that are used by the MVC part of the runtime.

hippiehunter commented 4 years ago

@rynowak One option would be to make System.CodeDom.Compiler.CodeDomProvider.AddCompilerInfo and System.CodeDom.Compiler.CompilerInfo.CompilerInfo(CompilerParameters compilerParams, string codeDomProviderTypeName) public. because any language's build system targets will have been run first, I think a language provider (me) could just bundle their CodeDomProvider into their build system nuget package and ensure AddCompilerInfo has been invoked. That's the most complete answer I think I have, but if that's not a viable I can keep digging for alternatives.