Matt Ward

NuGet Support in Visual Studio for Mac 7.6

Changes

  • Support no-op package restore on opening a solution
  • Added basic support for the NuGet SDK resolver
  • Fixed source code transformations not available in code completion
  • Fixed incorrect FSharp.Core NuGet package being restored
  • Fixed updating PackageReference removing metadata
  • Fixed build error after updating Xamarin.Forms PackageReference
  • Fixed build error after updating Xamarin.Forms NuGet package
  • Fixed editor errors when .NET Standard assembly referenced in Xamarin.iOS project

More information on all the new features and changes in Visual Studio for Mac 7.6 can be found in the release notes.

Support no-op package restore on opening a solution

On opening a solution a NuGet package restore was always run for projects that use PackageReferences. This resulted in the project.assets.json file being re-generated and the projects being re-evaluated. Now if the package references have not changed a no-op restore will occur. This makes the restore faster on opening a solution. It also prevents Visual Studio for Mac going online to fetch NuGet package information if a wildcard is used for a PackageReference or if the package version cannot be found. In the Package Console when a no-op restore occurs you will see the following messages:

Assets file has not changed. Skipping assets file writing.
No-Op restore. The cache will not be updated.

Allow NuGet SDK resolver to find NuGet SDK packages

Visual Studio for Mac now has basic support for the NuGet SDK resolver. The NuGet SDK resolver will download and install SDKs for SDK style projects if these SDKs are missing.

<Project Sdk="My.Custom.Sdk/2.3.4">
  ...
</Project>

The SDK resolution is done in the background when the project is opened and there is currently no visual indication that this is happening.

The NuGet library assemblies are not available to the remote MSBuild host used by Visual Studio for Mac so the NuGet SDK resolver was previously failing to load. The NuGet SDK resolver supports a MSBUILD_NUGET_PATH environment variable which is now set by Visual Studio for Mac to point to the directory containing the NuGet assemblies that are included with the IDE.

Bug Fixes

Source code transformations not available in code completion

Visual Studio for Mac now ensures that files generated by a NuGet package are available for code completion. One example NuGet package that generates files is the LibLog NuGet package.

The LibLog NuGet package has contentFiles that are processed by MSBuild and converted into .cs files. These .cs files are implicitly included in the project. These files are generated in the obj folder. For example:

obj/Debug/netstandard2.0/NuGet/SomeID/LibLog/5.0.0/ILog.cs

The types defined inside these generated files can be referenced by code in the project. Whilst the project would compile without any errors the text editor would show errors about the types from the generated files being undefined.

These generated files are not created or returned by running the CoreCompileDependsOn MSBuild target, which is currently used to find generated files. Now when the CoreCompileDependsOn target is evaluated, Visual Studio for Mac will also run NuGet specific MSBuild targets to ensure any NuGet package files are generated and made available for code completion.

Fixed incorrect FSharp.Core NuGet package restored

Installing the FSharp.Core 4.5.0 NuGet package into a F# .NET Core console project would result in version 4.3.4 of the FSharp.Core NuGet package being used and displayed in the Dependencies folder. FSharp.Core 4.3.4 is the NuGet package implicitly added by the F# .NET Core SDK. This was being used by the project instead of the PackageReference defined in the project. PackageReferences in the project will now override any implicitly added NuGet packages. This matches the behaviour of dotnet restore when run from the command line.

Fixed updating PackageReference removing metadata

On updating a NuGet PackageReference the old PackageReference was removed from the project file and then a new PackageReference was added. This resulted in custom MSBuild properties associated with the PackageReference being removed from the project file.

<PackageReference Include="NuGet.Versioning" Version="3.6.0">
  <PrivateAssets>all</PrivateAssets>
</PackageReference>

Now on updating a NuGet package the version of the existing PackageReference element is updated so any custom MSBuild properties are not removed.

Fixed build error after updating Xamarin.Forms PackageReference

A build error could occur after updating projects that had a Xamarin.Forms PackageReference. One way to reproduce this was to have a .NET Standard project that used an old Xamarin.Forms version as a PackageReference, and another non .NET Core project, that references the .NET Standard project, which used a newer Xamarin.Forms NuGet package. On building an error would be displayed:

Error XF002: Xamarin.Forms tasks do not match targets

On updating the .NET Standard project to use the same Xamarin.Forms NuGet package version the build error would still occur until the solution was closed and re-opened. Now the remote MSBuild host is shutdown to ensure the correct Xamarin.Forms MSBuild targets and assemblies are used after the NuGet package is updated.

Fixed build error after updating Xamarin.Forms NuGet package

On updating the Xamarin.Forms NuGet package in a solution the build would sometimes fail with errors similar to:

Could not load file or assembly 'Xamarin.Forms.Xaml,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=null' or one of
its dependencies.

Error XF002: Xamarin.Forms tasks do not match targets. Please
ensure that all projects reference the same version of
Xamarin.Forms, and if the error persists, please restart the IDE.

The problem was that the old MSBuild tasks and targets from the originally used Xamarin.Forms NuGet package were still being used. Now when an MSBuild import has changed in a project the remote MSBuild host is shutdown to ensure the correct MSBuild tasks are used.

Fixed editor errors when .NET Standard assembly referenced in Xamarin.iOS project

When a Xamarin.iOS project used an assembly that was compiled for .NET Standard, such as the assembly in the System.Collections.Immutable NuGet package, the netstandard assembly was not made available for code completion. This then resulted in the text editor showing errors even though the project could be compiled succesfully. The errors displayed were similar to:

  The type 'ValueType' is defined in an assembly that is not
  referenced. You must add a reference to assembly 'netstandard,
  Version=2.0.0.0, Culture=neutral, PublicKeytoken=cc7b1dffcd2ddd51'.

Now a check is made to determine if an assembly is referencing netstandard and if so the facade assemblies, which for Xamarin.iOS will include the netstandard.dll, are made available for code completion. Previously only a check was made for the project having an assembly referencing System.Runtime before including the facade assemblies.