RazorViewEngineOptions.ParseOptions are hard to use

[DamianEdwards]

Trying to set the C# lang version that Razor uses via the RazorViewEngineOptions.ParseOptions is a less-than-optimal experience right now, as the Roslyn types are immutable.

The following doesn't compile as ParseOptions.LanguageVersion is not settable:

services.AddMvc().AddRazorOptions(options =>
                options.ParseOptions.LanguageVersion = LanguageVersion.CSharp7);

The IntelliSense leads you down a path where this looks like what you should do, but it doesn't work, because WithLanguageVersion returns a new instance of ParseOptions which gets lost to the ether:

services.AddMvc().AddRazorOptions(options =>
                options.ParseOptions.WithLanguageVersion(LanguageVersion.CSharp7));

This is actually what you need to do:

services.AddMvc().AddRazorOptions(options =>
                options.ParseOptions = new CSharpParseOptions(LanguageVersion.CSharp7));

Or probably more correctly:

services.AddMvc().AddRazorOptions(options =>
                options.ParseOptions = options.ParseOptions.WithLanguageVersion(LanguageVersion.CSharp7));

Not really sure we can do anything about this given the types are designed this way.

[benaadams]

ref return ParseOptions ?

[rynowak]

IMO we should not support/expose this at all. It's confusing and we don't really do what it says.

Here are all 20 reasons why:

• Changing this setting doesn't help because Razor doesn't respect it
• No I'm not referring to how we don't currently have support for C#7
• What I mean is that when we do have support for C#7, it won't be possible for Razor's understanding of C# won't revert back to C#6
• This may do the right thing, or may not, but we shouldn't advertise it if we're not going to test it
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything
• Putting a Roslyn type like this in DI via options causes a LOT of things to be jitted even when we don't compile anything

[pranavkm]

@davidfowl who asked for this feature. I think you're right - we should probably have a select set of things exposed on view engine options (additional references for instance). We could have extensibility \ replacability around things like CSharpCompiler in the event the user actually wants to meddle with the compilation rather than having it exposed on such a publicly visible type.

[rynowak]

@Eilon @davidfowl @DamianEdwards - my proposal is to remove this from options and try to remove this from the startup path unless you actually need it.

I think this is a holdover from DNX days.

[pranavkm]

@rynowak where did we land on this?

[rynowak]

I haven't started this yet. If you think you can get it done today that would be a load of of my mind 👍

[pranavkm]

Sure, I can take over this.