The Antares team works with clients from a vast array of industries, from public to private entities, ranging from small businesses to large corporate environments. Regardless of the client or project size, one of our consistent priorities is to integrate their current business processes or workflows into a new solution. Leveraging proven processes seems logical, but sometimes technology can get in the way of progress.
Recently, the A-Team was tasked with integrating a custom Authentication System within a new ASPNETCORE Web Api. Leveraging the existing Authentication System, the idea was that the team could focus elsewhere in the application and not have to redesign the application’s authentication components. It was the typical “Why fix something that already works?” scenario. Fortunately, the original Authentication System library was developed with .NET Standard as its target framework. However, when adding the package to the new Web Api project, warnings began to surface and ultimately cause the Web Api’s configuration to error on launch, specifically with error NU1605.
Problem: A project with the NuGet package Microsoft.AspNetCore.All detected a package downgrade
Fix: Reference the package directly from the project to select a different version
After receiving this warning and eventually watching the Kestrel or IIS instance die while launching the new Web Api, it was evident that our tried and true authentication system components would not work out as planned. When reviewing the security solution’s original codebase, it appeared that the Authentication System leverages a NuGet package referencing Microsoft.AspNetCore.Authentication.Cookies 1.1.3, which did not match the new Web Api’s package reference 2.1.1. To overcome the version conflict, we specifically referenced the intended library directly. Following these steps, the A-Team was able to leverage the external reference to the Authentication System without having to modify the codebase:
