Matt Ward

NuGet PowerShell Core Console in Visual Studio for Mac 8.0

The NuGet extensions addin now includes a PowerShell Core based NuGet Package Manager console for Visual Studio for Mac 8.0.

NuGet Package Manager Console window

A NuGet PowerShell console has been available with the NuGet extensions addin since Xamarin Studio 5.0. Previously it used Pash, a cross-platform, open source reimplementation of PowerShell. Pash is no longer being actively developer on after Microsoft released PowerShell Core. The PowerShell support in Pash was incomplete, so whilst the NuGet commands, such as Install-Package, were supported, more complicated commands, such as those provided by Entity Framework Core, were not supported. Moving to PowerShell Core provides full PowerShell support, and with a partial implementation of the Visual Studio EnvDTE API, Entity Framework Core commands are now supported.

The NuGet extensions addin runs a .NET Core console application that hosts PowerShell Core. Communication between the addin running in Visual Studio for Mac and the console application is through the StreamJsonRpc library.

New Features

The following lists the new features compared with the Pash based PowerShell console.

  • PowerShell Core based NuGet Package Manager Console
    • Full PowerShell support
    • Get-Help now supported
  • Support for Entity Framework Core NuGet commands
  • Tab completion
  • Support for stopping the executing command
  • Opening the NuGet package source configuration page from the console

Limitations

  • Visual Studio EnvDTE API implementation is incomplete

The Visual Studio EnvDTE API is partially implemented. Whilst Entity Framework Core is supported other PowerShell scripts included with NuGet packages may not work.

  • Password protected NuGet package sources not supported in the following PowerShell commands:

    • Find-Package
    • Get-Package

Note that the other NuGet PowerShell commands are supported.

The NuGet extensions addin will not send usernames and passwords to the PowerShell Core host console application. .NET Core also does not support decrypting passwords stored in the NuGet.Config file.

The Find-Package and Get-Package commands all run completely within PowerShell hosted in the .NET Core console application.

The other commands work since they run partially within Visual for Mac where actions involving password protected NuGet package sources are supported.

  • Requires .NET Core 2.1 SDK to be installed

Opening the NuGet Package Manager Console window

From the View menu, select Pads, then select NuGet Package Manager Console.

View - Pages - NuGet Package Manager Console menu

 Entity Framework Core Support

The PowerShell commands provided by the Microsoft.EntityFrameworkCore.Tools NuGet package are supported in .NET Core projects.

  • Add-Migration
  • Drop-Database
  • Get-DbContext
  • Remove-Migration
  • Scaffold-DbContext
  • Script-Migration
  • Update-Database

Package Manager Console - Entity Framework Core Add-Migration and Update-Database commands

Note that the Entity Framework Core commands are not currently supported in projects that target the .NET Framework. This is because the PowerShell commands attempt to directly run ef.exe that is included in the NuGet package instead of using the .NET Core ef.dll which is used with projects that target .NET Core.

Tab Completion

Pressing tab in the console window will try to auto-complete the command being typed in.

Tab completion - Install-Package Newtonsoft.Json

Tab completion - Install-Package Newtonsoft.Json -Version

If there is only one match on pressing tab then the text will be inserted.

If there are multiple possible matches then a window will be displayed allowing an item to be selected by pressing Tab, Enter or Return. Typing with this completion list window open will filter the items in the list.

Stopping the PowerShell command being run

When a PowerShell command is being run the Stop button is enabled. The Stop button is the last button on the top right of the NuGet Package Console window.

Package Manager Console stop button

Clicking this button will attempt to stop the PowerShell command being run.

Package Manager Console pipeline stopped

Opening the NuGet Package Console configuration page

At the top of the NuGet Package Console window there is a cog icon after the list of package sources.

Package Manager Console configure sources cog icon

Clicking this cog icon will open the NuGet Package Sources configuration page which is also available from Preferences – NuGet – Sources.

Installation

The NuGet extensions addin is available from the Visual Studio for Mac extensions repository. To install the addin:

  • From the main menu, open the Extensions Manager dialog.
  • Select the Gallery tab.
  • Expand IDE extensions.
  • Select NuGet Package Management Extensions 0.18 or later.
  • Click the Refresh button if the addin is not visible.
  • Click Install‚Ķ to install the addin.
  • Restart Visual Studio for Mac.

NuGet Support in Visual Studio for Mac 8.0

Changes

  • Fixed build action not available after installing package into a PackageReference project
  • Fixed NuGet extension api install events not raised for PackageReference projects

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

Bug Fixes

Fixed build action not available on installing package into a PackageReference project

After installing the Xamarin.GooglePlayServices.Basement NuGet package, into a project that used PackageReferences, the GoogleServicesJson build action, defined by this NuGet package, was not available in the list of build actions when you right clicked a file in the Solution window. The build action was available after the solution was closed and re-opened.

Installing a NuGet package into a project that used PackageReferences would not re-evaluate the project’s MSBuild information. This resulted in any custom AvailableItemNames not being available to be used as a build action in the Solution window. The build actions for a project were cached so these are now cleared to ensure the latest items are available after an re-evaluation.

Fixed NuGet extension api install events not raised for PackageReference projects

The NuGet extension API has a PackageReferenceAdded event and a PackageReferenceRemoved. These were being raised if a project had a packages.config file but not if the project used PackageReferences.

NuGet Support in Visual Studio for Mac 7.8

Changes

  • NuGet package diagnostics displayed in Solution window
  • Support restoring multi-target framework projects
  • Display summary of NuGet restore errors in Package Console
  • Fixed wrong version of Microsoft.AspNetCore.App being restored
  • Fixed Paket restore not working with SDK style projects
  • Fixed NuGet restore ignoring build targets

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

NuGet package diagnostics displayed in Solution window

NuGet package diagnostic warnings are now shown in the Solution window.

NuGet package diagnostic warnings in Solution Window

The diagnostic warnings are shown underneath the NuGet package with a warning icon. Hovering over the warning icon will show a tooltip.

NuGet package diagnostic warning tooltip in Solution Window

Support restoring multi-target framework projects

Projects that have multiple target frameworks now have all frameworks restored.

Multi-target framework project restored in Solution window

Previously only the first target framework would be restored.

Conditional PackageReferences defined in the project file are also now respected when restoring the project. Previously the conditions on the PackageReferences would be ignored.

Conditional PackageReferences restored in Solution window

