-
Notifications
You must be signed in to change notification settings - Fork 377
Build and Test
Make sure you install VS with the following workloads:
- .Net Desktop Development
- Universal Windows Platform Development
- Mobile Development with .Net
- .Net Core cross-platform development
Some of the sample apps will require extra components, such as Windows SDKs, .Net Framework SDKs etc. You can either ignore those projects (unload them) or follow the instructions / error messages to install the extra components.
MSAL is a multi-target library and at the time of writing, VS for Mac is not able to understand and layout this project correctly. You can still build from the command line.
- Load LibsAndSamples.sln for a bigger solution with lots of apps that exercise MSAL. Load LibsNoSamples.sln for a small solution that has the library and the tests.
- Build in VS or via the command line with "msbuild /t:restore" and "msbuild"
Note: if you run into strong name validation issues, please log a bug. Workaround is to disable it on your dev box by running Admin Dev Prompt > sn -Vr *
You won't be able to run the Integration test or Automation tests because they require access to a Microsoft KeyVault which is locked down. These tests will run as part of our DevOps pipelines though.
Run the unit tests from the assemblies:
- Microsoft.Identity.Test.Unit.net45
- Microsoft.Identity.Test.Unit.netcore
From VS or from the command line if you wish to control the versioning:
msbuild <msal>.csproj /t:pack /p:MsalClientSemVer=1.2.3-preview
MSAL is a multi-target library. To enable us to target Xamarin as well as .Net core, we took a dependency on the MsBuild SDK extras - https://github.com/onovotny/MSBuildSdkExtras
Unfortunately dotnet
commands do not work with MSBuildExtras, except dotnet test
. However, dotnet restore
and dotnet build
don't do much except shelling out msbuild, so please use msbuild /t:restore
and msbuild
if you wish to build from the command line.
- 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
- 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
- AcquireTokenInteractive
- WAM - the Windows broker
- .NET Core
- Maui Docs
- 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
- High Availability
- Regional
- 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