Source Generators: Allow embedding of files other than source

[chsienki]

We've seen from several customers the want to embed other files into the output assembly, particularly EmbeddedResources (see #49923)

We should explore an API that allows generators to add 'other' inputs to the compilation other than just source. This could be scoped explicitly to EmbeddedResources, or we might want to allow e.g. AdditionalFiles too.

Expanding it out to more types might have implications for analyzers, as they would be able to see them as well, but given that analyzers today see the generated source this seems desirable (although we might need an API that returns the provenance of the thing, such as Generated or Not).

[lsoft]

Could I ask to add a possibility to include a non-compilable additional files? I need to send some metadata from SG to my VSIX (and update custom codelenses with that metadata), so I need to access that metadata (for example XML file) in Compilation, but I don't need to have that XML in the binaries (so, it is not a resource, not an embedded resource, but something like BuildAction=None in Property window).

[ChrML]

This would be great. Source generators should be able to add other types of files to the output. One example would be Swagger that could generate the OpenAPI file at compile time and add the resulting .json to the compile output. Unless there is another way that could be done?

[elv1s42]

Would be very useful!
Another example is to use source generators for generation of some partial views like .cshtml or .razor files.

[khaled-saleh-sf]

Any updates on this?

[zlepper]

Concrete use-case from my company:
We have a shared library that defines a set of formats that we can generate based on other files (think images from videos and such). Based on those format classes we generate a whole API and database definition (with ef core). Right now we do this by using the metadata loader, and then inspecting the whole assembly, however this is both slow and means we need 2 code paths in our generator, one for dealing with assemblies and one for dealing with compilation metadata (for example for when the source generator is invoked from an IDE).
Instead we would like to generate json file (or equivalent) that contains metadata about the formats, that we can then use to generate the full controllers/database. We can technically get away with putting in an assembly level annotation, but just having an embedded resource we could read would probably be much easier and much clearer.

[rick-palmsens]

Our use case:
We have a single C# backend, and build multiple applications on top of that using different frameworks. Most of these applications will use a lot of the same colors and styling. We would like to create a single source of truth and generate resources/themes/styles for each platform from that.

[AaronSymons]

I think this is a great idea!

Generating C# source code is fantastic, but being able to generate other file types, such as .cshtml, would increase the value of the generators even more.

I understand that .cshtml files are not considered source code, so perhaps an IContentGenerator could be the way to go for that. Further, there could be an IResourceGenerator to handle creating other types of files and resources (I'm starting to think that different generator interfaces could be concerned with different resource build actions). This way, separation of concern is preserved, and the feature availability of code generators in general is expanded and enriched.

As well as that, we could perhaps give flags to context.AddSource() in order to describe what kind of resource or file we're generating, and therefore describing how to handle the generation with regards to project inclusion and build action, for example.

Personally, if I can use generators to create .cshtml and .xaml files, I will be hitting a new and higher level of productivity!

Thanks, and much respect to the dev team (who I imagine are already considering such ideas)! 😄

P.S. As a fellow developer, I understand that requests and ideas are often far beyond the current concerns and/or reach of development goals. I'm just here as a voice in favour of supporting generating different file types because it's incredibly useful and... it's awesome!

[mgaffigan]

I'd love to see this available from source generators. Two use cases come to mind:

1. Generate bindings to .Net types from callers in other languages (C# types -> C headers, idl, tlb, and reg files for COM)
2. Generate ADMX files from C# models

Both of these are possible through secondary build actions which analyze the produced dll, but source generators are much easier.

[cdhanna]

this feature would help me as well. I'm using source generators to generate a virtual lookup table, but I would also love to generate some static resource file about that metadata that downstream consumers could read without having to load up the .dll file itself to get the coded lookup table.

[opticfluorine]

Also chiming in that this would be very useful. My use case: I am using Incremental Source Generators to generate bindings to an embedded Lua scripting engine, and I would also like to be able to generate API documentation files that I can later ingest into Sphinx or similar to generate API docs for my generated bindings.

[rjsams]

As other have pointed out, there is a major use case for generating bindings to non-C# code. After doing all the work to serialize the game objects with a source generator, we realized it would be a huge improvement to use that same code to generate the C++ bindings to the game client. We made this work but it's explicitly not an official use case.

It would also be great if this could be triggered as a build step and avoid it constantly running via IntelliSense.

[shueybubbles]

My use case - I want to rewrite this nuget package. It converts .strings files into a combination of .resx and .cs files. The .strings format allows you to specify the parameters needed by the format string so you get a strongly typed wrapper method instead of the generic ResourceManager method you get with the traditional .resx designer.

Due to the fast changing nature of multi-targeting builds and Dotnet evolution, keeping this package working cross platform has been a trial. It's also not very VS friendly, as Intellisense doesn't recognize the generated wrapper classes.