Visual Studio for Mac now uses the GenerateRestoreGraphFile MSBuild target to determine package dependencies. Previously this information was obtained from the project information held in memory. This fixes several NuGet restore bugs in Visual Studio for Mac.

Display summary of NuGet restore errors in Package Console

Creating an xUnit .NET Core test project named ‘xunit’ fails to restore since there is a package reference cycle between the project and the xunit NuGet package. Whilst this reference cycle is reported it is hidden in the Package Console output and all you would see was a message indicating that the restore had failed. Now the error information is shown at the end of the Package Console as a summary of the failures to make it easier to see the problem.

Now for the xunit project you will see the following at the end of the Package Console output:

Cycle detected.
  xunit -> xunit (>= 2.3.1).
Restore failed.

Bug Fixes

Fixed wrong version of Microsoft.AspNetCore.App being restored

With an ASP.NET Core 2.1 project, that had included a PackageReference for Microsoft.AspNetCore.App version 2.1.5, Visual Studio for Mac would incorrectly restore Microsoft.AspNetCore.App version 2.1.1.

Using the GenerateRestoreGraphFile MSBuild target to determine package reference information when restoring has fixed this problem.

Fixed Paket restore not working with SDK style projects

When Paket is used with an SDK style project it injects PackageReferences via the PaketRestore target from the Paket.Restore.targets file. Visual Studio for Mac was not using MSBuild to get the package reference information so PackageReferences defined by Paket were not being restored or made available.

Fixed NuGet restore ignoring build targets

OrchardCore would fail to restore when opened in Visual Studio for Mac. OrchardCore defines the PackageReference versions in a separate MSBuild .props file and has a custom MSBuild target to define these versions. This custom MSBuild target is now supported since Visual Studio for Mac uses the GenerateRestoreGraphFile MSBuild target to determine package references when restoring.

Task Runner Explorer in Visual Studio for Mac

The Task Runner Explorer addin provides a Task Runner Explorer window, similar to the one in Visual Studio on Windows, which can be used to run tasks with Cake, Gulp, Grunt, NPM and TypeScript.

Task Runner Explorer Window

Features

  • Task Runner Explorer Window
    • View tasks
    • Run tasks
    • View task output
    • Run and cancel long running tasks, such as tcs watch
    • Configure tasks to run when specific IDE events occur
      • Before Build
      • After Build
      • Clean
      • Project Opened
      • Solution Opened
  • Task Runners
    • Cake
    • Gulp
    • Grunt
    • NPM
    • TypeScript

Supports

  • Visual Studio Mac 7.5 or later.

Task Runner Explorer

To open the Task Runner Explorer window, from the View menu select Pads, then select Task Runner Explorer.

View Task Runner Explorer menu

The Task Runner Explorer will look for files supported by a task runner in the solution directory and the project directory. It will also look at all files that have been added to a project or that have been added to a solution folder.

Task Runner Explorer TypeScript and NPM tasks

The top left of the Task Runner Explorer shows a list of projects or the solution that have tasks available. This can be used to filter the tasks shown in the Task Runner Explorer window.

Currently changes made to tasks will not be detected automatically. To refresh the task information you can click the Refresh button available at the top left of the Task Runner Explorer window.

Running a Task

To run a task you can double click it or right click and select Run.

Task Runner Explorer Run menu

Output from the task is shown on the right hand side of the Task Runner Explorer window.

NPM update running

NPM update completed

A long running task, such as tcs watch, will run until the solution is closed, or the Stop button, available on the right hand side of the Task Runner Explorer window, is clicked.

Binding Tasks to IDE Events

Tasks can be configured to run when the following IDE events occur:

  • After Build
  • Before Build
  • Clean
  • Project or Solution Opened

If the task runner file is in a project directory then the build and clean events are associated with the project. If the task runner file is in a solution directory then the build events are associated with the solution.

To configure a task, right click it, select Bindings and then select the event.

Task Runner Explorer Bindings menu

The binding will be displayed in the Bindings tab and will also be shown as checked when the context menu for the task is opened.

Task Runner Explorer Before Build binding added

To remove the binding you can right click the task, select Bindings and select the event again to uncheck it. Alternatively you can right click it in the Bindings tab and select Remove.

The order in which the tasks are run for a particular IDE event can be changed by right clicking the binding in the Bindings tab and selecting Move Up or Move Down.

Task Runner Explorer binding Move Up and Down menus

The binding information is typically saved in a file in the same directory as the corresponding task runner file, however this depends on how the task runner is implemented.

Disabling Automatic Running of Tasks

In preferences there is a Task Runner Explorer section which shows a check box that can be used to enable or disable the automatic running of tasks on opening a project or solution, and when building or cleaning.

Preferences - Automatically run tasks option

Cake Task Runner

The Cake task runner supports running tasks defined in a build.cake file.

Cake Task Runner

This is based on the Cake Task Runner for Visual Studio.

Gulp Task Runner

The Gulp task runner supports running tasks defined in a gulpfile.js file.

Gulp Task Runner

Gulp needs to be installed separately.

Grunt Task Runner

The Grunt task runner supports running tasks defined in a Gruntfile.js file.

Grunt Task Runner

Grunt needs to be installed separately.

NPM Task Runner

The NPM task runner supports running tasks defined in a package.json file.

NPM task runner

The NPM task runner is a port of Mads Kristensen’s NPM Task Runner.

The NPM task runner supports running with the verbose NPM option defined. If a task is selected then a button will be displayed on the left hand side of the Task Runner Explorer window. If this is selected then npm will be passed the -d argument when it is run.

NPM task runner Verbose button

NPM needs to be installed separately.

TypeScript Task Runner

The TypeScript task runner supports running tcs build and tcs watch if a tsconfig.json file is found.

TypeScript task runner

TypeScript tcs watch output

The TypeScript task runner will try to use tsc that is distributed with the Web Tools extension that is included in Visual Studio for Mac. If the Web Tools extension is not installed then the task runner will fall back to running tsc directly.

Installation

There are two addins to be installed:

The Task Runner is the main addin. This will be used by other task runner addins and provides the main task runner API and services.

The Task Runners Bundle addin contains the Cake, Gulp, Grunt, NPM and TypeScript task runners. These are currently included together as a single addin instead of being distributed separately.

Download both of the above .mpack files. Install the Task Runner addin first since the Task Runners Bundle addin depends on it. To install an addin’s .mpack file, 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. After installing both the addins restart Visual Studio for Mac.

