Microsoft.CodeAnalysis not found

[ViRuSTriNiTy]

When compiling a project I get the following error:

CS8785

Generator 'NTypewriterSourceGenerator' failed to generate source. It will not contribute to the output and compilation errors may occur as a result. Exception was of type 'FileNotFoundException' with message 'Could not load file or assembly 'Microsoft.CodeAnalysis, Version=3.11.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.'.
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.CodeAnalysis, Version=3.11.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.
File name: 'Microsoft.CodeAnalysis, Version=3.11.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
at NTypewriter.SourceGenerator.NTypewriterSourceGenerator.Execute(GeneratorExecutionContext context)
at Microsoft.CodeAnalysis.SourceGeneratorAdaptor.b__5_5(SourceProductionContext productionContext, GeneratorContextBuilder contextBuilder)
at Microsoft.CodeAnalysis.UserFunctionExtensions.<>c__DisplayClass3_0`2.b__0(TInput1 input1, TInput2 input2, CancellationToken token)

I know that this is a dependency of the source generator and I remember having to tackle this error with my own source generators but I currently don't remember what the solution was.

Any idea?

[NeVeSpl]

This is something new, something has changed in one of the latest versions of VS. What is interesting the exception happens after the source generator successfully generates files, *.ts files are saved on the disk, and *.cs files are added to the compilation, the build is done successfully, but generated *.cs files are not displayed in Solution Explorer.

[ViRuSTriNiTy]

Perhaps it helps to update the dependencies to the latest version? For example the package Microsoft.CodeAnalysis is at major version 4 something already. My guess is that other dependencies can be updated too.

[ViRuSTriNiTy]

Another possible issue could be code analyzers running in the background. I have a custom one running in the background and it has some issues with respecting the rules applied via .editorconfig when NTypewriter.SourceGenerator adds something to the compilation. This is really strange and I should first verify whether this issue also exists with a source generator implemented on my own.

[NeVeSpl]

3.11 is the last one that is running under VS 2019, upgrading dependencies would mean dropping support for VS 2019. VS has binding redirects set up, so it is really strange that somehow still is looking for 3.11.

I do not have any custom analyzers, and I can reproduce exactly the same problem, an application can be built and run, and generated types exist at runtime, but somehow VS throws expectations during editing before adding them to compilation.

[ViRuSTriNiTy]

Perhaps Microsoft.CodeAnalysis should be added as embedded resource like the other DLLs added here:

NTypewriter/NTypewriter.SourceGenerator/NTypewriter.SourceGenerator.csproj

Line 76 in f43e26d

<!-- Above "official" way does not work sometimes, sooooo, to be sure, let us embedded dependencies -->

[ViRuSTriNiTy]

It seems like we have a compiler toolset issue here, that cannot be reasolved easily or even reasolved at all.

This answer on SO provides a solution where you can enforce a specific toolset version. I did try all versions available and when I use like 3.1.something everything in my code breaks because I use latest C# features, .editorconfig is not working as expected etc.

Especially the .editorconfig thing caught my attention, because with NTypewriter added to the project, the source generated code is not analyzed correctly because rules set in .editorconfig are not working anymore. So, it seems like NTypewriter somehow enables an outdated toolset (to me it is outdated because I use latest VS 2022), which then produces issues.

Is there an option to compile NTypewriter with the latest versions of all dependencies and provide this compilation as a package? Like a preview version or something?

[ViRuSTriNiTy]

Ok, the non-working .editorconfig is currently an open issue and the solution is to use .globalconfig, see dotnet/roslyn#47384 (comment). So, this is solved for me, but the initial issue still exists.

[NeVeSpl]

I have published a new version of SG, with upgraded Microsoft.CodeAnalysis.* dependencies from 3.11 to 4.0.1, and a slightly more sophisticated approach to resolving assemblies.

It seems to work on the latest VS, and from MSBuild, but somehow when used with dotnet build, it is not always successful.

And answering your question, why Scriban.Signed , or any strongly named assembly: because you can load multiple versions of strongly named assemblies into the same app domain.

[ViRuSTriNiTy]

It seems to work on the latest VS, and from MSBuild, but somehow when used with dotnet build, it is not always successful.

I can confirm that the not found error is now gone and dotnet build often does not execute the SG, but dotnet build --no-incremental does! The --no-incremental forces a rebuild, therefore also forces execution of the SG. I think this behavior is normal. With the old package, the SG also only always runs when rebuilding.

[ViRuSTriNiTy]

Issue is fixed with latest release, therefore closed.