Visual Studio 15.4.2 – Package restore failed. Rolling back package changes for ‘Antares.Shared’.
Earlier this week, after opening a pre-2.0.0 netcoreapp project to apply enhancements based on client feedback, one could not miss a glaring new issue: Package restore failed. Timing of essence, this particular solution was updated last week (November 2, 2017) and pushed through our testing process. So what happened since then? An upgrade from Visual Studio 15.4.1 to the current version Visual Studio 15.4.2. As discussed before, Visual Studio receives updates on a more timely basis, seemingly once a week at this point. So since the latest update was applied after the last commit to our Visual Studio Team Services environment, we began to assess the environment locally on our development machines to determine the cause of this issue…
TLDR;
problem: IDE reports errors in the output window concerning that the solution’s project packages (pre-2.0.0 netcoreapp) could not be restored
fix: update all project dependencies to current versions, remove any associated AssemblyInfo files from the projects within the solution, re-apply package info using the properties window for each project, and then perform a rebuild of the solution
The Tell All…
The solution architecture is simple on this particular client application: A single netstandard1.6 library project referenced by a single netcoreapp1.0 web application as shown:
On quick study, the dependencies within each project showed errors and normally this is associated with packages that are not fully compatible with the calling project. So after trying to restore the project’s NuGet packages, and error was produced indicating that a package was not compatible with netstandard1.6. In this case the culprit wasMicrosoft.AspNetCore.Diagnostics.Abstractions version 1.1.2. After reviewing breaking change and release notes for the newer version of this particular package, it seemed to be an easy upgrade with no impact to the client’s application. However, after further study, the target version for this new version would also required a change in the project’s target framework from the current version .NET Standard 1.6 to the more recent .NET Standard 2.0. That is quite a large impact to the client’s application! Not only will the A-Team have to address this standard library project but also any other projects that reference this particular shared library.
The effort was estimated to be a modest hour to upgrade all dependencies and to test basic functionality of the application. Once adequately tested by the developer conducting the upgrade and committing the solution to the VSO build process, regression testing will be requested by the normal Quality Assurance processes implemented in the Antares Application Development process.
After upgrading all dependencies to the now current netstandard2.0 library project and the current netcoreapp2.0 web application, an attempt to rebuild the solution was unsuccessful. Although the original errors were gone, new issues were presented describing duplicate assembly attributes as found within the AssemblyInfo.cs file created by the MSBuild process.
Reviewing the target Assembly Info.cs file, an attempt was made to comment out the attributes and rebuild the project. This produced the same error as described and another thought was presented to delete the AssemblyInfo.cs file thereby removing it from the project. Because the solution was committed last week and our backup processes are based on best practice, removing the file as a work-around seemed like a plausible option.
After right clicking on the AssemblyInfo.cs file and choosing Delete, a solution rebuild was performed without incident. At this point, we reviewed the Package properties for the specific libraries and projects to ensure that the meta-data was correct and modified as necessary. With this work-around, the A-Team was able to then refocus efforts on updating the solution with the requested features and enhancements as requested by our client.