These addins are not currently available from the main Visual Studio for Mac extensions server.

Source Code

NuGet Support in Visual Studio for Mac 7.7

Changes

  • NuGet 4.8 support
  • Support PackageReferences without a Version
  • Fixed NuGet sdk resolver not being found in Mono 5.16
  • Fixed null reference exception in package compatiblity check
  • Fixed Update menu enabled when project has no PackageReferences
  • Fixed updating a NuGet package changing a reference’s ItemGroup
  • Fixed updating a NuGet package changing a fully qualified reference hint path to a relative path

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

NuGet 4.8 support

NuGet 4.8.0.5385 is now included with Visual Studio for Mac 7.7.2.

Support PackageReferences without a Version

Visual Studio for Mac did not support projects that used PackageReferences without specifying a version.

<ItemGroup>
    <PackageReference Include="Newtonsoft.Json" />
</ItemGroup>

The version may be defined elsewhere in another MSBuild file, such as the Directory.props file, or by the .NET Core SDK, as with the Microsoft.AspNetCore.App PackageReference in ASP.NET Core projects. By default a PackageReference without a version will restore the lowest available version for the NuGet package.

However in Visual Studio for Mac there were several problems with PackageReferences that did not specify a version.

Opening a project with a PackageReference without a Version would result in an ArgumentNullException being logged and the Add Packages dialog could not be opened.

If the PackageReference, in a non-SDK project, had no Version then it was not displayed in the Packages folder and a null reference exception was logged. The Solution window would try to find the package to check if it was installed which is not possible with a missing version and NuGet’s VersionFolderPathResolver would throw a null reference exception.

If a PackageReference had no Version then a null reference exception was logged when checking for updates. A null version is now handled.

Right clicking the package in the Packages folder would log a null reference exception if a non-SDK style project was used and it had a PackageReference without a version. This is now handled and the menu label will show “Version None”.

Bug Fixes

Fixed NuGet sdk resolver not being found in Mono 5.16

More recent versions of MSBuild, such as MSBuild 16.0.40 which is included with Mono 5.16.0.173, allow the sdk resolver to use a manifest.xml file to define the assembly where the resolver can be found:

<SdkResolver>
  <Path>..\..\Microsoft.Build.NuGetSdkResolver.dll</Path>
</SdkResolver>

This manifest file not supported and resulted in the NuGet sdk resolver not being loaded. Any projects that use an MSBuild sdk from a NuGet package no longer worked and would result in an ‘Invalid configuration mapping’ error shown in the Solution window. The sdk resolution in Visual Studio for Mac has now been updated based on the latest MSBuild source code.

Fixed null reference exception in compatiblity check

Changing the target framework of a project that uses a packages.config file will result in a package compatiblity check being run. If the project had both a PackageReference and a packages.config file the package compatiblity check would fail with a null reference exception. Visual Studio for Mac was treating the project as though it was using a packages.config file, when it should have been treated as a PackageReference project. This resulted in a null reference exception being thrown when checking for package compatiblity.

Fixed Update menu enabled when project has no PackageReferences

The Update menu was enabled if the project used PackageReferences but had none in the project. Without any PackageReferences in the project there is no packages to update. The check to determine if the Update menu should be enabled has been changed to make sure the project has PackageReferences in the project file, not just imported PackageReferences. The Update NuGet Packages menu, which is used to update packages for the solution, has also been changed to have the same behaviour.

Fixed updating a NuGet package changing a reference’s ItemGroup

On updating a NuGet package the Reference item will now be modified in place in the project file.

On updating a NuGet package in a project that used a packages.config the old NuGet package is uninstalled and the new one is installed. This removes the old references and adds new references. If the references are in an ItemGroup with a condition then the new reference may be added into a different ItemGroup if there are other ItemGroups with references. To prevent this from happening the changes to made to references are cached and not applied to the project until all the NuGet actions have all been run. This allows a NuGet package update which would remove a reference and then add a new reference to be converted into an update of the original Reference in the project, changing just its HintPath, so its location in the project file is not changed.

This was fixed in Visual Studio for Mac 7.7.3.

Fixed updating a NuGet package changing a fully qualified reference hint path to a relative path

Updating a NuGet package, where the project, which uses a packages.config file, had been modified so the original reference had a fully qualified hint path, would result in a relative path used for the hint path when the reference was updated.

Now if the original hint path was full path then if the hint path for the reference is changed it is saved using a full path. This is different behaviour to how Visual Studio on Windows works, which will always add a relative hint path for the reference.

This was fixed in Visual Studio for Mac 7.7.3.

Proxy Testing a Mac Application with Apache

Here we look at using Apache as a proxy server in order to test that a Mac client application, such as Safari or Visual Studio for Mac, can make web requests through a proxy. Enabling Basic and NTLM proxy authentication with Apache will be covered, as well as using the Apache as a proxy without any authentication.

Apache will run on a separate Windows machine. Using a separate machine allows us to check that the Mac client application is not bypassing the proxy and making direct web requests to any server. This check can be done by configuring the local firewall to block all direct connections out from the Mac machine but allow connections from the machine running Apache.

Apache Proxy – No authentication

Unzip Apache and extract the files to c:\Apache24\ which is the default ServerRoot configured in the conf\httpd.conf file.

Define SRVROOT "/Apache24"

In the httpd.config file configure the port to be used by the Apache server if required. By default port 80 is used. Here we will be using port 8888.

Listen 8888
ServerName localhost:8888

mod_proxy, mod_proxy_connect and mod_proxy_http should be loaded. Edit the http.conf file and ensure these modules are loaded.

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so

Add a VirtualHost and Proxy section to the httpd.conf file.

<VirtualHost *>
     ProxyRequests On

    <Proxy *>
        Require all granted
    </Proxy>
</VirtualHost>

To run Apache, open a command prompt, change into the Apache24\bin directory, then run httpd.exe

cd c:\Apache24\bin
httpd.exe

On running Apache for the first time you will see a Windows Firewall dialog.

Windows Firewall alert for Apache

Allow Apache to access both the private and public networks.

Configuring the Mac to use Apache as its proxy server can be done by opening System Preferences – Network. For the active network select the Advanced button and open the Proxies tab. Enter the machine IP address where Apache is running and its port into the Web Proxy (HTTP) and Secure Web Proxy (HTTPS) sections, and ensure both of these are checked.

Mac web proxy settings

