Changes

• VSTest Console Runner now included with Visual Studio for Mac
  • Allows xUnit tests to be supported for non .NET Core projects
• Renamed ASP.NET Core Project Templates
• New ASP.NET Core F# Project Templates Added
• Support Backslash in Project Template Primary Output Path
• Support NuGet Restore MSBuild Properties
  • RestoreAdditionalProjectFallbackFolders
  • RestoreAdditionalProjectSources
  • RestoreFallbackFolders
  • RestorePackagesPath
  • RestoreSources
• Fixed transitive project references not supported

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

VSTest Console Runner

Previous versions of Visual Studio for Mac would use dotnet vstest, included with the .NET Core SDK, to run unit tests for .NET Core projects. Now Visual Studio for Mac includes the VSTest Console runner and uses that instead of using the .NET Core SDK.

The standalone VSTest Console runner allows other project types, not just .NET Core projects, to be supported. Visual Studio for Mac can now run xUnit tests for .NET Framework projects. Previously only NUnit was supported.

Let us take a look at using xUnit in a .NET Framework project.

First create a .NET Framework Library project by opening the New Project dialog and selecting Library from the Other – .NET – General category.

Install the following NuGet packages into the project.

• xunit
• xunit.runner.visualstudio

Edit MyClass.cs and add some xUnit tests, as shown below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

using Xunit;

namespace xUnitTests
{
  public class MyClass
  {
      [Fact]
      public void PassingTest()
      {
          Assert.True(true);
      }

      [Fact]
      public void FailingTest()
      {
          Assert.False(true);
      }
  }
}

Building the project should then show the xUnit tests in the Unit Tests window.

Note that, due to a bug in Visual Studio for Mac, the tests may not appear in the Unit Tests window if the xunit.runner.visualstudio was not available in the local machine’s NuGet package cache when it was added to the project. Closing and re-opening the solution should allow the tests to be discovered.

The tests can then be run or debugged in the usual way.

Currently MSTest is not yet supported in .NET Framework projects. The tests are discovered but they fail to run with an access denied error message:

An exception occurred while invoking executor 'executor://mstestadapter/v2': 
Access to the path "/TestResults" is denied.

Renamed ASP.NET Core Project Templates

The ASP.NET Core template names displayed in the New Project dialog have been changed to be more consistent with Visual Studio on Windows.

• ‘ASP.NET Core Web App (Razor Pages)’ renamed to ‘ASP.NET Core Web App’
• ‘ASP.NET Core Web App’ renamed to ‘ASP.NET Core Web App (MVC)’

Visual Studio uses (Model-View-Controller) but the shorter MVC is used by Visual Studio for Mac.

New ASP.NET Core F# Project Templates Added

The following ASP.NET Core F# project templates are now available from the New Project dialog.

• ASP.NET Core Empty
  • .NET Core 1.x and 2.0
• ASP.NET Core Web API
  • .NET Core 2.0 only

Support Backslash in Project Template Primary Output Path

The template.json file used by the new templating engine uses a primaryOutputs property for projects and files. If the paths used contained backslashes then the project was not added to the solution.

1
2
3
4

"primaryOutputs": [
  { "path": "Library1\\Library1.csproj" },
  { "path": "Library2\\Library2.csproj" }
]

Now the paths have the backslashes replaced with forward slashes if the current platform does not support backslash as a path separator.

Support RestoreAdditionalProjectFallbackFolders MSBuild Property

The RestoreAdditionalProjectFallbackFolders MSBuild property is read and appended to the list of fallback folders stored in the project.assets.json file. The .NET Core 2.0 SDK will set this MSBuild property to point to the NuGet package fallback folder that is installed with the SDK. This will be used to resolve NuGet packages first before downloading them to the ~/.nuget/packages folder.

Support RestoreAdditionalProjectSources MSBuild Property

The RestoreAdditionalProjectSources MSBuild property can be used to add additional package sources to the existing list of sources used to resolve packages.

Support RestoreFallbackFolders MSBuild Property

The RestoreFallbackFolders MSBuild property can be used by project that uses PackageReferences to define a set of package fallback folders that will override any specified in the NuGet.Config file. It can also be used to clear any pre-defined fallback folders by specifying ‘clear’ as its value. Note that this value does not affect any folders defined by RestoreAdditionalProjectFallbackFolders which will be appended even if RestoreFallbackFolders is set to ‘clear’.

Support RestorePackagesPath MSBuild Property

The RestorePackagesPath MSBuild property can be used to override the global packages folder location when a project uses a PackageReference.

Support RestoreSources MSBuild property

The RestoreSources MSBuild property can be used to override the sources defined by any NuGet.Config file. Any sources defined in the RestoreAdditionalProjectSources MSBuild property will still be appended to the list of sources if RestoreSources is defined.

Bug Fixes

Fixed Transitive Project References not supported

With three .NET Core projects, LibC referencing LibB referencing LibA, the types defined by LibA were not available to LibC unless it was directly referencing LibA. In Visual Studio for Mac 7.3 the types defined by LibA are available to LibC without LibC directly referencing LibA.

Portable Class Library projects can now be referenced by .NET Core projects

Portable Class Library (PCL) projects could not be referenced by .NET Core projects or .NET Standard projects. The Edit References dialog would show “Incompatible target framework” for the PCL project when trying to add the reference.

Visual Studio for Mac now has the same behaviour as Visual Studio on Windows where a .NET Standard project can reference any PCL project.

Fixed MSBuild Update item not removed from project

If a file was deleted from a project, or removed without deleting, and the file was the last file for a particular wildcard include, the Update item for the file was not being removed from the project.

Fixed MSBuild Remove item not added when Update item exists

With a project that contained a single .cs file, and that file had an Update item defined, when the file was removed from the project, without deleting it, a Remove item was not being added to the project for the file.

Fixed Remove item not being added when file excluded from project

When the last file was removed from the project, but not deleted, an MSBuild Remove item was not added to the project for the file.

1. Create a .NET Standard 2.0 project.
2. Right click Class1.cs and select Remove.
3. Select Remove from Project in the dialog that opens.
4. Close and re-open solution.

The Class1.cs file was still shown in the Solution window when it should have been removed. The project file did not have a Compile remove item for Class1.cs when it should have been added:

<Compile Remove="Class1.cs" />

Deleting a XAML file left an MSBuild Remove item in project file

When a .xaml file in a project was deleted the associated Remove MSBuild item, if it was present, was not being removed from the project file.

1. Create a new .NET Standard 2.0 project.
2. Add Xamarin.Forms 2.3 NuGet package.
3. Add a new Content Page with Xaml file using the New File dialog.
4. In the Solution window select the .xaml file and delete it.

All MSBuild items associated with the .xaml file should have been removed from the project file but instead a None item would remain.

<None Remove="MyPage.xaml" />

Fix MSBuild remove item not added when adding a XAML file

Adding a new .xaml file to a project was not adding a None Remove item for the .xaml file to remove it from the default wildcard include for all files.

<None Remove="MyNewPage.xaml" />

On reloading the solution the Solution window would show two .xaml files – one EmbeddedResource item and one None item.

Fixed MSBuild condition evaluation when using Czech locale

With the primary operating system language set to Czech, creating a new .NET Core project would result in the project having a target framework of net461.

