[Bug] MissingMethodException due to forced WAM upgrade
See original GitHub issueLogs and network traces
System.MissingMethodException: Method not found: 'Void Microsoft.Identity.Client.Core.MsalLoggerExtensions.Verbose(Microsoft.Identity.Client.Core.ILoggerAdapter, System.String)'.
at Microsoft.Identity.Client.Broker.RuntimeBroker.IsBrokerInstalledAndInvokable(AuthorityType authorityType)
at Microsoft.Identity.Client.ClientApplicationBase.GetAccountsFromBrokerAsync(String homeAccountIdFilter, ICacheSessionManager cacheSessionManager, CancellationToken cancellationToken)
at Microsoft.Identity.Client.ClientApplicationBase.GetAccountsInternalAsync(ApiIds apiId, String homeAccountIdFilter, CancellationToken cancellationToken)
at Microsoft.Identity.Client.ClientApplicationBase.GetAccountsAsync(CancellationToken cancellationToken)
at Microsoft.Identity.Client.ClientApplicationBase.GetAccountsAsync()
Which version of MSAL.NET are you using? MSAL.NET 4.50.0
Platform net7.0
What authentication flow has the issue?
- Desktop / Mobile
- Interactive
- Integrated Windows Authentication
- Username Password
- Device code flow (browserless)
- Web app
- Authorization code
- On-Behalf-Of
- Daemon app
- Service to Service calls
Is this a new or existing app? The app is in production, and I have upgraded to a new version of MSAL.
Repro
var app = PublicClientApplicationBuilder
.Create(ClientId)
.WithDefaultRedirectUri()
.WithBrokerPreview()
.WithParentActivityOrWindow(....)
.Build();
var accounts = await app.GetAccountsAsync();
Expected behavior Works just like in 0.49.1.
Actual behavior Throws MissingMethodException.
Issue Analytics
- State:
- Created 7 months ago
- Comments:7 (2 by maintainers)
Top Results From Across the Web
System.MissingMethodException: Method not found?
I resolved this issue by installing the correct .NET Framework version on the server. The website was running under version 4.0 and the...
Read more >MissingMethodException / "Method not found" after update ...
Hi, Today I've tried updating the NuGet package from 4.7.145.0 to 4.8.0.0 and I'm running ... or fix this if it is an...
Read more >PingAccess 5.2 Manuals
WAM session initiation. When a user authenticates, PingAccess applies the application and resource-level policies to the request.
Read more >PingAccess Server 4.1 - PingFederate - Ping Identity
Ping Identity may occasionally update online documentation between releases of the related software. Consequently,.
Read more >MissingMethodException Class (System)
MissingMethodException is thrown when code in a dependent assembly attempts to access a missing method in an assembly that was modified. MissingMethodException ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hmm, well we rely a lot on internals, so can’t remove
InternalsVisibleTo
. Somehow globally catching MissingMethodEx and retrowing may not be accurate. Not sure what proper way to do this would be. Once the fix for packaging goes in the next release, that should reduce these errors, since Interop will be loaded automatically.I see what the problem was. I went to VS and updated all my packages to the latest available versions, but, by default, VS does that only for stable packages, not for the preview ones, so it only updated Microsoft.Identity.Client from 4.49.1 to 4.50.0 and Microsoft.Identity.Client.Extensions.Msal from 2.25.3 to 2.26.0. It did not update Microsoft.Identity.Client.Broker from 4.49.1-preview to 4.50.0-preview. Still, after updating to the latest, I get a different exception:
I’ve looked at the source of that package, and I only see a build folder, not a buildTransitive. That is probably why the need of a manual installation is needed. I believe this should be addressed.
I also agree with @bgavrilMS, the
InternalsVisibleTo
is makes it impossible to detect breaking changes, but this could/should also be solved at a NuGet level. The new package has a binary incompatibility with the previous version, so in semver that would mean a major version bump. The package should have a dependency on a specific major version, with an upper bound.