Finally click OK and Apply to enable the proxy settings.

Now http and https requests should be sent through Apache. A simple way to test this is to open Safari and view a web page. In the C:\Apache24\logs\access.log file you should see entries for the sites accessed.

192.168.1.100 - - [28/Oct/2018:12:18:47 +0000] "GET http://neverssl.com/ HTTP/1.1" 200 1183
192.168.1.100 - - [28/Oct/2018:12:18:47 +0000] "GET http://neverssl.com/favicon.ico HTTP/1.1" 200 124
192.168.1.100 - - [28/Oct/2018:12:18:41 +0000] "CONNECT www.nuget.org:443 HTTP/1.1" 200 -

Apache Proxy – Basic authentication

To enable Basic authentication change the Proxy section in the httpd.conf file as shown below.

<VirtualHost *>
     ProxyRequests On

    <Proxy *>
        AuthType Basic
        AuthName "Authentication required"
        AuthBasicProvider file
        AuthUserFile proxy-password.file
        Require valid-user
    </Proxy>
</VirtualHost>

Here we will be using htpasswd.exe to create a file to store the username and password required to authenticate against the proxy server. htpasswd.exe is in the Apache bin directory. Run the following to generate the proxy-password.file, replacing user with the username to be used with the proxy.

htpasswd.exe -c proxy-password.file user

Enter the password when prompted.

Copy the proxy-password.file to the Apache server’s root directory c:\Apache24

To make it easier to see the basic auth header being sent you may want to enable forensic logging in Apache. To do this add a LoadModule to the httpd.conf file.

LoadModule log_forensic_module modules/mod_log_forensic.so

Define the path to the forensic log file using an IfModule.

<IfModule log_forensic_module> 
    ForensicLog "logs/forensic.log"
</IfModule> 

Run httpd.exe from the Apache24\bin directory.

When connecting through the proxy for the first time the Mac will show a dialog asking for credentials.

Mac proxy authentication required dialog

Clicking the System Preferences button will show open a dialog where you can enter the credentials for the proxy.

Mac proxy authentication required - credentials dialog

Entering the credentials will result in the Mac’s key chain being updated with the credentials associated with the proxy’s address.

Proxy credentials stored in Mac key chain

If you open the Mac’s Network settings you will see the Web Proxy and Secure Web Proxy settings now have a username and password associated with them.

Username and password associated with proxy in network settings

In the Apache access.log you should see the requests being made and a Proxy authentication 407 status code.

192.168.1.100 - - [28/Oct/2018:12:44:47 +0000] "CONNECT www.nuget.org:443 HTTP/1.1" 407 415
192.168.1.100 - - [28/Oct/2018:12:44:53 +0000] "GET http://neverssl.com/ HTTP/1.1" 407 415

In the forensic.log file you should see the basic proxy authorization header being used by the Mac.

GET http%3a//neverssl.com/ HTTP/1.1|Host:neverssl.com|Connection:keep-alive|Proxy-Connection:keep-alive|Upgrade-Insecure-Requests:1|Proxy-Authorization:Basic MTox|Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8|User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Safari/605.1.15|Accept-Language:en-gb|DNT:1|Accept-Encoding:gzip, deflate
CONNECT www.nuget.org%3a443 HTTP/1.1|Host:www.nuget.org%3a443|User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Safari/605.1.15|Connection:keep-alive|Proxy-Authorization:Basic MTox|Proxy-Connection:keep-alive

Apache Proxy – NTLM authentication

In order to enable NTLM authentication the NTLM authentication module needs to be downloaded. Download Mod Auth NTLM for Apache 2.4.x x64 – mod_authn_ntml.zip, extract the files and copy the mod_auth_ntlm.so file to the Apache24\modules directory.

Add a LoadModule to the httpd.conf file for the mod_authn_ntlm.so file.

LoadModule auth_ntlm_module modules/mod_authn_ntlm.so

Change the VirtualHost Proxy section as shown below:

<VirtualHost *>
    ProxyRequests On

    <Proxy *>
        AuthType SSPI
        AuthName "Auth required"
        NTLMAuth On
        NTLMAuthoritative On

        <RequireAll>
            <RequireAny>
                Require valid-user
            </RequireAny>

            <RequireNone>
                Require user "ANONYMOUS LOGON"
                Require user "NT AUTHORITY\ANONYMOUS LOGON"
            </RequireNone>
        </RequireAll>
    </Proxy>
</VirtualHost>

The username and password used to authenticate against the proxy needs to match an account on the Windows machine. As with basic authentication, the Mac will prompt for credentials if they do not match what is stored in the key chain for the proxy.

Run httpd.exe and then use Safari to open a web site to check web requests are being sent through the proxy. You should see the Windows account being used to authenticate in Apache’s access.log.

192.168.1.100 - - [28/Oct/2018:13:09:19 +0000] "GET http://neverssl.com/ HTTP/1.1" 407 415
192.168.1.100 - windows\\useraccount [28/Oct/2018:13:09:19 +0000] "GET http://neverssl.com/ HTTP/1.1" 304 -
192.168.1.100 - - [28/Oct/2018:13:09:38 +0000] "CONNECT www.nuget.org:443 HTTP/1.1" 407 415
192.168.1.100 - windows\\useraccount [28/Oct/2018:13:09:12 +0000] "CONNECT www.nuget.org:443 HTTP/1.1" 200 -

The forensic log should show that the NTLM header is being used by the Mac.

CONNECT www.nuget.org%3a443 HTTP/1.1|Host:www.nuget.org%3a443|User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Safari/605.1.15|Connection:keep-alive|Proxy-Authorization:NTLM T...|Proxy-Connection:keep-alive
GET http%3a//neverssl.com/ HTTP/1.1|Host:neverssl.com|Proxy-Connection:keep-alive|Proxy-Authorization:NTLM T...|If-Modified-Since:Thu, 14 Jun 2018 00%3a16%3a40 GMT|Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8|Accept-Language:en-gb|Accept-Encoding:gzip, deflate|Content-Length:0|User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Safari/605.1.15|Connection:keep-alive|Upgrade-Insecure-Requests:1|DNT:1

Proxy Testing a Mac Application with Fiddler

Here we look at using Fiddler as a proxy server in order to test a Mac client application, such as Safari or Visual Studio for Mac, can make web requests through the proxy. Enabling Basic proxy authentication with Fiddler will be covered, as well as using the Fiddler as a proxy without any authentication.

