Cannot Run Generators in IntegrationTests Project

[JasonBock]

For whatever reason, I can't get the source generator to run in WebAssembly.IntegrationTests. Here's the error message I get:

An exception of type 'System.IO.FileNotFoundException' occurred in WebAssembly.Generators.dll but was not handled in user code Could not load file or assembly 'WebAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2ddeabf6a9c8f742' or one of its dependencies. The system cannot find the file specified.

Here's the specific exception details:

System.IO.FileNotFoundException
  HResult=0x80070002
  Message=Could not load file or assembly 'WebAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2ddeabf6a9c8f742' or one of its dependencies. The system cannot find the file specified.
  Source=WebAssembly.Generators
  StackTrace:
   at WebAssembly.Generators.WasmTypeBuilder.Build(String wasmPath, String className) in C:\Users\jason\source\repos\WebAssembly.Generators\src\WebAssembly.Generators\WasmTypeBuilder.cs:line 28
   at WebAssembly.Generators.WasmTypeGenerator.Execute(GeneratorExecutionContext context) in C:\Users\jason\source\repos\WebAssembly.Generators\src\WebAssembly.Generators\WasmTypeGenerator.cs:line 25
   at Microsoft.CodeAnalysis.GeneratorDriver.RunGeneratorsCore(Compilation compilation, DiagnosticBag diagnosticsBag, CancellationToken cancellationToken)

For what it's worth, here's the FusionLog property value of the exception:

=== Pre-bind state information ===
LOG: DisplayName = WebAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2ddeabf6a9c8f742\n (Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/MSBuild/Current/Bin/Roslyn/
LOG: Initial PrivatePath = NULL
Calling assembly : WebAssembly.Generators, Version=0.1.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
LOG: Using application configuration file: C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Enterprise\\MSBuild\\Current\\Bin\\Roslyn\\VBCSCompiler.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\\Windows\\Microsoft.NET\\Framework64\\v4.0.30319\\config\\machine.config.
LOG: Post-policy reference: WebAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2ddeabf6a9c8f742
LOG: Attempting download of new URL file:///C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/MSBuild/Current/Bin/Roslyn/WebAssembly.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/MSBuild/Current/Bin/Roslyn/WebAssembly/WebAssembly.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/MSBuild/Current/Bin/Roslyn/WebAssembly.EXE.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/MSBuild/Current/Bin/Roslyn/WebAssembly/WebAssembly.EXE.
LOG: Attempting download of new URL file:///C:/Users/jason/AppData/Local/Temp/VBCSCompiler/AnalyzerAssemblyLoader/d903d7eade6444f39979f1e8d85b419d/7/WebAssembly.DLL.
LOG: Attempting download of new URL file:///C:/Users/jason/AppData/Local/Temp/VBCSCompiler/AnalyzerAssemblyLoader/d903d7eade6444f39979f1e8d85b419d/7/WebAssembly/WebAssembly.DLL.
LOG: Attempting download of new URL file:///C:/Users/jason/AppData/Local/Temp/VBCSCompiler/AnalyzerAssemblyLoader/d903d7eade6444f39979f1e8d85b419d/7/WebAssembly.EXE.
LOG: Attempting download of new URL file:///C:/Users/jason/AppData/Local/Temp/VBCSCompiler/AnalyzerAssemblyLoader/d903d7eade6444f39979f1e8d85b419d/7/WebAssembly/WebAssembly.EXE.

Note that all the tests in WebAssembly.Tests run just fine.

I'm referencing 0.9.0-preview of WebAssembly on purpose, as that was the last version that targeted .NET Standard 2.0. That package switched to just targeting netcoreapp3.1 for 1.0.0. I'm not sure if that is part of the reason - that is, if there's something in 0.9.0-preview that's causing the issue.

[JasonBock]

Forgot to mention this project started from this issue - I'm hoping this issue will close that one.

[jaredpar]

Sounds like the generator here depends on the WebAssembly.dll assembly. Given that the load is failing here that means it's almost certainly not being passed with the /analyzer flag. That's a requiurement for all analyzer and their dependent DLLs.

[JasonBock]

@jaredpar you're correct in that WebAssembly.Generator references WebAssembly. But WebAssembly is just a NuGet package, it's not referenced by WebAssembly.IntegrationTests (and I don't think it should be either).

[JasonBock]

@jaredpar wait....I'm looking at this sample, and it seems like you have to do a fair amount to reference another package (basically, everything after line 13). Are all of those settings and entries necessary? Meaning, you just can't do a simple <PackageReference> in a SG-based project; you need to set up more than that?

[JasonBock]

@jaredpar oh wait....I just saw this. This may be the problem....

[JasonBock]

@jaredpar OK, I tried some things, and it's still not working, nor is it generating the NuGet package either. I'm kind of stumped, not sure what I'm missing....

[jmarolf]

I got this working here: https://github.com/jmarolf/generator-start/tree/webassembly-dependency

My best guess is that some of the packages you are including are messing up with nuget packaging as I understand it. the only real difference bewteen mine and yours is that

• I am not attempting to publish symbols for the generator package (no idea how that would work tbh)
• not using sourcelink

[JasonBock]

@jmarolf I looked at what you did....but what I'm not seeing is how the WebAssembly.IntegrationTests projects references WebAssembly.Generators in a way such that it's running the generators. When I added:

OutputItemType="Analyzer"

to the project reference, I get the same error that I'm seeing in my code.

At this point, I think I'm going to revisit how this is doing what it's doing. Maybe a better way is to write a .NET tool and let it generate the .cs file based on a given .wasm file. Your comment in Discord about how you have a concern about perf since WebAssembly has to load the .wasm file itself is also a reason I'm considering the change.

[jmarolf]

ah, you want this to work as a project reference not just a nuget package. one sec let me go look up the msbuild goop

[jmarolf]

adding <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> will deploy all the dependencies to the output directory. as I've done here: https://github.com/jmarolf/generator-start/commit/d0db05af009b29406caed7bde007d472fffc8c2f

This should allow project references to find the dependent dlls as they will be laid down next to them

[JasonBock]

Thanks, I'll try that.

[JasonBock]

@jmarolf ok, you're right, that works in your branch....now I just need to figure out how to make it work on my stuff....

[JasonBock]

@jmarolf and now I have it working in my code. Of course, I'm getting an error with the gen'd code, but that's my problem :)

[JasonBock]

Or....it doesn't work again :(. This is frustrating.

[JasonBock]

Yeah, now it's not working again. I need to walk away from this. Way too annoying :|

[jmarolf]

The project reference approach is the first thing everyone tries and is the least-tested scenario. I would go so far as to say its unsupported but @jaredpar and @chsienki have placed it in the cookbook :) There are a lot of moving pieces to making ana analyzer/generator work as a project reference and it is trivially easy to make it fall off a cliff :(

[JasonBock]

@jmarolf would you say it's better just to test the generator from a NuGet package reference? I've done that as well with other source generators I've written, and in this case, I'm perfectly fine just skipping the idea of referencing a project in a test project and using a local NuGet package reference instead.

[jmarolf]

If you are shipping a nuget package at the end of the day then I would recommend doing that.

[JasonBock]

Well, I finally gave up on the IntegrationTests project. I just couldn't get it to work. But I created a project to test the NuGet package, and that's finally working as expected.