-
Notifications
You must be signed in to change notification settings - Fork 340
MSAL.NET 2.6.0 released
Since MSAL.NET 2.2.0 released, there were a number of releases improving MSAL.NET based on your feedback but the changes were mainly communicated with the release notes. With MSAL.NET 2.6.0, we are getting one step further to our goal of removing the -preview tag on MSAL.NET. We thought it was useful to update you on the progress made.
MSAL.NET supports multiple platforms. When you want to write applications working on several platforms, you will probably create a library targeting the MSAL.NET .NET Standard platform. The problem is that, in the case of multi-target projects, the assembly actually used by .NET is different:
- at coding or build time (IDE, msbuild)
- and at runtime (CLR).
The picture below shows the case of a .NET Core application and an Android application which reference a shared code library targeting the .NET standard platform.
If you are interested in learning more about what is .NET standard, how .NET resolves platforms, what it means to build against .NET standard and what happens at runtime, read Understanding multi targetting and NetStandard.
Until MSAL.NET 2.6.0, there were differences between the public API surface exposed in different platforms (that is fine), but also with the public API of the .NET standard platform. When you were developing shared code libraries, you were hit by two kind of issues:
- The concrete platforms could have more APIs than .NET standard, which was making your life difficult: You basically had to create multi-platform projects yourself, and use conditional compilation.
- Also because the edit/build time and runtime assembly resolution is different, and the public API was different, you could get, at runtime, and on some platforms only, a
MethodNotImplementedException
, whereas your code was building fine. Debugging these exceptions was also difficult as the exceptions were not actionable
With MSAL.NET 2.6.0, the public API of the .NET Standard platform was re-thought so that you can more easily build cross-platform libraries:
- The public API was introduced each time it made sense for you to use it in the .NET standard assembly.
- In the case of methods that do not make sense in some platforms, either they do nothing, or they throw a meaningful and actionable
PlatformNotImplementedException
, which has an aka.ms link to MSAL.NET conceptual documentation
The MSAL.NET nuget package also now contains, in addition to platform assemblies (let's say implementation assemblies, the ones used at runtime) a set of corresponding reference assemblies, which are used at edit and build time. Think of reference assemblies as kind of interface assemblies: they have the .NET metadata, but not the IL body.
- Home
- Why use MSAL.NET
- Is MSAL.NET right for me
- Scenarios
- Register your app with AAD
- Client applications
- Acquiring tokens
- MSAL samples
- Known Issues
- AcquireTokenInteractive
- WAM - the Windows broker
- .NET Core
- Xamarin Docs
- UWP
- Custom Browser
- Applying an AAD B2C policy
- Integrated Windows Authentication for domain or AAD joined machines
- Username / Password
- Device Code Flow for devices without a Web browser
- ADFS support
- Acquiring a token for the app
- Acquiring a token on behalf of a user in Web APIs
- Acquiring a token by authorization code in Web Apps
- High Availability
- Token cache serialization
- Logging
- Exceptions in MSAL
- Provide your own Httpclient and proxy
- Extensibility Points
- Clearing the cache
- Client Credentials Multi-Tenant guidance
- Performance perspectives
- Differences between ADAL.NET and MSAL.NET Apps
- PowerShell support
- Testing apps that use MSAL
- Experimental Features
- Proof of Possession (PoP) tokens
- Using in Azure functions
- Extract info from WWW-Authenticate headers
- SPA Authorization Code