Sergio Pedri

Right, but I'm saying there's just no reason to do so at all. T4 templates are the right tool for this. Not to mention, using source generators with a local...

> "can you elaborate what do you mean by this considering our use-cases?" The advantage of source generators is that they can dynamically generate code based on what code you're...

> "Use T4 if you want to generate code for a single project you control, otherwise you'll just end up adding even more complexity and maintenance burden." I would say...

Also hitting this one (had opened #63396 though it was a dupe of this). I'm trying to update my generator in ComputeSharp to remove IO (following the conversation in #63290),...

Sharing some more findings while testing https://github.com/Sergio0694/ComputeSharp/pull/349. I believe there's two different issues related to supporting this scenario (ie. analyzers that depend on native libs bundled with the analyzer .dll),...

> "Let me blow your mind: embed the native dlls in your assembly yourself, and write them out to disk during DLL startup." My mind was not blown, as that's...

Roslyn, yes. If it just ignored native PEs, then all would be fine 🙂

Yeah, I'd assume the issue is originating here: https://github.com/dotnet/roslyn/blob/dd044537d55b074e49c8ed8eab74a8cc6895389c/src/Compilers/Core/Portable/DiagnosticAnalyzer/AnalyzerFileReference.cs#L451-L469 Where the loader just tried to get the `Assembly` from the input .dll, which will of course crash for a native...

Do you know who we should ping from the MSBuild team about this? With its behavior currently being this, and leading Roslyn to just fail to load analyzers entirely, we're...

> "or embedding them as resources" I'm one of those, as that's what I'm currently doing in ComputeSharp. As I mentioned though that has major issues, because: - The logic...