In VS2022 I get /*OpCode not supported: LdMemberToken*/ in ILSpy it works

[jogibear9988]

I've some assemblies where I get this error in Visual studio: (in the decompilation)

/OpCode not supported: LdMemberToken/

in ILSpy the same Assembly works.

Is there an older Version of the decompilation engine used in VS2022?

[christophwille]

You can see the engine version in the top region, and yes, it is old.

[christophwille]

An update PR is open since May btw: https://github.com/dotnet/roslyn/pull/53304

[christophwille]

@sharwell do you have any news for us when ICS.D will be updated in Roslyn?

[siegfriedpammer]

I've some assemblies where I get this error in Visual studio: (in the decompilation)

/OpCode not supported: LdMemberToken/

This is likely a problem with missing references and thus not being able to detect some patterns, such as expression trees or dynamic, which tend to use ldtoken a lot. Could you share the assembly with me? Thanks!

Nonetheless, if it works in ILSpy then it should also work in VS... we probably need to improve the integration and/or make the decompiler more resilient.

However, first the already mentioned PR should be merged. Thanks!

[jogibear9988]

I've some assemblies where I get this error in Visual studio: (in the decompilation) /OpCode not supported: LdMemberToken/

This is likely a problem with missing references and thus not being able to detect some patterns, such as expression trees or dynamic, which tend to use ldtoken a lot. Could you share the assembly with me? Thanks!

Nonetheless, if it works in ILSpy then it should also work in VS... we probably need to improve the integration and/or make the decompiler more resilient.

However, first the already mentioned PR should be merged. Thanks!

the assembly is Microsoft.Data.SqlCLient and class is TdsParser

[jogibear9988]

[siegfriedpammer]

yes, that is a problem with VS being unable to provide the correct references. It won't be fixed by updating to the latest version of the decompiler, this is something that requires further improvements in VS.

[siegfriedpammer]

I just tried this myself in a classic .NET framework project simply referencing .nuget\packages\microsoft.data.sqlclient\4.0.0\lib\net461\Microsoft.Data.SqlClient.dll directly and navigating to TdsParser via SqlCommandBuilder.DeriveParameters(null);.

The result is that there is no static constructor and the fields s_longDataHeader and s_xmlMetadataSubstituteSequence are initialized as expected, which means that the transformation was successful.

@jogibear9988 what does the decompilation log (a hidden region at the end of the file) tell you? Could you please paste it here? Thanks!

[jogibear9988]

I look when I'm back at work. Mine was a Net6 Programm

[siegfriedpammer]

Now I found the (I hope) correct assembly (.nuget\packages\microsoft.data.sqlclient\4.0.0\runtimes\win\lib\netstandard2.0\Microsoft.Data.SqlClient.dll):

        static TdsParser()
        {
            s_sniSupportedEncryptionOption = TdsParserStateObjectFactory.Singleton.EncryptionOptions;
            s_maxSSPILength = 0u;
            s_longDataHeader = new byte[25]
            {
                16,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255,
                255
            };
            s_tdsParserLock = new object();
            s_xmlMetadataSubstituteSequence = new byte[8]
            {
                231,
                255,
                255,
                0,
                0,
                0,
                0,
                0
            };
            s_fSSPILoaded = false;
            Encoding.RegisterProvider(CodePagesEncodingProvider.get_Instance());
        }

(Notice the Encoding.RegisterProvider call at the end, which is the reason for the decompiler to not move the initialization of the fields to the field declarations.)

However, as you can see, the actual problem still does not occur.

I look when I'm back at work.

No hurry, thanks a lot!

[siegfriedpammer]

@jogibear9988 Any update on this?

[siegfriedpammer]

Closing - no feedback.