Vs2022 ver17.8.3 mpc fail

[labyte]

I have a Unity project and the following happened when I was doing AOT compilation
vs2022 ver17.7.4: ok
Vs2022 ver17.8.3: fail
Vs2022 preview: fail

I suspect it has something to do with net8.0

[AArnott]

Can you try using the source generator in our 2.6 beta? You can read about it in our README file as seen in the dev branch.

[jtabuloc]

@AArnott, Thank you for providing an alternative in this issue. I have a similar situation with AByte using Vs2022 ver17.8.3. I followed the instructions in the README file in the dev branch, but after I set it up and built it successfully, it didn't generate the "MessagePack.cs" file that contains GeneratedResolver : global::MessagePack.IFormatterResolver as it used to when executing mpc.

Here are the exact steps I did:

• I update my VS to ver17.8.3 (shipped with .Net Core 8.0.100)

• Uninstall all packages related to MessagePack (old version)

  • MessagePack
  • MessagePack.Annotiations
  • MessagePack.AspNetCoreMvcFormatter
  • MessagePack.MSBuild.Tasks

• Uninstall MessagePack.Generator tool

• Install 2.6.100-alpha

  • MessagePack
  • MessagePack.Annotiations
  • MessagePack.AspNetCoreMvcFormatter
  • MessagePack.SourceGenerator
  • MessagePackAnalyzer

• Change code to opt-in for AOT-generated formatters

static MyConnectClient()
{
    if (!SerializerRegistered)
    {
        // **** Old Code ****
        // StaticCompositeResolver.Instance.Register(GeneratedResolver.Instance,StandardResolver.Instance);
        // var option = MessagePackSerializerOptions.Standard.WithResolver(StaticCompositeResolver.Instance);
     
        // **** New Code ****
        var option = MessagePackSerializerOptions.Standard.WithResolver(GeneratedMessagePackResolver.InstanceWithStandardAotResolver);

        MessagePackSerializer.DefaultOptions = option;
        SerializerRegistered = true;
    }
}

• Added MessagePackAnalyzer.json in project root folder

{
  "$schema": "https://raw.githubusercontent.com/MessagePack-CSharp/MessagePack-CSharp/develop/MessagePackAnalyzer.schema.json",
  "generator": {
    "resolver": {
      "public": false,
      "name": "GeneratedMessagePackResolver",
      "namespace": "MessagePack"
    },
    "formatters": {
      "namespace": "Formatters"
    },
    "usesMapMode": false
  }
}

• Build the entire solution (it builds without error)

I actually expected it to auto-generate a file after the build, but it didn't. Was my expectation wrong? What am I missing here?

Our migration from .NET 6 to .NET 8 for MAUI has been blocked at this point due to this issue. I would greatly appreciate it if you could guide me in the right direction.

[AArnott]

Build the entire solution (it builds without error)
Our migration from .NET 6 to .NET 8 for MAUI has been blocked at this point due to this issue. I would greatly appreciate it if you could guide me in the right direction.

How is it blocking if it built without error?

I actually expected it to auto-generate a file after the build, but it didn't. Was my expectation wrong? What am I missing here?

It does generate a code file, but it does so as part of the C# compiler, and AFAIK it is never written to disk. You can inspect the generated code within VS though, by expanding the MessagePackAnalyzers node in the Solution Explorer under the project's Analyzers tree. Or by using Go To Definition on a reference to the generated type.

[jtabuloc]

Thank you for the response @AArnott.

It does generate a code file, but it does so as part of the C# compiler, and AFAIK it is never written to disk. You can inspect the generated code within VS though, by expanding the MessagePackAnalyzers node in the Solution Explorer under the project's Analyzers tree. Or by using Go To Definition on a reference to the generated type.

I now see the files by expanding the MessagePackAnalyzers node. I conducted a quick test by executing a console app but encountered an exception stating, "is not registered in resolver: MessagePack.Resolvers.CompositeResolver+CachingResolver" during the return (T)MessagePackSerializer.Deserialize(targetType ?? typeof(T), await response.Content.ReadAsByteArrayAsync()); operation. Note that the (T) was Response<ReferenceDto<AccountDto>>.

I have confirmed that the formatter classes (AccountDto, ReferenceDto<T>, Response<T>) were generated by the source generator.

However, one thing I noticed when comparing mpc and source generator file output is that the ReferenceDto generates a ReferenceDtoFormatter, but it was not added to the GeneratedMessagePackResolver lookup. The same holds true for other classes with generic types. Could be one possible reason why it throws an exception?

When I debugged, it can't find the formatter in GeneratedMessagePackResolver and return null.

I'm not certain if it's related to our project setup, but here is the composition.

• Core Project (a library where all models reside that use MessagePack Annotations)
• Client Project (a distributed http client API nuget package that consume Core Project. This where the files were SourceGenerator autogenerated the formatters)
• Console App (app that consume Client Project to test MessagePack 2.6.100-alpha)

This setup works in mpc, and the only changes made were to the MessagePack libraries and minor AOT configurations mentioned in my first post. I'm still trying to figure out what could be the missing piece, but if you have a suggestion that I can try, I would appreciate it.

How is it blocking if it built without error?

The build is only on my local machine, and we can't proceed with migration until it has been tested thoroughly.

[AArnott]

Thanks for those details. It sounds like we may have a bug in the source generator for generic formatters as you say. Since I haven't hit it though, would you mind writing a minimal repro and sharing it so we can address it?

[jtabuloc]

Hi @AArnott, I invited you to the sample repo that contains the generic type used during my testing. I hope the code is enough to help address the generic type issue. I apologize for the delay in getting back to you, as I had to attend to a personal matter.

[AArnott]

Thanks. I've received the invite. Just haven't had time to look at it yet. Hopefully this weekend.

[AArnott]

I think I found the problem. It won't make sense for me to fix it during the massive refactor I have going on, but I can work on it afterward.

[jtabuloc]

That is great that you have found the problem. I have no intention of putting pressure on you regarding this issue, but do you have a tentative time when you can release the fix? This is for me to evaluate our options while waiting for the fix.

[AArnott]

It's probably going to be 2-3 weeks.

[jtabuloc]

@AArnott , I hope you're doing well. I would like to get back on this topic. Have you had a chance to include this in your big refactor?

[AArnott]

I haven't forgotten, but I got stuck on part of the refactor (#1739 (comment)) and haven't heard back from nueucc. I wouldn't have let that stop me for too long, except that other priorities have come up that have taken time away from my work here.