| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Handle other MSBuild targets failing when calling the MSBuild target
ResolveFrameworkReferences by setting ContinueOnError to
ErrorAndContinue. Previously if there was any other failure the
design time build would stop even though the main msbuild target
may work and return some references.
|
|
|
|
The Frameworks folder for .NET Core 3.0 and .NET Standard 2.1
projects would show an update count label if the project had package
updates. Framework references cannot be updated in the IDE, and also
are not typically defined in the project itself, so the update count
should not be shown.
Fixes VSTS #980887 - Frameworks node under dependencies has a message
about updates next to it
|
|
|
|
Previously multi-target framework projects would show the framework
nodes under Dependencies - NuGet and Dependencies - SDK. Now the
framework nows appear directly under the Dependencies folder. Note
that currently the Assemblies and Projects folders do not support
multi-target frameworks and just show all assemblies and projects
referenced directly in the project ignoring any conditions.
|
|
Refactored the dependency node tests so they test the node builders
themselves. Previously the data object classes were being tested.
This is in preparation for new tests for multi-target projects.
|
|
Move SDK style project specific code out of the .NET Core addin into
MonoDevelop.Core. NuGet specific code has been moved into the NuGet
addin. The DotNetCoreProjectExtension was supporting all SDK style
projects now it supports .NET Core and .NET Standard projects that
use the .NET Core SDK.
Fixes VSTS #830544 - Split out SDK style project support from the
.NET Core addin
|
|
Add new Template Tag for *.Web.Spa.ProjectTemplates and corresponding unit test
Add new unit test cases for Asp.Net Core for all platforms - added class to check for Node dependency so unit test can be disabled if Node isn't installed.
|
|
|
|
These tests all output into the same directory, they
should not all be local copying the same references
into it.
|
|
What's with all these direct refs to the packages
folder in projects that don't even have a packages.config?
|
|
[PublishToFolder] Sorts out default destination folder
|
|
[netcore30] Implements netcoreapp30
|
|
|
|
With two sdk projects, Lib1 and Lib2, where Lib1 has its output
assembly signed, then in Lib2 any use of any types from Lib1 would
show errors in the text editor after the solution was built. Errors
similar to:
The type 'Class1' exists in both 'Lib1, Version=0.0.0.0, Culture=Neutral, PublicKeyToken='
and 'Lib2, Version=1.0.0.0, Culture=neutral, PublicKeyToken='
This was because the generated AssemblyInfo.cs file which exists in
the obj directory was available to the type system so there was a
mismatch in the assembly information from the assembly .dll on disk
and the project information which resulted in Roslyn creating two
references. The generated AssemblyInfo.cs file is now returned to
the type system when it calls Project.GetSourceFilesAsync.
Fixes VSTS #753821 - Inline type resolution errors when project
references are public signed
|
|
- Adds new templates
- Adds support for .net standard 2.1
- Adds support tests
- Adds support for global.json
|
|
Update NuGet to version 4.9.0.5658
Fixes VSTS #743959 - Bump VSMac to NuGet 4.8 or later
|
|
This was causing none of the NuGet addin tests to be run. In the
unit test output from running vstool would show an error about
failing to load NuGet.Versioning since the .NET Core tests were
copying the old assembly into the build/tests directory:
Could not load file or assembly 'NuGet.Versioning, Version=4.7.0.5,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its
dependencies.
|
|
[DotNetCore] Display NuGet package dependency diagnostics
|
|
And make .NET Core tests use it, for creating projects from templates
and building them.
|
|
Added tests for the nodes generated for the Dependencies folder. Tests
the for the nodes added for the SDK and NuGet folders have been added.
|
|
This disables searching in registry, AssemblyFoldersEx, etc.
|
|
Remove redundant information, and make more information
redundant by setting good defaults in the MD props.
This lays some groundwork for the PackageConfig migration
and eventually SDK-style project format migration.
|
|
|
|
Instead of including the project templates with the IDE if .NET Core
SDK 2.1.300 is installed then the templates will be looked for in
the directory:
/usr/local/share/dotnet/sdk/2.1.300-preview1-008174/Templates/
The latest version of the .NET Core 2.1 SDK will be used if multiple
are installed.
The .NET Core 2.0 and 1.1 project templates are still included
with the DotNetCore addin.
|
|
Added project templates that are available if .NET Core 2.1.300 SDK
is installed. Using version 1.0.1-beta3-20180215-1392068
Added tests for project template wizard and supported target
frameworks based on the installed sdks and runtimes.
|
|
After commit 7b6587aaa8dcc796b70ea66f79d5237fdcaea3b0 the template
tests were failing with an error:
DotNetCoreProjectTemplateTests
System.Exception : Toolkit could not be loaded
----> System.IO.FileNotFoundException : Could not load file or
assembly 'PresentationFramework, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
at Xwt.Toolkit.LoadBackend (System.String type, System.Boolean isGuest, System.Boolean throwIfFails) [0x00081] in monodevelop/main/external/xwt/Xwt/Xwt/Toolkit.cs:295
at Xwt.Toolkit.Load (Xwt.ToolkitType type) [0x00049] in monodevelop/main/external/xwt/Xwt/Xwt/Toolkit.cs:235
at MonoDevelop.MacIntegration.MacPlatformService.LoadNativeToolkit () [0x00028] in monodevelop/main/src/addins/MacPlatform/MacPlatform.cs:144
at MonoDevelop.Ide.DesktopService.get_NativeToolkit () [0x0000d] in monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide/DesktopService.cs:85
at MonoDevelop.Ide.DesktopService.Initialize () [0x000a5] in monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide/DesktopService.cs:73
at MonoDevelop.DotNetCore.Tests.DotNetCoreProjectTemplateTests.SetUp () [0x0004b] in monodevelop/main/src/addins/MonoDevelop.DotNetCore/
The test setup has now been re-arranged to avoid this exception.
|
|
The project templates are created, restored and built in a set of
tests. The tests detect what .NET Core SDKs are available and only
create and build those templates that would be available.
The ASP.NET Core project templates are not yet being built.
|
|
Fixed bug #58271 - Handle .NET Core 2.0 SDK not being installed when
opening a .NET Core 2.0 project
https://bugzilla.xamarin.com/show_bug.cgi?id=58271
If a .NET Core 2.0 or .NET Standard 2.0 project is opened and .NET Core
2.0 SDK is not installed then a dialog is shown allowing the user to
download and install it. The project in the Solution window will show
an error icon with the same information about .NET Core 2.0 not being
installed. Currently the download link goes to the .NET Core 2.0
preview page - https://www.microsoft.com/net/core/preview#macos - the
url is shorted and can be redirected later without changing the code.
|
|
The sdk version parsing is now done with the DotNetCoreVersion class.
|
|
If the latest version of the .NET Core runtime installed is a 2.0
pre-release then the default Microsoft.NETCore.App version, which
will be 2.0, is modified before it is written to the
project.assets.json file so it is the pre-release version. This allows
the NuGet restore to work. This workaround should be removed when
.NET Core 2.0 stable is released.
|
|
|
|
If the .NET Core SDK is installed but is too old or is missing the
new Sdk MSBuild targets a different error message is displayed when
opening the project, in the error tooltip in the Solution window,
and when building the project. This error message indicates that the
SDK is unsupported and a newer version should be installed.
Previously the error message would just indicate that the .NET Core
SDK was not installed which is misleading. If there is no Sdk
directory then the error message the original error message will
still be displayed.
|
|
|
|
|
|
Ensure that Sdk style projects use the Version attribute when a
NuGet package reference is added to the project.
|
|
Roslyn 2.x needs this so we have to do it for MonoDevelop.Core
and every assembly that references it.
|
|
|
|
Extract out reading/writing MSBuild project code from the project
extension to a separate class to make it easier to write unit tests.
|
|
When saving a .NET Core project a ProjectGuid property was added
and the DefaultTargets was set to Build. These are not in a
.NET Core project by default so they are not added when a project
is saved.
The DotNetCoreProjectExtension is now only enabled for projects
that contain a TargetFramework or TargetFrameworks property.
|
|
|