The problem was that Single.TryParse was returing true for an empty string when the machine’s culture was ‘cs-CZ’. This was causing the MSBuild condition evaluation to be treated as a boolean comparison incorrectly in some cases. The condition below would return false even though the property was not defined and both sides of the condition were empty strings:

<PropertyGroup Condition="'$(TargetFrameworkIdentifier)' == ''">

This was causing the TargetFrameworkIdentifier to not be set for .NET Core projects so the default of .NETFramework was being used.

Re-evaluate AppliesTo condition on capability change

Fixed the AppliesTo attribute not attaching a project extension to a project after a NuGet package restore enabled a project capability. The AppliesTo attribute allows a project extension to be associated to a project based on its capabilities.

If the project extension uses an AppliesTo attribute which is initially false and then a new project capability is added, and the project is re-evaluated, the AppliesTo attribute is now re-evaluated. This will then cause the project extension to be attached to the project. If the project extension was attached to the project and the project capability is removed then the project extension will now be removed when the project is re-evaluated.

Fixed being unable to run a new Azure Functions project

Creating a new Azure Functions project would result in being unable to run the project until the solution was closed and re-opened again. After the NuGet packages are restored the project can be run but this information was not updated in Visual Studio for Mac.

Now after a NuGet package restore, when re-evaluating the project, the solution startup item is updated if there is no startup item already defined.

When the project capability is removed, due to a NuGet package being uninstalled, and the project can no longer be run the startup item will be updated if it was previously set to be this project.

Fix generated NuGet files being imported twice

The ProjectName.nuget.g.targets and ProjectName.nuget.g.props, that are generated for .NET Core projects in the base intermediate directory, were being imported twice. Once by Microsoft.Common.props, that is provided with Mono, and once again by Visual Studio for Mac.

Importing these files twice was causing a duplicate file to be added to the project information held in memory by Visual Studio for Mac when Xamarin.Forms 2.4 was used and no .NET Core SDK was installed. This would result in the content page xaml and associated C# file not being nested in the solution window.

Fixed items added to project when a new content page with XAML was created

Adding a new Xamarin.Forms content page with XAML would add an update item for the .xaml.cs file, a remove item for the xaml file, and an include item for the xaml file.

An example is Xamarin.Forms 2.4 which defines wildcard includes:

<None Remove="**\*.xaml" />
<EmbeddedResource Include="**\*.xaml" SubType="Designer" Generator="MSBuild:UpdateDesignTimeXaml" />

Which would cause a new .xaml file added to the project and saved in the project file as well as a remove for the None item even though the .xaml file was already removed from the None items.

<None Remove="MyView.xaml" />

<EmbeddedResource Include="MyView.xaml">
  <Generator>MSBuild:UpdateDesignTimeXaml"</Generator>
</EmbeddedResource>

Fix DependentUpon property being saved in project

Xamarin.Forms 2.4 defines an update item similar to:

<Compile Update="**\*.xaml.cs" DependentUpon="%(Filename)" />

When a project was saved a Compile item was added to the main project with the filename stored in the DependentUpon element. Now the evaluated DependentUpon value is treated as being the default value so it is not added to the project file.

Fix xaml.cs files not being nested

Xamarin.Forms 2.4 defines an update item similar to:

<Compile Update="**\*.xaml.cs" DependentUpon="%(Filename)" />

The DependentUpon property was being evaluated as ‘*.xaml.cs’. This was causing .xaml.cs files to not be nested in the Solution window.

Fixed build error when Xamarin.Forms 2.4 used in a .NET Standard project

If a Xamarin.Forms .NET Standard project had a .xaml file and a .xaml.cs file then the xaml.g.cs file would not be generated when the project file contained no files. The default items defined by the Xamarin.Forms NuGet package were not being imported. This then caused a build error about the InitializeComponent method not being defined.

Xamarin.Forms 2.4.0 uses default item imports which were not being included since they are conditionally imported and the MSBuildSDKsPath was not defined:

<Import Project="$(MSBuildThisFileDirectory)Xamarin.Forms.DefaultItems.props" Condition="'$(MSBuildSDKsPath)'!=''" />

MSBuild on the command line defines the MSBuildSDKsPath globally in its MSBuild.dll.config file. The MSBuild engine host, used when building a project in Visual Studio for Mac, now also defines the MSBuildSDKsPath property.

Fixed remove item added when removing a linked file

Deleting a file link in a .NET Core project would add a remove item for the file instead of removing the link from the project.

Changes

• Support installing System.ValueTuple NuGet Package from Quick Fixes
• NuGetizer 3000 – Update NuGet.Build.Packaging to version 0.2
• Support NuGet Restore MSBuild Properties
  • RestoreAdditionalProjectFallbackFolders
  • RestoreAdditionalProjectSources
  • RestoreFallbackFolders
  • RestorePackagesPath
  • RestoreSources
• Fixed transitive dependencies not available when using project.json

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

Quick Fix – Install System.ValueTuple NuGet Package

C# 7.0 introduced tuple types that may require the System.ValueTuple NuGet package to be added to the project. Visual Studio for Mac now offers to install the System.ValueTuple NuGet package if the project requires this NuGet package.

Creating a .NET Framework 4.6 project with the following code:

1
2
3
4

public (string, int) GetValues(string id)
{
  return ("Name", 25);
}

