Warning: Need to add this ability (to set options) to CodeActionResolve too, because the first thing it does is compute code actions again :( At least there we have CodeActionResolveData I can probably abuse :)

Could you point to code that sets the option value on an instance of CodeGenerationOptions?

I'm going to wait on Tomas being ok before looking :)

Could you point to code that sets the option value on an instance of CodeGenerationOptions?

For an LSP request the value is set by wrapping the options provider:
https://github.com/dotnet/roslyn/pull/66917/files#diff-93009ab52d3bb3062b613014e84528202206753601dee250968bd7f2dbbbcb22R91

Otherwise the CodeGenerationOptions constructor sets it from the fallbackOptions, which is what makes document.GetCodeGenerationOptionsAsync work, here:
https://github.com/dotnet/roslyn/pull/66917/files#diff-00c9880ecd7bbcfd5d3747b2aaa5c9756260052c0eab6d1a886edaf342250689R40

On second thought, I think we might need a different approach here. I think we need to do what AddImportPlacementOptions.AllowInHiddenRegions, or perhaps move it to CodeGenerationOptions and reuse it, because this does need to depend on the document in question. Unfortunately it also depends on the request coming from the Razor LSP client. So we need a document based property to know whether to honour the CodeGenerationOptions property :(

The problem is if we have a Foo.razor file and a Goo.cs file that had hidden regions in it, then currently this change will mean code actions requested from Foo.razor will offer to generate in hidden regions of Goo.cs, which we don't want. If we just use the document properties service approach though, code actions requested from Goo.cs will offer to generate in Foo.razor[.g.cs], but nothing will be processing the result of the code action request to actual make those edits valid.

The question is how to tell the document is a razor document. We could add something to DocumentPropertiesService for AllowGenerateInHidden, but I thought we wanted to remove that. We could do what AddImportPlacementOptions.AllowInHiddenRegions does, which is check for a span mapping service, which is disingenuous since its not the span mapping service that will be doing the work here. Or we could do something else. Make AllowGenerateInHiddenCode take a filename pattern? 🤮

Thoughts?

Do we even care about hidden regions for non-asp.net files? As far as I understand from the code comments, thats what it was added for. I would be surprised if people were manually creating them, and were happy not getting code generation offered. Also worth mentioning that we'll eventually be switching to using the razor source generator documents instead of IDynamicFile so all of the document services and document properties bits would need to be replaced with something else anyway.

we'll eventually be switching to using the razor source generator documents instead of IDynamicFile so all of the document services and document properties bits would need to be replaced with something else anyway.

Right, so that's what troubles me about adding more document services based approach.

It seems like we need to rethink how code actions for Razor should be architected rather than just adding one-off flag.

It seems like we need to rethink how code actions for Razor should be architected

I don't disagree, but I also don't want to block this forever. Even if we consider this a temporary hacky fix, it unblocks Generate Method for razor users, and that's the 3rd most used code action in C#. I guess I'll set up a meeting and we can talk about it more.

Random thought/realisation: If we separate "Generate Method" and "Generate Method into a different document" into two code fixes, then Razor could just allow-list the former, and this PR would be sufficient. The latter would then be unblocked by the more elaborate re-architecting that we're talking about.