Fiddler will run on a separate Windows machine. Using a separate machine allows us to check that the Mac client application is not bypassing the proxy and making direct web requests to any server. This check can be done by configuring the local firewall to block all direct connections out from the Mac machine but allow connections from the machine running Fiddler.

  • Mac High Sierra 10.13
  • Fiddler 5.0 on Windows

Fiddler Proxy – No authentication

To enable the Mac to use Fiddler as its proxy first configure Fiddler to allow remote connections. This can be done by open the Tools menu, selecting Options, opening the Connections tab, and checking Allow remote computers to connect.

Fiddler allow remote connections

Configuring the Mac to use Fiddler as its proxy server can be done by opening System Preferences – Network. For the active network select the Advanced button and open the Proxies tab. Enter the Fiddler’s machine IP address and port into the Web Proxy (HTTP) and Secure Web Proxy (HTTPS) sections, and ensure both of these are checked.

Mac web proxy settings

Finally click OK and Apply to enable the proxy settings.

Now http and https requests should be sent through Fiddler. A simple way to test this is to open Safari and open a web page.

Fiddler https request recorded

Fiddler Proxy – Basic authentication

To enable Basic proxy authentication in Fiddler open the Rules menu and ensure that Require Proxy Authentication is checked.

Fiddler require proxy authentication option

This will result in Fiddler requiring Basic authentication with a username ‘1’ and a password ‘1’.

Unfortunately it seems that the native Mac networking API does not work with Fiddler for https requests but will work for non-secure http requests. Opening a web page in Safari will cause the Mac to prompt for the proxy credentials.

Mac proxy authentication required dialog

Clicking the System Preferences button will show open a dialog where you can enter the credentials for the proxy.

Mac proxy authentication required - credentials dialog

Entering the credentials will result in the Mac’s key chain being updated with the credentials associated with the proxy’s address.

Proxy credentials stored in Mac key chain

If you open the Mac’s Network settings you will see the Web Proxy and Secure Web Proxy settings now have a username and password associated with them.

Username and password associated with proxy in network settings

Safari will display an error page when accessing a web page over https when the Mac is configured to use Fiddler’s basic authentation proxy.

Safari 310 proxy error

It seems that for a https request the Mac sends the request with two keep alive headers:

  • Connection: keep-alive
  • Proxy-Connection: keep-alive

Fiddler responds with a 407 proxy authentication required response and a close header.

  • Connection: close

Fiddler https request denied

Since the keep-alive is not being honoured by Fiddler the web request sent from the Mac fails and an kCFErrorDomainCFNetwork 310 error occurs. This maps to the kCFErrorHTTPSProxyConnectionFailure status code.

Other applications that do not use the native Mac networking API, such as the Google Chrome web browser, will work with Fiddler and will prompt for credentials.

Unfortunately you currently cannot use Fiddler with basic proxy authentication enabled to test a Mac application making https requests. As an alternative you can use another proxy server, such as Apache.

.NET Core Support in Visual Studio for Mac 7.6

Changes

  • NuGet SDK resolver now used to find NuGet SDK packages
  • Fixed Synchronous operation cancelled message on stopping debugging
  • Fixed debugger hanging when debugging unit tests
  • Fixed command line arguments not used with a new project
  • Fixed hang when discovering unit tests
  • Allow loading of SDK style projects without a main PropertyGroup
  • Fixed TargetFramework not being updated in project
  • Fixed .xaml.cs code completion in new Xamarin.Forms .NET Standard project
  • Fixed default build action for new HTML file
  • Fixed SDK version not being parsed from Sdk attribute
  • Fixed null reference on opening .NET Core project with sdk version
  • 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.

NuGet SDK resolver now used to find NuGet SDK packages

Visual Studio for Mac now has 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

Fixed synchronous operation cancelled message on stopping debugging

Stopping the .NET Core debugger would sometimes result in a dialog being displayed indicating that the debugger operation failed.

Debugger operation failed - Synchronous operation cancelled - dialog

Fixed debugger hanging when debugging unit tests

The .NET Core debugger would sometimes hang Visual Studio for Mac when debugging unit tests. The problem was that if the breakpoint was placed on an invalid line then the .NET Core debugger would send back the adjusted breakpoint location. Visual Studio for Mac would then send back an incorrect breakpoint line back to the .NET Core debugger, which again resulted in the debugger sending back a corrected line. This would repeat resulting in the IDE and debugger getting stuck in a loop.

Fixed command line arguments not used with a new project

Creating a new .NET Core console project, editing the project run configuration to use extra command line arguments, or to not use the external console, then building and running the project would result in the project run configuration not being used. No extra arguments would be passed to the console project, and the external console would still be used. This could be fixed by closing and re-opening the solution.

The problem was that when the project is re-evaluated, after it is created, its run configurations are cleared. The solution’s startup run configuration would still be using the original project run configuration that was no longer used. Changes made to the project run configuration then had no affect. Closing and re-opening the solution fixed this since the run configuration defined in the .csproj.user file is re-used when the project is re-evaluated on reloading so both the solution run configuration and the project run configuration refer to the same configuration. To fix this, on re-evaluating the project, if the solution’s run configuration refers to a project run configuration that has been removed then the solution’s startup configuration is refreshed.

Note that there is a similar problem with multiple solution run configurations that can occur which is not addressed by this fix.

Fixed hang when discovering unit tests

Opening a solution containing a .NET Core test project would sometimes result in the IDE hanging when discovering tests. On running kill -QUIT pid the IDE log would show a background thread and the UI thread both awaiting test discovery to complete:

var discoveredTests = await VsTestDiscoveryAdapter.Instance.DiscoverTestsAsync (Project);

VsTestProjectTestSuite/<OnCreateTests>d__12.MoveNext
in MonoDevelop.UnitTesting.VsTest/VsTestProjectTestSuite.cs:95

Allow loading of SDK style projects without a main PropertyGroup

On loading an SDK style project that did not have a main PropertyGroup Visual Studio for Mac would show the error message “Error while trying to load project: Object reference not set to an instance of an object”.

A project may define MSBuild properties in a Directory.Build.props file instead of having this in the main project file. It is then possible for the main project file to have no main property group.

Directory.Build.props:

<Project>
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.1</TargetFramework>
  </PropertyGroup>
</Project>

MainProject.csproj:

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

Visual Studio for Mac now handles the missing main PropertyGroup.

Fixed TargetFramework not being updated in project

Changing a .NET Core project’s target framework to a different version in Project Options, then re-opening Project Options and changing the target framework version back again, would result in the target framework not being updated in the project. The problem was the original target framework the project had on opening was cached and the changing back to the same target framework version was being ignored resulting in the project file not being updated.

Fixed .xaml.cs code completion in new Xamarin.Forms .NET Standard project

Creating a new Xamarin.Forms .NET Standard project, then modifing the .xaml to add new named UI items, would result in no code completion in the .xaml.cs file for these new items until the solution was closed and re-opened. The problem was that the .xaml and .xaml.cs files were being removed from the file information held in memory when the project was re-evaluated. On re-evaluation, after the NuGet restore is first run for the project, the old MSBuild items for the .xaml and .xaml.cs file have the wrong metadata, so they need to be removed, whilst new MSBuild items with the updated metadata need to be added. The removal was done after adding the updated files and, since they had the same filename, the new updated files were being removed. The removal is now done before adding the updated files to avoid the files being removed incorrectly.

Fixed default build action for new HTML file

Adding a new .html file to the wwwroot folder of an ASP.NET Core project would add the file as a None item instead of a Content item. This would result in the .html file not being used when publishing the project. When ‘dotnet publish’ was used the publish directory would not contain the .html file.

ASP.NET Core projects have different build actions for files based on where they are added. A .html file in the root directory would be a None item by default, whilst a .html file in the wwwroot directory would be a Content item by default. To fix this the default build action for a file is determined by the file wildcard information available from the .NET Core SDK.

Fixed SDK version not being parsed from Sdk attribute

The Sdk attribute would have its forward slash / replaced with a backslash \ which meant Visual Studio for Mac was creating an SdkReference with the wrong name, for example:

Microsoft.NET.Sdk.Razor\2.1.0-preview2-final

Instead of having Microsoft.NET.Sdk.Razor as the name with the version being separate.

Fixed null reference on opening .NET Core project with SDK version

Opening a SDK style project that used a Sdk attribute with a version would show an error message “Error while trying to load project: Object reference not set to an instance of an object”. The problem was that an SdkResolver can return null from its Resolve method. These null results were added to a list and then an attempt was made to log the result warnings on a null result.

<Project Sdk="Microsoft.NET.Sdk.Razor/2.1.0-preview2-final">

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.

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.

.NET Core Support in Visual Studio for Mac 7.5

New Features

  • .NET Core 2.1 SDK support
    • .NET Core 2.1 SDK project templates
    • HTTPS development certificate support
    • .NET Core global tools added to PATH on startup
  • .NET Core location can now be configured
  • Xamarin.Forms project templates now use .NET Standard projects
  • Performance improvements when using projects with many files
  • .NET Core templating engine has been updated
  • Improved support for Xamarin.Forms
  • Item templates are now supported with the .NET Core templating engine

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

.NET Core 2.1 SDK support

Visual Studio for Mac 7.5 includes support for the .NET Core 2.1 SDK which is currently available as a release candidate. The following sections will look into the support provided by Visual Studio for Mac 7.5 for the .NET Core 2.1 SDK.

.NET Core 2.1 SDK project templates

If .NET Core 2.1.300 SDK is installed then the .NET Core 2.1 project templates will be available in the New Project dialog.

New Project dialog - .NET Core 2.1 target framework option

The .NET Core 2.1 project templates are not included with Visual Studio for Mac and will be searched for in the 2.1.300 SDK templates directory.

/usr/local/share/dotnet/sdk/2.1.300-rc1-008673/Templates/

The project templates for .NET Core 2.0 and 1.1 are currently still being shipped with Visual Studio for Mac.

HTTPS development certificate support

ASP.NET Core 2.1 projects use HTTPS by default. In order to be able to run ASP.NET Core 2.1 projects with HTTPS a development certificate needs to be installed. Visual Studio for Mac will detect if the development certificate is missing and offer to install it when you run an ASP.NET Core 2.1 project that uses HTTPS.

HTTPS development certificate not installed message

Visual Studio for Mac will use the dotnet dev-certs tool to check if the HTTPS development certificate is installed and trusted.

dotnet dev-certs https --trust --check

Installing the HTTPS certificate requires administrator privileges so you may be prompted for your username and password after clicking the Yes button. Currently the prompt for credentials shows mono-sgen64 wants to make changes. In the future this will show a custom message indicating that the credentials are required to install the HTTPS development certificate.

Mono sgen administrator dialog prompt

After entering your credentials the following command is run as administrator.

dotnet dev-certs https --trust

After the certificate is installed the ASP.NET Core 2.1 project will be opened in the default browser using HTTPS.

ASP.NET Core 2.1 project open in browser using HTTPS

Running dotnet dev-certs https —trust to install and trust the certificate needs to be done with administrator privileges with the user id 0. To do this Visual Studio for Mac does the following:

  1. Launches a separate custom console app.
  2. The console app uses the AuthorizationExecuteWithPrivileges Mac API provided by Xamarin.Mac to launch itself as again as administrator. It is not possible to run dotnet as administrator initially since it requires the user id to be set to 0, which is what happens when you use sudo dotnet, and this can only be done when running with administrator privileges. So the console app is launched again but this time with administrator privileges.
  3. The console app, now being run with administrator privileges, will use setuid to set the current user id to 0.
  4. The console app then runs dotnet dev-certs https —trust which will install and trust the HTTPS development certificate.

The dotnet dev-certs https —trust command will add two localhost certificates. You can see these by opening the Keychain Access application and searching for localhost.

localhost certificate created by dotnet dev-certs in Keychain Access application

If the HTTPS development certificate is found to be valid and trusted then this will be remembered for the current Visual Studio for Mac session and a check will not be run again during the current session.

.NET Core global tools added to path on startup

The .NET Core SDK 2.1 supports installing global tools. These tools are .NET Core console apps that are available as NuGet packages and can be installed and used from the command line. To be able to use these tools with the dotnet command line the ~/.dotnet/tools directory needs to be added to the PATH environment variable. The path to these global tools is now added to Visual Studio’s PATH environment variable when it starts.

Prompt to install .NET Core 2.1 SDK if not installed

If a .NET Core 2.1 project is opened and .NET Core 2.1.300 SDK is not installed then a dialog will be shown allowing the SDK to be downloaded. The project in the Solution window will show an error icon indicating that the .NET Core 2.1 SDK is not installed.

Launching a browser when running an ASP.NET Core 2.1 project

The .NET Core SDK 2.1 project templates for ASP.NET Core specify the https and http urls in the launchSettings.json file by using the applicationUrl property.

    "MyAspNetCore21Project": {
        "commandName": "Project",
        "launchBrowser": true,
        "applicationUrl": "https://localhost:5001;http://localhost:5000",
        "environmentVariables": {
            "ASPNETCORE_ENVIRONMENT": "Development"
        }
    }

With earlier .NET Core 2.1 preview SDKs this was defined in the ASPNETCORE_URLS environment variable. The full applicationUrl property was used unmodified when running the ASP.NET Core 2.1 project and resulted in an invalid url being used causing the AspNetCoreExecutionHandler to log a warning and not opening the browser. Now the first url in the applicationUrl is used if there are multiple urls.

Support ASPNETCORE_URLS when launching the browser

If the launchSettings.json does not define an applicationUrl then Visual Studio for Mac will fallback to checking the environment variable defined for ASPNETCORE_URLS in the launchSettings.json file and will use the first url found there. This url will be used to launch the browser when running the project.

An example launchSettings.json that was used in the .NET Core 2.1 preview SDKs is shown below.

"MyProject": {
  "commandName": "Project",
  "launchBrowser": true,
  "environmentVariables": {
    "ASPNETCORE_ENVIRONMENT": "Development",
    "ASPNETCORE_URLS": "https://localhost:5001;http://localhost:5000"
  }
}

Compared with the .NET Core SDK 2.0.

"MyProject": {
  "commandName": "Project",
  "launchBrowser": true,
  "environmentVariables": {
    "ASPNETCORE_ENVIRONMENT": "Development"
  },
  "applicationUrl": "http://localhost:5000/"
}

Allow .NET Core location to be configured

In Preferences there is now a Projects – SDK Locations – .NET Core section that can be used to configure the location of the .NET Core command line tool (dotnet).

.NET Core location configured in preferneces

This can be used to configure Visual Studio for Mac to use a .NET Core SDK that is not installed in the default location. After this is changed the MSBuild engine hosts are recycled and all .NET Core projects are re-evaluated to ensure the new locations of any MSBuild targets are used.

If the location is invalid, or no runtimes or SDKs can be found at the configured location, a Not found error will be displayed.

Invalid .NET Core location path specified in preferences

Xamarin.Forms Project Templates now include .NET Standard projects

The Xamarin.Forms project templates, Blank Forms App and Forms App, will now create a .NET Standard 2.0 project instead of a Portable Class Library (PCL) project if .NET Standard is selected in the New Project dialog.

New Project dialog - Blank Forms - .NET Standard option

The Xamarin.Forms Class Library project template now creates a .NET Standard 2.0 project instead of a Portable Class Library project.

New Project dialog - Xamarin.Forms Class Library project

Prevent .xaml.cs file from being renamed in a .NET Core project

The Xamarin.Forms NuGet package has an MSBuild .targets file that is imported after the project items are defined. This .targets file overrides the DependentUpon property for all .xaml.cs files. This means that renaming the .xaml.cs file to be different to the .xaml file is not supported. To prevent this the Rename menu is now disabled in the Solution window for .xaml.cs files if they depend on a .xaml file.

Exclude None build action for XAML files in .NET Core projects

Recent versions of Xamarin.Forms NuGet packages exclude all .xaml files from the default None file wildcard defined by the .NET Core SDK. This exclusion is done in a .targets file which is applied after the items in the project file have been added. This means that a .NET Standard project should not use None items for .xaml files since they will be removed. To avoid this problem the None build action is excluded from the list of build actions for .xaml files. This list of build actions is available when right clicking the file in the Solution window and in the Properties window when the file is selected.

Dependent files now renamed on renaming parent file in the Solution window

When a file is renamed in the Solution window the dependent files will also be renamed if they start with the same name as the parent file. This avoids problems with XAML files since a different name for the .xaml file and the associated .xaml.cs file is not supported.

Improve project load times for projects with many files

Opening a .NET Core project that contained many files that were not excluded, such as a .NET Core console project that has a node_modules directory, could take a long time to load.

Some performance improvements have been made to speed up the loading of .NET Core projects. For a .NET Core console project that had a node_modules directory containing around 17000 files the initial project load time which was taking around 70-80 seconds and now it takes around 20 seconds. Visual Studio 2017 on Windows takes around 15-20 seconds to load the same project before it is visible in the Solution Explorer window.

The performance improvements include:

  1. Adding a faster project item lookup used when finding an existing project item on loading the project.
  2. Updating the existing project items is now faster avoiding iterating over the existing items.
  3. Evaluating MSBuild items is now only done when evaluating properties. Previously this was done when evaluating project configurations and run configurations. This would result in files and directories being searched multiple times when looking wildcard matches on loading the project. Now the files and directories are searched once during the initial project load.

.NET Core templating engine updated

Updated the .NET Core templating to version 1.0.0-beta3-20171117-314. This new version of the .NET Core templating engine fixes the following problems:

  1. Templates that use files with @ character in their names being generated with the @ symbol encoded.
  2. Templates that use the Guid macro and did not specify a format would cause the template generation to fail. An exception was thrown since the format was not defined. Now if the format is not defined the default format is used.

Report template creation failures when using the .NET Core templating engine

To help diagnose problems with project and item templates that use the .NET Core templating engine more detailed information about the failure is now logged in the IDE log.

Support item templates with the new templating engine

Item templates that use the .NET Core templating engine can be defined through a new extension point.

<Extension path="/MonoDevelop/Ide/ItemTemplates">
        <Template
                id="Azure.Function.CSharp.BlobTrigger"
                _overrideName="Blob Trigger"
                path="Templates/Azure.Functions.Templates.nupkg" />
</Extension>

Item templates are not currently supported in the New File dialog however there is an API that can be used by extensions to create files from these templates. This is currently used when adding a new Azure Function to a project.

Bug Fixes

Missing child package dependencies in Solution window

After creating a new ASP.NET Core project sometimes the package dependencies shown in the Solution window under the SDK folder and the NuGet folder could not be expanded to view the child dependencies.

The problem was that if the call to get the package dependencies using MSBuild was cancelled this would result an empty list of depenencies being cached. Since no package dependencies were returned the Solution window would fallback to showing the package dependencies that were listed in the project and a default top level SDK package dependency.

MSBuild wildcards being expanded on saving a project

Saving a project with a file wildcard that had a Link with MSBuild item metadata, as shown below, would result in the wildcard being removed and replaced with MSBuild items for each file included by the wildcard.

<Compile Include="**\*.cs" Exclude="obj\**">
  <Link>%(RecursiveDir)%(Filename).cs</Link>
</Compile>

The problem was that the evaluated Link property value was being compared with the unevaluated value, which did not match, resulting in the wildcard being replaced with individual MSBuild items for each file. Now if the property value contains a % character a comparison is made against the evaluated value when checking if the project item has changed.

MSBuild items added for wildcards with link metadata on saving project

A project containing the following MSBuild file wildcards would have extra MSBuild items added when the project file was saved.

<ItemGroup>
  <Compile Include="..\**\*.cs">
    <Link>%(RecursiveDir)%(Filename)%(Extension)</Link>
  </Compile>
</ItemGroup>

On saving the project Compile update items would be added for each file included by the file wildcard.

<ItemGroup>
  <Compile Update="..\Test\Class1.cs">
    <Link>Class1.cs</Link>
  </Compile>
</ItemGroup>

This problem is similar to the previous problem where the evaluated Link value was being compared with the unevaluated value, which did not match, resulting MSBuild update items being added to the project when it was saved. Now if the property value contains a % character a comparison is made against the evaluated value when checking if the project item has changed.

TargetFramework changed on saving project

Adding a file to an SDK style project that targeted Tizen 4.0 would result in the TargetFramework changing from tizen40 to tizen4.0. Now the original framework identifier name is not modified and if the version of the framework changes then the version will be dotted or contain only numbers based on the format that was originally used in the project file.

ASP.NET Core file templates modifying project file

Adding a new .cshtml file from a file template to an ASP.NET Core project would modify the project file when it should not have been modified. The problem was the files were added as None items whilst .cshtml are Content items. The project file would contain the following after adding a new cshtml file from a template:

<ItemGroup>
  <Content Remove="Views\Index.cshtml" />
</ItemGroup>
<ItemGroup>
  <None Include="Views\Index.cshtml" />
</ItemGroup>

Another problem was that the Razor Page with view model file template specifies a DependentUpon property so this was added to the project file. This would result in the .cshtml and .cs files being nested whilst the other .cshtml and .cs files created with the initial ASP.NET Core project template were not nested. The project file would include the following:

<ItemGroup>
  <Compile Update="Views\Index.cshtml.cs">
    <DependentUpon>Index.cshtml</DependentUpon>
  </Compile>
</ItemGroup>

The .NET Core SDK does not indicate that .cshtml and .cs files are dependent on each other so they are not currently nested in the Solution window. New .cshtml files created from these updated file templates will now not be nested in Solution window.

XAML files not nested after editing project file in editor

Adding a new content page with xaml to a .NET Standard project, then excluding the files from the project, but not deleting it, then editing the project file and commenting out the MSBuild remove items, would then result in the xaml files not being nested in the Solution window. The problem was that the MSBuild update item for the .xaml.cs file, defined by the Xamarin.Forms default msbuild items, was being removed from the MSBuild project in memory. This MSBuild update item had the DependsOn property defined so this information was lost on reloading the project. Now a check is to made to ensure only update items that exist in the original project file are removed.

MSBuild item added for XAML file copied to a .NET Standard project

When copying a .xaml file from a Portable Class Library project to a .NET Standard project an MSBuild include item for the file would be added if the .xaml file did not have the default metadata properties defined by Xamarin.Forms. Now .NET Core projects opt-in to supporting items not being excluded if they are missing MSBuild item metadata which prevents an MSBuild include item added for the .xaml file.

Duplicate XAML file build error when copying file to a .NET Standard project

Copying a .xaml file from a Portable Class Library project to a .NET Standard project would result an MSBuild item for the .xaml file to the project causing it to not build due to a duplicate .xaml file.

Now when a xaml file is copied into a .NET Standard project, and it is missing properties that are included in by an update wildcard, an MSBuild item will not be added to the project.

MSBuild remove item not added for .xaml.cs file

With a .NET Core project, containing a single .xaml file and a dependent .xaml.cs file, removing but not deleting the .xaml file from the Solution window would not add an MSBuild remove item for the .xaml.cs file even though it was removed from the Solution window.

The problem was that the Xamarin.Forms NuGet package includes a Compile update item and only this was being considered when saving the project file. The default file wildcard, that includes all .cs files, provided by the .NET Core SDK was not considered. Only the last MSBuild item associated with the .xaml.cs file was being considered. If there was another .cs file in the project then the MSBuild remove item was added correctly. To avoid this all MSBuild items associated with a project item are now considered.

MSBuild remove item not removed on adding XAML file to project

When an .xaml file was removed but not deleted, and Xamarin.Forms 2.5 used, which has default MSBuild items defined, on adding the .xaml file back again to the project the EmbeddedResource remove item was not removed from the project.

The problem was that the .xaml file was being added as a None item since by default there is no build action specified for .xaml files.

Another problem was that the MSBuild remove items, defined by Xamarin.Forms that remove all .xaml files from the default None included by the .NET Core SDK, were being ignored since the file wildcards were not found.

Also an msbuild item is no longer added for an existing xaml file when it is added to the project. The Xamarin.Forms default msbuild items for .xaml files have extra metadata which were not being added to the file when it was added to the project from the file system.

Update item added on renaming xaml.cs file

When the .xaml and .xaml.cs file were renamed at the same time an MSBuild update item was added for the .xaml.cs file even though the Xamarin Forms NuGet package has a default MSBuild item that was the same as the generated MSBuild update item.

Argument null exception logged on opening .NET Core project

Opening a .NET Core project would sometimes log an unhandled ArgumentNullException. A file created event was sometimes raised before the project had finished loading and could result in a null set of items being used when checking if the new file should be added to the project. This is now handled. The files being created on project load are typically in the obj folder and would be ignored by the default file wildcards.

An unhandled exception has occured. Terminating Visual Studio? False
System.ArgumentNullException: Value cannot be null.
Parameter name: source
  at System.Linq.Enumerable.Where[TSource]
  in corefx/src/System.Linq/src/System/Linq/Where.cs:42
  at MonoDevelop.Projects.Project.OnFileCreatedExternally
in src/core/MonoDevelop.Core/MonoDevelop.Projects/Project.cs:4041