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 1.3 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.