You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, currently, source generators can only have dependencies if they are packaged into a nuget packages. this is cumbersome UX for usecases where you write one-off source generators for yourself, for example.
i'm thinking about improving the ux for source generators by enabling easier handling of referenced dlls, especially for generators using ProjectReferences for their refs.
if we would extend the behaviour of ShadowCopyAnalyzerAssemblyLoader to inspect the deps.json of the generators and copy those files, too... would that be PRable?
I do not believe this is a viable path forward because it violates determinism in the compiler. Specifically that all inputs to the compiler, including analyzers need to appear on the command line. In the case that is done the compiler will laod them and there shouldn't be a need for looking through deps.json.
Hello, currently, source generators can only have dependencies if they are packaged into a nuget packages. this is cumbersome UX for usecases where you write one-off source generators for yourself, for example.
i'm thinking about improving the ux for source generators by enabling easier handling of referenced dlls, especially for generators using ProjectReferences for their refs.
if we would extend the behaviour of ShadowCopyAnalyzerAssemblyLoader to inspect the deps.json of the generators and copy those files, too... would that be PRable?
@jaredpar Fred suggested to ping you :-P
other pings: @PaulBraetz @viceroypenguin
P.S.: I read through dotnet/sdk#17775 but don't think the recommendations there apply :-(
The text was updated successfully, but these errors were encountered: