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.
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.
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.
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.
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:
- Launches a separate custom console app.
- 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.
- The console app, now being run with administrator privileges, will use setuid to set the
current user id to 0.
- 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.
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).
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.
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.
The Xamarin.Forms Class Library project template now creates a .NET Standard 2.0 project instead of
a Portable 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:
- Adding a faster project item lookup used when finding an existing
project item on loading the project.
- Updating the existing project items is now faster avoiding iterating
over the existing items.
- 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:
- Templates that use files with @ character in their names being generated with the
@ symbol encoded.
- 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