You will see error markers in the text editor. If you hover over one of these error markers you will see a Predefined type ‘System.ValueTuple`2’ is not defined or imported message.

If you right click the error marker there is now a new Install Package ‘System.ValueTuple’ Quick Fix action available.

From this menu you can install the latest System.ValueTuple NuGet package or open the Add Packages dialog to search for a specific version of the System.ValueTuple NuGet package.

Note that if the project is targeting .NET Framework 4.7 or .NET Standard 2.0 then the System.ValueTuple NuGet package is not required.

Also note that the official nuget.org package source needs to be available for this feature to work.

NuGetizer 3000 – Updated NuGet.Build.Packaging to version 0.2

The version of the NuGet.Build.Packaging NuGet package used by default for NuGetizer 3000 support has been updated from 0.1.276 to 0.2.0. This fixes a potential build error when building with Mono 5.6.

1
2
3
4
5
6
7

Using "ReportAssetsLogMessages" task from assembly "/usr/local/share/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/build/../tools/net46/Microsoft.NET.Build.Tasks.dll".
Task "ReportAssetsLogMessages"
/usr/local/share/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/build/Microsoft.PackageDependencyResolution.targets(323,5): error MSB4018: The "ReportAssetsLogMessages" task failed unexpectedly. [RefactoringEssentials/RefactoringEssentials.2017/RefactoringEssentials.csproj]
/usr/local/share/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/build/Microsoft.PackageDependencyResolution.targets(323,5): error MSB4018: System.TypeLoadException: Could not resolve type with token 0100005b (from typeref, class/assembly NuGet.ProjectModel.IAssetsLogMessage, NuGet.ProjectModel, Version=4.3.0.5, Culture=neutral, PublicKeyToken=31bf3856ad364e35) [RefactoringEssentials/RefactoringEssentials.2017/RefactoringEssentials.csproj]
/usr/local/share/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/build/Microsoft.PackageDependencyResolution.targets(323,5): error MSB4018: at Microsoft.NET.Build.Tasks.TaskBase.Execute () [0x00000] in <01420900fd004c128de2d2ee31bad624>:0 [RefactoringEssentials/RefactoringEssentials.2017/RefactoringEssentials.csproj]
/usr/local/share/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/build/Microsoft.PackageDependencyResolution.targets(323,5): error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute () [0x00023] in <765502eb2f884ce79731edeb4b0517fb>:0 [RefactoringEssentials/RefactoringEssentials.2017/RefactoringEssentials.csproj]
/usr/local/share/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/build/Microsoft.PackageDependencyResolution.targets(323,5): error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder+d__26.MoveNext () [0x0022d] in <765502eb2f884ce79731edeb4b0517fb>:0 [RefactoringEssentials/RefactoringEssentials.2017/RefactoringEssentials.csproj]

The ReadLegacyDependencies target from NuGet.Build.Packaging.Tasks is called when PackOnBuild is set to true.

The NuGet.Build.Packaging.Tasks assembly was loading an embedded NuGet.ProjectModel assembly that conflicts with the version that is used by Microsoft.NET.Build.Tasks.

Support RestoreAdditionalProjectFallbackFolders MSBuild Property

The RestoreAdditionalProjectFallbackFolders MSBuild property is read and appended to the list of fallback folders stored in the project.assets.json file. The .NET Core 2.0 SDK will set this MSBuild property to point to the NuGet package fallback folder that is installed with the SDK. This will be used to resolve NuGet packages first before downloading them to the ~/.nuget/packages folder.

Support RestoreAdditionalProjectSources MSBuild Property

The RestoreAdditionalProjectSources MSBuild property can be used to add additional package sources to the existing list of sources used to resolve packages.

Support RestoreFallbackFolders MSBuild Property

The RestoreFallbackFolders MSBuild property can be used by project that uses PackageReferences to define a set of package fallback folders that will override any specified in the NuGet.Config file. It can also be used to clear any pre-defined fallback folders by specifying ‘clear’ as its value. Note that this value does not affect any folders defined by RestoreAdditionalProjectFallbackFolders which will be appended even if RestoreFallbackFolders is set to ‘clear’.

Support RestorePackagesPath MSBuild Property

The RestorePackagesPath MSBuild property can be used to override the global packages folder location when a project uses a PackageReference.

Support RestoreSources MSBuild property

The RestoreSources MSBuild property can be used to override the sources defined by any NuGet.Config file. Any sources defined in the RestoreAdditionalProjectSources MSBuild property will still be appended to the list of sources if RestoreSources is defined.

Bug Fixes

Transitive dependencies not available when using project.json

With two projects A and B that both use project.json files, project B referencing project A, the NuGet package dependencies used by project A were not available to project B transitively. This was because the project reference information was not being used when a restore occurred. This caused the assemblies from the transitively referenced NuGet packages to not be added to the project.lock.json file for Project B.

Unable to debug a new Azure Functions project without re-opening project

After creating a new Azure Functions project it was possible to build the project but not to debug it or run it. On closing and re-opening the solution it would be possible to debug and run the Azure Functions project.

When Visual Studio for Mac created a new Azure Functions project it initially determined that it could not run or debug the project. After the Azure Functions project has its PackageReferences restored it gains an AzureFunctions project capability. This capability is used to determine if the project can be run. This change in the capability was not handled by Visual Studio for Mac so it did not allow the project to be run until the project was closed and re-opened.

Now, after the NuGet package restore is finished, the project is re-evaluated and a check is made to see if the project can now be run.

Fix generated NuGet files being imported twice

The generated ProjectName.nuget.g.targets and ProjectName.nuget.g.props that are created for .NET Core projects in the base intermediate directory were being imported twice when evaluating the project. Once by Microsoft.Common.props, provided with Mono, and once by Visual Studio for Mac.

This duplicate import was resulting in a duplicate file being added to the project held in memory by Visual Studio for Mac when the Xamarin.Forms 2.4 NuGet package was used in a .NET Standard project and no .NET Core SDK is installed. This would result in the content page xaml and associated C# file not being nested in the solution window.

The Template Creator extension provides a way to create a project template from an existing project or solution open in Visual Studio for Mac and have the project template available in the New Project dialog straight away.

The Template Creator uses the .NET Core templating engine to create the projects from the project templates.

Let us take a look in more detail at what the Template Creator extension provides in Visual Studio for Mac.

Features

• Create a project template from an existing solution or project
• Create custom top level project template categories

Supports

• Visual Studio Mac 7.0 or later.

Creating a new Project Template

To create a new project template for a project opened in Visual Studio for Mac, right click the project and select Create Template.

A Template Information dialog is then opened.

The information in the dialog is used to populate the generated template.json file. Further details on what the template.json file holds is available in the reference for template.json.

• Author
  • Author of the project template.
• Display Name
  • This is the template name displayed in the New Project dialog.
• Description
  • This is the description displayed in the New Project dialog.
• Category
  • This is the category in the New Project dialog used by the template.
• Short Name
  • This is the short name for the template that can be used from the .NET Core command line.
• Default Project Name
  • This is the default project name that will be used with the .NET Core command line.
• Identity
  • This is the unique id for the template. This should be unique across all custom project templates.
• Group Identity
  • This is typically a substring of the template’s Identity.

By default the project template will use the Other – .NET – General category in the New Project dialog. To change the category click the browse button next to the category text box to open the Template Categories dialog.

Select the required category and click OK. The selected category will then be updated in the Template Information dialog.

Click OK to generate the template.json file. The template.json file will be opened in the text editor. It will also be displayed in the Solution window in the .template.config folder.

The project template is now available in the New Project dialog.

Updating a Project Template

After the project template is created you can modify the original project and its template.json file as required.

Changes made to the project are available in the New Project dialog immediately.

Changes made to the template.json file are available immediately in the same instance of Visual Studio for Mac where the template.json file is being edited.

Multiple Projects in a Template

A project template may create more than one project. To create a project template for all projects in the solution right click the solution and select Create Template.

A template.json file will be created in a .template.config directory inside the solution’s directory.

Note that in order for the new projects created to use the name specified in the New Project dialog they should all have a common start to their name. The template.json file’s sourceName will be the part that is replaced with the name of the project specified in the New Project dialog.

Configuring Registered Project Templates

The .NET Core templating engine supports project templates in NuGet packages or project templates that unpackaged in a directory. The Template Creator extension does not package the project templates into a NuGet package and instead stores a set of directories that are scanned by the .NET Core templating engine for templates. The set of directories that are registered can be viewed and updated in the Preferences dialog from the Templates – Custom Folders section.

The templating engine will scan the configured directories and look for all the template.json files which define the project templates. The project templates found are then made available to the Visual Studio for Mac’s New Project dialog by the Template Creator extension.

When the template.json file is created using the information in the Template Information dialog the Template Creator extenxion also registers the project’s directory so it will be scanned by the templating engine.

To remove a project template from the New Project dialog you can either delete the template.json file or remove the folder from the Custom Folders defined in the Preferences dialog.

If you have an existing set of project templates that use template.json files and are not in a NuGet package then you can register a single parent directory in the Preferences dialog.

Custom Categories

Custom top level categories can be defined for your project templates by adding them in Preferences – Templates – Custom Categories.

The Add Top Level Category button will add a new top level category and two child category levels. The New Project dialog requires three category levels. The ids used should ensure that the full path to the template’s category is unique. For example, with a custom category custom/net/general there should not be another top level custom category id, but the second and third level category ids can be re-used in another top level category, such as top/net/general.

The Add Category button will add a single child category to the currently selected category whilst the Remove button will remove the selected category.

Note that changes to the categories require Visual Studio for Mac to be restarted before they are visible in the New Project dialog.

Also note that it is not currently possible to extend existing project template categories using the Template Creator extension.

Diagnosing Template Problems

If the template does not appear in the New Project dialog or fails to be created then you may be able to diagnose the problem by opening the Templating Log window. This is available from the View – Pads menu.

This window will show messages returned from the .NET Core templating engine and any errors reported by the Template Creator extension.

Installation

The Template Creator extension is available to download from GitHub.

To install the extension open the Extensions Manager by selecting Extensions… from the main menu. Click the Install from file button. Select the .mpack file and then click the Open button.

The extension is also available in the Extensions Manager from the Visual Studio Extension Repository (Beta channel).

Source Code

• Template Creator extension for Visual Studio for Mac and MonoDevelop

Further Reading

• How to create your own templates for dotnet new
• Reference for template.json
• Creating Visual Studio project and solution templates – Part 3, VS for Mac extension
• SideWaffle v2 for Visual Studio

Changes

• Support NuGet package fallback folders
• Support AssetTargetFallback
• Xamarin.Forms 2.4 support (VS for Mac 7.2.2)
• Fixed transitive types from references not being available

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

NuGet package fallback folders support

The .NET Core SDK 2.0 defines a NuGet package fallback folder /usr/local/share/dotnet/sdk/NuGetFallbackFolder that can be used when looking for NuGet packages whilst restoring. This fallback folder is now supported by Visual Studio for Mac 7.2 so that on restoring a .NET Core 2.0 project the NuGet packages from the fallback folder will be found and do not need to be downloaded from nuget.org into the local machine NuGet package cache ~/.nuget/packages. This should speed up NuGet package restore for .NET Core 2.0 and .NET Standard 2.0 projects the first time it occurs.

As well as the NuGet fallback folders Visual Studio for Mac will now add the following items to the generated project.assets.json if they are available:

• configFilePaths
• sources
• warningProperties

AssetTargetFallback support

The .NET Core 2.0 SDK uses an AssetTargetFallback MSBuild property defined in an imported SDK MSBuild files. This is used instead of the PackageTargetFallback property when determining if a NuGet package is compatible. Currently the AssetTargetFallback property is set to net461 by the .NET Core 2.0 SDK which allows .NET Core projects to use NuGet packages that include assemblies that target the full .NET Framework. The supported fallback frameworks are now added to the generated project.assets.json file by Visual Studio for Mac when a .NET Core 2.0 project is restored.

NuGet package restore now fails if package and asset target fallbacks are defined by a project

If both AssetTargetFallback and PackageTargetFallback are defined by a project then the NuGet restore will fail with an error indicating that they cannot be used together. This mirrors the behaviour of the .NET Core command line restore.

Mark implicit PackageReferences as auto referenced

PackageReference items that have IsImplicitlyDefined set to true in their metadata now have autoRefererenced set to true in the project.assets.json file.

Support parsing MSBuild conditions with unquoted properties

The .NET Core 2.0 SDK uses conditions that pass properties to the Exists function without using single quotes around the MSBuild property. This is now supported by Visual Studio for Mac.

<PropertyGroup Condition="Exists($(FileName))">

Xamarin.Forms 2.4 support

The following sections cover bug fixes made in Visual Studio for Mac 7.2.2 to improve support for Xamarin.Forms 2.4 and later versions. Xamarin.Forms 2.4 includes .NET Standard support as well as defining default MSBuild items for .NET Core and .NET Standard projects. These default MSBuild items were not handled by Visual Studio for Mac 7.2.0 and earlier versions. The main symptoms of Visual Studio for Mac not supporting Xamarin.Forms 2.4 were:

• Duplicate .xaml files in the Solution window.
• Nesting of .xaml and .xaml.cs files not working in Solution window.
• MSBuild items incorrectly added to SDK style projects.

Generated NuGet files being imported twice

The generated NuGet files, .nuget.g.targets and .nuget.g.props, that are created for .NET Core projects were being imported twice. Once by Microsoft.Common.props, that is provided with Mono, and once by Visual Studio for Mac.

This double import was causing a duplicate file to be added to the project when Xamarin.Forms 2.4 was used in a .NET Standard project and the .NET Core SDK was not installed. This would result in the .xaml file and associated .xaml.cs file not being nested in the solution window.

MSBuild items added when new xaml file added to project

Adding a new Xamarin.Forms content page with XAML would incorrectly add an update item to the project for the .xaml.cs file when an SDK style project was used.

When a new .xaml file was added to an SDK style project a None item as well as an EmbeddedResource item would incorrectly be added to the project file.

1
2
3
4
5

<None Remove="MyView.xaml" />

<EmbeddedResource Include="MyView.xaml">
  <Generator>MSBuild:UpdateDesignTimeXaml"</Generator>
</EmbeddedResource>

Compile item added with DependentUpon metadata

Xamarin.Forms 2.4 defines a wildcard update similar to:

<Compile Update="**\*.xaml.cs" DependentUpon="%(Filename)" />

When a project was saved in Visual Studio for Mac a Compile item was incorrectly added to the main project with the evaluated value stored in the DependentUpon element.

DependentUpon being evaluated incorrectly

Metadata defined for wildcard MSBuild items were being evaluated using the wildcard item instead of the expanded item. This was causing .xaml.cs files to not be nested in the Solution window for Xamarin.Forms 2.4.

Xamarin.Forms 2.4 defines an update item similar to:

<Compile Update="**\*.xaml.cs" DependentUpon="%(Filename)" />

The DependentUpon property was evaluated using the wildcard item which resulted in the DependentUpon property being evaluated as ‘*.xaml.cs’ instead of the filename of the item that was updated by the wildcard.

Define MSBuildSDKsPath for MSBuild engine host

MSBuild when run on the command line defines the MSBuildSDKsPath in its MSBuild.dll.config file. The MSBuild engine host that is used when building with Visual Studio for Mac now also defines the MSBuildSDKsPath property. Previously this was not being defined.

This fixes a build error when using Xamarin.Forms 2.4.0 in an SDK style project that targets .NET Standard. Xamarin.Forms 2.4.0 uses default item imports which were not being included since they are conditionally imported based on the MSBuildSDKsPath property value:

<Import Project="$(MSBuildThisFileDirectory)Xamarin.Forms.DefaultItems.props" 
    Condition="'$(MSBuildSDKsPath)'!=''" />

If the SDK style project had a .xaml file and a .xaml.cs file then the .xaml.g.cs file was not being generated when the project had no files explicitly defined in the project file. This then caused a build error about the InitializeComponent method not being defined.

Bug Fixes

Fixed transitive assembly references not available until restart

Given a solution that contains three .NET Standard projects: LibC references LibB which references LibA. If the Newtonsoft.Json NuGet package was installed into LibA the types from this NuGet package were not available in LibB or LibC until the solution was closed and re-opened again. Closing and re-opening the solution refreshes the reference information used by the type system. Now when a NuGet package is installed into a .NET Core project the projects that reference this project have their reference information refreshed. Types from the installed NuGet packages are then available in projects that reference this updated project either directly or indirectly.

Fixed transitive project references after editing a project file

Given a solution that contains three .NET Standard projects: LibC references LibB which references LibA. If a NuGet package is added to LibA by editing its project file in the text editor the types from this NuGet package were not available to LibB or LibC without restarting Visual Studio for Mac or until the packages were restored for the solution. Now when the project file is saved the projects that directly or indirectly reference the project will be restored.

Ignore project references with ReferenceOutputAssembly set to false when restoring

Project references that have ReferenceOutputAssembly are now not added to the project.assets.json file. This was causing the NuGet package restore to fail in some cases. For example, if a .NET Standard project has a project reference to a .NET Core App project, but has the ReferenceOutputAssembly set to false, then running dotnet restore from the command line would work, but the restore would fail in Visual Studio for Mac.

Changes

• NuGet 4.3.1 support
• NuGet fallback folders support
• AssetTargetFallback support
• NuGet operations can be cancelled on closing the solution
• Fixed transitive types from references not being available
• Fixed credential dialog being shown multiple times on opening a solution

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

NuGet 4.3.1 support

NuGet 4.3.1.4445 is now included with Visual Studio for Mac 7.2.

NuGet 4.3.1 includes a fix for imports in the project.json file being ignored which could cause a NuGet package to incorrectly be considered incompatible when restoring NuGet packages.

NuGet package fallback folders support

The .NET Core SDK 2.0 defines a NuGet package fallback folder /usr/local/share/dotnet/sdk/NuGetFallbackFolder that can be used when looking for NuGet packages whilst restoring. This fallback folder is now supported by Visual Studio for Mac 7.2 so that on restoring a .NET Core 2.0 project the NuGet packages from the fallback folder will be found and do not need to be downloaded from nuget.org into the local machine NuGet package cache ~/.nuget/packages. This should speed up NuGet package restore for .NET Core 2.0 and .NET Standard 2.0 projects the first time it occurs.

As well as the NuGet fallback folders Visual Studio for Mac will now add the following items to the generated project.assets.json if they are available:

• configFilePaths
• sources
• warningProperties

AssetTargetFallback support

The .NET Core 2.0 SDK uses an AssetTargetFallback MSBuild property defined in an imported SDK MSBuild files. This is used instead of the PackageTargetFallback property when determining if a NuGet package is compatible. Currently the AssetTargetFallback property is set to net461 by the .NET Core 2.0 SDK which allows .NET Core projects to use NuGet packages that include assemblies that target the full .NET Framework. The supported fallback frameworks are now added to the generated project.assets.json file by Visual Studio for Mac when a .NET Core 2.0 project is restored.

NuGet operations can be cancelled on the closing the solution

Previously when closing the solution, or closing Visual Studio for Mac, when a NuGet package operation was still running would result in a dialog being displayed saying that the solution cannot be closed until the NuGet operation was completed. NuGet v3 and above now allow the NuGet operations to be cancelled so now the dialog allows the current operation to be cancelled. If the operation is taking a while to cancel a busy spinner image will be displayed in the dialog.

If a restore is being run when the solution will be closed the restore will be cancelled automatically without showing the dialog.

NuGet package restore now fails if package and asset target fallbacks are defined by a project

If both AssetTargetFallback and PackageTargetFallback are defined by a project then the NuGet restore will fail with an error indicating that they cannot be used together. This mirrors the behaviour of the .NET Core command line restore.

Support imported package references in non .NET Core projects

If a non .NET Core project had no PackageReference items but imported a file that did have PackageReference items the NuGet packages were not restored on opening the solution. This was because only the PackageReference items defined directly in the project were checked to determine if the project used NuGet packages. Now the evaluated MSBuild items are checked so any imported PackageReference items are detected and a restore will be run on opening the solution.

Note that imported PackageReference items are not displayed in the Packages folder.

Package Console is no longer opened when a NuGet operation is cancelled

When a NuGet operation is cancelled from the main status bar the Package Console is now not opened when the NuGet operation fails due to the cancellation. If the NuGet operation is not cancelled then the Package Console window will still be opened as before if the operation fails. This is also a workaround for Visual Studio for Mac closing the currently displayed dialog when the Package Console window opens after the NuGet operation is cancelled when closing the solution.

Whitespace is now trimmed when creating a new package source

When creating a new package source copying and pasting NuGet package source url can sometimes copy extra whitespace which can then result in NuGet package restore errors such as:

Failed to verify the root directory of local source
' https://api.nuget.org/v3/index.json'.

The package source name and url will now have whitespace trimmed to avoid this copy and paste problem. This also matches Visual Studio on Windows behaviour.

Mark implicit PackageReferences as auto referenced

PackageReference items that have IsImplicitlyDefined set to true in their metadata now have autoRefererenced set to true in the project.assets.json file.

Bug Fixes

Fixed transitive assembly references not available until restart

Given a solution that contains three .NET Standard projects: LibC references LibB which references LibA. If the Newtonsoft.Json NuGet package was installed into LibA the types from this NuGet package were not available in LibB or LibC until the solution was closed and re-opened again. Closing and re-opening the solution refreshes the reference information used by the type system. Now when a NuGet package is installed into a .NET Core project the projects that reference this project have their reference information refreshed. Types from the installed NuGet packages are then available in projects that reference this updated project either directly or indirectly.

Fixed transitive project references after editing a project file

Given a solution that contains three .NET Standard projects: LibC references LibB which references LibA. If a NuGet package is added to LibA by editing its project file in the text editor the types from this NuGet package were not available to LibB or LibC without restarting Visual Studio for Mac or until the packages were restored for the solution. Now when the project file is saved the projects that directly or indirectly reference the project will be restored.

Fixed credential dialog shown multiple times on opening a solution

With check for updates enabled, multiple projects in the solution, and a package source that was missing or had invalid credentials, on opening the solution the credential dialog would be displayed multiple times even if the correct username and password was entered or the dialog was cancelled. The dialog was being displayed for each project and the credential information was not being re-used.

Now the NuGet source repositories are re-used when checking for updates and also when restoring the projects when the solution is first opened. Any valid credentials entered will be re-used when checking the remaining projects. If the credential dialog is cancelled then the dialog is no longer displayed again whilst checking for updates for the other projects.

Fixed credential dialog displayed when credentials are available

With valid credentials stored in the Mac key chain the credential dialog would still be displayed when it should not have been. The problem was that the NuGet credential service puts itself in a retry mode if any of the credential providers are used when trying to authenticate against a package source. Once in this retry mode the Visual Studio for Mac credential provider would always show a dialog asking for the credentials instead of re-using the existing credentials. To avoid this the credential service is reset before any user actions, such as opening the Add Packages dialog, running a restore or an update.

Fixed crash when displaying Chinese characters in the Add Packages dialog

With the NuGet v3 package source https://api.nuget.org/v3/index.json selected, searching for Microsoft.AspNet.WebApi.Client would result in the Visual Studio for Mac terminating when an attempt was made to display the results in the Add Packages dialog. The crash was in the Pango library when it attempted to determine the size of the package title displayed in the search results. If the package title contained Chinese characters then Pango would throw an exception:

Illegal byte sequence encounted in the input.
at (wrapper managed-to-native) Pango.Layout:pango_layout_get_pixel_size (intptr,int&,int&)

Then when Visual Studio for Mac tried to use Pango again to determine the size of the text this would result in Visual Studio for Mac terminating.

1
2
3
4
5
6

Pango-WARNING (recursed) **: shaping failure, expect ugly output.
shape-engine='BasicEngineCoreText', font='.SF NS Text',
text='∫ê'Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) Pango.Layout.pango_layout_get_pixel_size (intptr,int&,int&) [0x0000b] in <c7aa2d93df4045df8dc71d5439f99d72>:0

If the NuGet v2 package source was used then this crash did not occur since the package title was not returned in the search results and the package id would be displayed instead which does not contain Chinese characters.

As a workaround the Add Packages dialog now displays the package id instead of the package title.

Ignore project references with ReferenceOutputAssembly set to false when restoring

Project references that have ReferenceOutputAssembly are now not added to the project.assets.json file. This was causing the NuGet package restore to fail in some cases. For example, if a .NET Standard project has a project reference to a .NET Core App project, but has the ReferenceOutputAssembly set to false, then running dotnet restore from the command line would work, but the restore would fail in Visual Studio for Mac.

New Features

• NuGet 4.3 support
• Support PackageReference in non .NET Core projects
• Enable file template when a NuGet package is installed

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

NuGet 4.3 Support

NuGet 4.3.0.2418 is now included with Visual Studio for Mac 7.1.

This version of NuGet adds support for .NET Core 2.0 and .NET Standard 2.0 target frameworks.

Support PackageReference in non .NET Core projects

Non .NET Core Sdk style projects that use a PackageReference MSBuild item are now supported.

<PackageReference Include="Newtonsoft.Json">
  <Version>10.0.1</Version>
</PackageReference>

In Visual Studio for Mac 7.0 the Solution window would not show any packages for the project, would not allow the packages to be restored, and would create a packages.config file when installing a NuGet package even though the project was using PackageReferences.

Now if the project has a PackageReference the Packages folder shows the installed packages and can be used to update or install NuGet packages which will also create PackageReference MSBuild items.

If the project has no PackageReferences then by default a packages.config file will be created when a NuGet package is installed.

Currently it is not possible to opt-in to using PackageReferences by default. So the project file will need to be edited in the text editor to include at least one PackageReference before the default behaviour of using a packages.config file is overridden.

Enable file template when a NuGet package is installed

A file template can now specify that it should be enabled if the project has a specific reference or has a specific NuGet package installed. Previously it was only possible to enable a file template based on the references defined in the project file.

<HasPackageOrReference PackageId="Xamarin.Forms" Assembly="Xamarin.Forms" />

Whilst a reference will work for projects that use a packages.config file, if the project uses a project.json file or PackageReferences then checking the references defined in the project would not find any matches and the file template would not be enabled.

Bug Fixes

Do not require description when creating a new NuGet package project

When creating a NuGet package project or a multiplatform project the description needed to be specified in the New Project dialog.

To simplify the project creation process the package id is used as the description by default. As you type the package id into the New Project dialog the description text box will be updated. The description can be changed to be different to the package id if required.

Fix being unable to load NuGet Package Project created by Visual Studio on Windows

Visual Studio on Windows creates a NuGet package project (.nuproj) with no target framework version which resulted in 4.0 being used by default in Visual Studio for Mac. This would cause the project to fail to load in Visual Studio for Mac since it was checking for 4.5 or later.

Fix no packages shown in Packages folder for NuGet Package Projects

Opening a previously created NuGet package project (.nuproj) would show no packages in the Packages folder.

The problem was that the PackageReference project item was defined by both the NuGet addin and the Packaging addin. The NuGet addin’s PackageReference project item was used instead of the one defined by the Packaging addin so no package references were found for the NuGet package project.

Fix NuGet Package Project’s MSBuild targets not being created

If the NuGet package project’s generated .nuget.targets or .nuget.props are missing then these are now created on opening the solution if automatic restore is enabled.

Fix being unable to package .NET Standard projects

A NuGet package project that referenced an Sdk style .NET Standard project would fail to build the NuGet package. The build would fail with an error:

Error: Project targets '.NETStandard,Version=v1.4'. It cannot be
referenced by a project that targets 'NuGet,Version=v1.0'

Updating to a more recent NuGet.Build.Packaging NuGet package, such as version 0.1.276, fixes this problem.

NuGet Package project treated as .NET Core project

NuGet package projects (.nuproj) that use the NuGet.Build.Packaging 0.1.276 NuGet package define a TargetFramework property in an imported MSBuild .props file. This was causing the project to be treated as a .NET Core project by Visual Studio for Mac. This caused the Dependencies folder to be displayed and the References folder to be removed. Visual Studio for Mac now checks the project has the Sdk attribute instead of looking at the MSBuild properties defined by the project when determining the project type.

New Features

• .NET Core 2.0 support
• Target framework selection for new projects
• New project templates
• .NET Core Runtimes and SDKs displayed in About Dialog
• Improved support for multi target framework projects

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

.NET Core 2.0 Support

Visual Studio for Mac 7.1 adds support for .NET Core 2.0 and .NET Standard 2.0.

The .NET Core 2.0 SDK needs to be installed separately.

Target Framework Selection for New Projects

If a project template supports multiple target frameworks, and the corresponding framework is available, then the New Project dialog will allow the framework to be selected before the project is created.

Visual Studio for Mac includes project templates for .NET Core 1.0, 1.1 and 2.0 as well as for .NET Standard versions 1.0 through to 2.0.

To be able to create projects that target .NET Core 2.0 or .NET Standard 2.0 the .NET Core 2.0 SDK needs to be installed.

New Project Templates

The following project templates have been added:

• ASP.NET Core Web App (Razor Pages)
  • Available if .NET Core 2.0 SDK is installed.
• Class Library
  • Targets .NET Core instead of .NET Standard.
• MSTest

Some project templates do not support all the target framework versions. For example, the ASP.NET Core Web App (Razor Pages) only supports .NET Core 2.0, so this template will only be displayed if .NET Core 2.0 SDK is installed.

The F# project templates have some restrictions on what target frameworks they support. The F# .NET Standard project templates do not support selecting .NET Standard versions below 1.6. The F# Class Library project only supports .NET Core 2.0.

.NET Core Runtime and SDKs displayed in About Dialog

The About dialog will now display the .NET Core runtimes and SDKs that are installed on the local machine.

Improved Support for Multi Target Framework Projects

SDK style projects that target multiple frameworks can now be opened in Visual Studio for Mac 7.1 and will show source files as well as NuGet package dependencies.

The project will be treated as though it only has one target framework which is the first one specified in the TargetFrameworks property in the project file.

Please note that currently the support for multiple target frameworks is limited in comparison with Visual Studio on Windows.

Bug Fixes

ASP.NET Core Web API project does not open API url on launching browser

When an ASP.NET Core Web API project was run it would open a blank web page in the browser instead of a page that showed the api values. Now when a new ASP.NET Core Web API project is run the http://localhost:<port>/api/values url is launched in the browser so the API values will be displayed.

Unable to run or debug ASP.NET Core project with empty SDK directory

If there was an empty directory inside the .NET Core SDK directory /usr/local/share/dotnet/sdk then it was not possible to run or debug an ASP.NET Core web project

If the .NET Core SDK MSBuild files were not found in the SDK directory then the project’s OutputType was not read and would result in the project being treated as a library project. This could also occur if only the .NET Core runtime is installed.

Shared project files shown for .NET Core project in Solution window

When a .NET Core project referenced a shared assets project the files from the shared project were incorrectly being displayed in the .NET Core project in the Solution window.

Fix generated code for resource files in .NET Core projects

Adding a resx file to a .NET Core 1.x or .NET Standard 1.x project would result in code being generated that could not be compiled.

Projects that target .NET Core App 1.0, 1.1, or .NET Standard below version 2.0 cannot compile code that uses typeof(Resources).Assembly which was being generated by the ResXFileCodeGenerator. If these target frameworks are used by the project then the code generated by Visual Studio for Mac will now use typeof(Resources).GetTypeInfo().Assembly which is supported.

.NET Core 2.0 and .NET Standard 2.0 do not need to use GetTypeInfo so the code generated for these frameworks has not been changed.

Fix new resource file not added as Update item in Sdk projects

Adding a new resource file to a .NET Core project would add the .resx file and the .Designer.cs file as Include items instead of an Update items.

<ItemGroup>
  <EmbeddedResource Include="Resources.resx">
    <Generator>ResXFileCodeGenerator</Generator>
    <LastGenOutput>Resources.Designer.cs</LastGenOutput>
  </EmbeddedResource>
</ItemGroup>
<ItemGroup>
  <Compile Include="Resources.Designer.cs">
    <DependentUpon>Resources.resx</DependentUpon>
  </Compile>
</ItemGroup>

This then caused the build to fail since these files are already included by the .NET Core SDK.

Visual Studio on Windows can be configured to use a different editor to open a file. With Visual Studio for Mac, whilst you can open a file with a selection of editors and applications, it is not currently possible to change the default editor or add a custom application.

The Open With addin provides an Open With dialog that allows you to change the default editor or application used to open a file in a similar way to how this is done in Visual Studio on Windows.

Features

• Supports changing the default editor used to open a file.
• Supports adding a custom application to open a file.
• Editor configuration is saved and will be available on restarting Visual Studio for Mac.

Supports

• Visual Studio Mac 7.0 or later.

Configuring the Default Editor or Application

To configure the application or editor used to open file you can right click the file in the Solution window and select Open With – Preferences…

This will open the Open With dialog.

The editors and applications that support opening the file are displayed. The default application is indicated by having (Default) next to its name.

To change the default application or editor used to open the file select it and then click the Set as Default button. Click OK to close the dialog and save the configuration.

If a file is currently open then it will need to be closed before it is opened in the new default editor or application.

Adding a Custom Application

A custom application can be added to the list of applications shown in the Open With menu. First open the Open With dialog by selecting Open With – Preferences. Then click the Add button to open the Add Application dialog.

The Browse button can be used to find an application.

The Friendly Name is the name that will be displayed in the Open With menu for the custom application.

Arguments cannot be specified if a Mac application (.app) is used. However if the application is not a Mac application, for example, it is a C# program, then arguments can be passed. To pass the filename to the program you can use {0} in the Arguments text box. This placeholder will be expanded to be the full filename path when the program is run.

Removing a Custom Application

To remove a custom application for a file first open the Open With dialog by selecting Open With – Preferences. Select the application you want to remove. Then click the Remove button.

The Remove button is only enabled for custom applications that you have added. The built-in editors and applications cannot be removed.

Installation

The Open With addin is available to download from GitHub.

To install the addin open the Extensions Manager by selecting Extensions… from the main menu. Click the Install from file button. Select the .mpack file and then click the Open button.

The addin is also in the Extensions Manager from the Visual Studio Extension Repository (Beta channel).

Source Code

• Open With addin for Visual Studio for Mac

New Features

• .NET Core support
• NuGet 4.0 support

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

.NET Core Support

.NET Core projects do not show a Packages folder in the Solution window. Instead the NuGet packages are displayed in a NuGet folder, which is inside a Dependencies folder.

The version of the NuGet package is displayed directly in the Solution window. For other project types you need to right click the package to see the version.

If the NuGet package depends on other packages then these can be seen by clicking on the arrow to expand the dependencies.

Restoring Packages

NuGet packages will be restored automatically on opening a .NET Core project. This can be disabled in preferences by unchecking Automatically restore packages when opening a solution in the NuGet – General section.

You can manually restore NuGet packages for .NET Core projects by:

• Right clicking the Dependencies folder and selecting Restore.
• Right clicking the NuGet folder and selecting Restore.
• Selecting Restore NuGet Packages from the Project menu.

Selecting Restore NuGet Packages from the Project menu will restore packages for the project or the solution depending on what is currently selected in the Solution window.

Restoring NuGet packages for a .NET Core project works differently compared with a project that uses a packages.config file. The NuGet packages themselves will be downloaded into the NuGet package cache folder ~/.nuget/packages if they do not exist, as before, but the NuGet packages will not be copied into a packages directory inside the solution’s directory. The project file will not contain have any Reference items added when a NuGet package is installed.

When a NuGet restore is run for a .NET Core project three files in the obj directory are created.

• project.assets.json
• ProjectName.csproj.nuget.g.props
• ProjectName.csproj.nuget.g.targets

The project.assets.json file contains the dependencies for your project.

The nuget.g.props and nuget.g.targets files will contain any MSBuild imports that your NuGet package requires and they also define some properties, such as the path to the NuGet package cache on your machine.

These three files are used when building your project to resolve the assemblies to be referenced now that they are no longer explicitly stored in your project file.

Updating Packages

NuGet packages can be updated by:

• Right clicking the package inside the NuGet folder and selecting Update.
• Right clicking the NuGet folder and selecting Update.
• Right clicking the Dependencies folder and selecting Update.
• Selecting Update NuGet Packages from the Project menu.

Selecting Update NuGet Packages from the Project menu will update all packages in the project or in the solution depending on what is currently selected in the Solution window.

Removing Multiple NuGet Packages in One Step

You can remove multiple NuGet packages in one step from a .NET Core project by selecting the packages in the Solution window, right clicking and selecting Remove.

Projects that use a packages.config file do not support removing multiple NuGet packages in one step.

Installing NuGet Packages

NuGet packages are installed by using the Add Packages dialog in the same way as with other project types. To open the Add Packages dialog for a .NET Core project:

• Right click the NuGet folder and select Add Packages…
• Right click the Dependencies folder and select Add Packages…
• Right click the project and select Add – Add NuGet Packages…
• From the Project menu select Add NuGet Packages…

When the first NuGet package is installed into a .NET Core project a packages.config file will not be created. Instead the NuGet package will be added as a PackageReference that is saved in the project file.

Package Reference

.NET Core projects do not use a packages.config file to record their NuGet dependencies. Instead the .NET Core project file will contain a PackageReference after the NuGet package is installed into the project.

1
2
3
4
5
6
7
8
9
10
11

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="10.0.2" />
  </ItemGroup>
</Project>

Please note that Visual Studio for Mac currently only supports package references with the new SDK style projects which are used by .NET Core. If you use package references in other project types then the Solution window will not show the packages and a packages.config file will be created if you install a NuGet package.

Updated Packages Available

For other project types the Solution window will check for updated packages and show this information in the Packages folder. This is not currently supported with .NET Core projects.

NuGet 4.0 Support

Visual Studio for Mac now includes NuGet 4.0.

More information on the new features provided by NuGet 4.– can be found in the Announcing NuGet 4.0 RTM blog post and the NuGet 4.0 release notes.

• Integrated support for creating NuGet packages with NuGetizer 3000
• NuGet 3.5 support
• Improved project.json support
• Native License Acceptance dialog

More information on all the new features and changes in Xamarin Studio 6.2 can be found in the release notes.

NuGetizer 3000

NuGetizer 3000 is a set of build tools for creating NuGet packages inspired by NuProj. Support for NuGetizer 3000 in Xamarin Studio includes:

• Project templates for creating NuGet packages
• Support for creating a NuGet package from an existing project
• Reference assembly generation for Portable Class Library profiles

The following sections look at the NuGetizer 3000 features provided by Xamarin Studio. For more detailed information on what is supported by NuGetizer 3000 please read the NuGetizer 3000 feature spec.

Project Templates

There are two new project templates available.

• Multiplatform Library
• NuGet package

Multiplatform Library – Single for all platforms

The Mulitplatform Library project template will create a Portable Class Library project with NuGet package metadata when the Single for all platforms option is selected.

To create a NuGet package right click the project and select Create NuGet Package. This will generate a NuGet package (.nupkg) in the output directory with the Portable Class Library assembly in the corresponding portable lib directory inside the NuGet package.

Multiplatform Library – Platform specific

This Multiplatform Library will create a shared project, an iOS project, an Android project and a NuGet packaging project when the iOS and Android options are selected.

The iOS and Android project will reference the shared project. The NuGet packaging project will reference the iOS and Android projects. The NuGet packaging project will contain the NuGet package metadata.

When the NuGet packaging project is built it will create the NuGet package in its output folder and inside the NuGet package will be the Android and iOS output assemblies each in their own platform specific lib folders.

NuGet Packaging Project

The NuGet packaging project can be used to create a meta NuGet package, which is a NuGet package that has no content itself but references other NuGet packages, or it can reference other projects and it will add their output assemblies to the NuGet package. If the referenced project has NuGet package references then these will be added to the generated NuGet package as dependencies.

NuGet packages can be added to the NuGet packaging project by using the Add Packages dialog.

To include files in the NuGet packaging project the files need to have Include in Package property set to true. This can be done by right clicking the file in the solution window, selecting Properties, then selecting Include in Package from the NuGet section in the Properties window.

Adding NuGet Package Metadata

NuGet package metadata can be added to any .NET project by selecting the NuGet Package – Metadata page available in the project options.

The General tab shows compulsory metadata that must be specified for a NuGet package. The Details tab shows other optional metadata that can be specified. This NuGet package metadata is saved directly into the project file (.csproj).

Once NuGet package metadata has been added then the NuGet.Build.Packaging NuGet package will be added to the project if it does not already exist. This NuGet package provides MSBuild tasks that are used when creating the NuGet package for the project.

NuGet package metadata should be added to project if you want to be able to create a NuGet package for that project on its own. Without NuGet package metadata the project would need to be referenced by a NuGet packaging project, or another project with NuGet package metadata, for it to be included in a NuGet package.

If a NuGet packaging project references a project that has its own NuGet package metadata then a dependency will be added to the NuGet package created by the NuGet packaging project. The referenced project’s output assembly would not be included in the NuGet package created by the packaging project in this case.

Generating a NuGet Package

To generate a NuGet package you can right click the project and select Create NuGet Package.

For NuGet packaging projects you can also build the project and it will create a NuGet package.

For a .NET project that has NuGet package metadata you can generate a NuGet package when building the project by enabling the “Create a NuGet Package when building the project” option in the Project Options dialog.

Adding Platform Implementations

If you have a Portable Class Library with NuGet package metadata you can add platform specific implementations for iOS and Android by right clicking the project and selecting Add – Add Platform Implementation. This will open a dialog where you can choose iOS and Android, and also whether to create a shared project.

After clicking OK an Android and iOS project will be created along with a NuGet packaging project that references these projects. The NuGet package metadata will be moved from the Portable Class Library project to the NuGet packaging project. If the shared project option was selected then the code from the Portable Class Library project will be moved to the shared project. The shared project will be referenced by the iOS and Android project.

Reference Assembly Generation

In the Project Options for a NuGet Packaging project there is a Reference Assemblies page in the NuGet Package category. This pages shows a list of Portable Class Library profiles that can be selected.

Reference assemblies for the selected profiles will be generated based on the output assemblies from the projects referenced by the NuGet packaging project.

That brings us to the end of the walkthrough of the NuGetizer 3000 features provided by Xamarin Studio.

NuGet 3.5 Support

Xamarin Studio now includes NuGet 3.5.

More information on the new features provided by NuGet 3.5 can be found in the Announcing NuGet 3.5 RTM blog post and the NuGet 3.5 release notes.

Improved project.json Support

NuGet packages are now automatically restored when the project.json file is saved in the text editor.

Native License Acceptance Dialog

The Licence Acceptance dialog now uses native UI.

Bug Fixes

Updating all NuGet packages installs unexpected pre-release NuGet packages

With a pre-release NuGet package installed in a project, updating all the NuGet packages in the project could cause the stable NuGet packages to be updated to pre-release versions. On updating all the packages if any were pre-release the include pre-release flag would be set on updating which would allow any pre-release NuGet packages to be used on updating. Now the include pre-release flag is not set on updating. NuGet 3 will still update pre-release NuGet packages to the latest pre-release or latest stable, depending on which is the latest version, without this include pre-release flag being set. NuGet 2 required the include pre-release flag set to update a pre-release to the latest pre-release.

An example – project has the following NuGet packages installed:

Xamarin.Forms 2.3.3.180
Xamarin.Forms.CarouselView 2.3.0-pre1

Latest available packages from nuget.org:

Xamarin.Forms 2.3.3.180 (latest stable)
Xamarin.Forms 2.3.4.184-pre1 (latest pre-release)
Xamarin.Forms.CarouselView 2.3.0-pre2

Expected result on updating all packages in the project:

Xamarin.Forms 2.3.3.180
Xamarin.Forms.CarouselView 2.3.0-pre2

Actual result:

Xamarin.Forms 2.3.4.184-pre1
Xamarin.Forms.CarouselView 2.3.0-pre2

Types unavailable when NuGet package added to project.json file

When a NuGet package was added to a project that used a project.json file the types from the assembly provided by the NuGet package were not available until the project was reloaded or the references were modified. This prevented code completion from showing the correct information.