Fsharp api v3 #93
Fsharp api v3 #93
Conversation
and update MSBuildEvaluationContext.cs accordingly
IntrinsicFunctions are now loaded at runtime from the current version
of Microsoft.Build.dll, as identified by the active runtime.
The old IntrinsicFunctions test is no longer meaningful and has been removed
This fixes Issue dotdevelop#75 so that all project properties are now evaluated correctly.
….4 or greater
or for DotNetCore (runtime) versions 3.x or greater (ie includes .net5.0+)
previously only netstandard2.0 was supported for mono 5.2 AND netcore3.0 installed
…DotnetCore.addin.xml and MonoDevelop.ASpNetCore.addin.xml to allow net5.0 and net6.0 projects to be created These template updates were overlooked in the menu limit changes in PR#76
1 - use 'git submodule deinit main/external/nuget-binary' to remove submodule from .git/config 2 - use 'git rm main/external/nuget-binary' to remove submodule from work tree
This commit updates all NuGet dll binaries to release-5.8 ready to support .net5.0 projects Note that the main/external/nuget-binary folder (and all its contents) are no longer a submodule in the DotDevelop repo, but just a normal folder under the control of the main DotDevelop git repo.
NuGet.Client release-5.8.x (and later) is able to handle .net5.0 projects To allow DotDevelop to build with this release of Nuget a number of small changes are needed to the DotDevelop PackageManagement files because the interface to NuGet changed after release-5.4.0 (which DotDevelop currently builds with) The commits in this 'net5ff_nuget' branch also remove 'nuget-binary' from being an external submodule within the DotDevelop repo, since 'nuget-binary' has not been updated since MonoDevelop was archived. Instead, the folder with the NuGet dlls is now a simple folder under DotDevelop's version control. This simplifies updating NuGet to later releases, which will be required to handle .net6.0+ frameworks. With these commits, net5.0 projects can be created, saved, etc, which effectively fixes Issue dotdevelop#79 (project.assets.json gets a wrong TargetFrameworkMoniker for net5 and higher)
Use hwt-dev as development branch Add first PR to dotdevelop
Add next PR to hwt-dev
Add final PR to hwt-dev
Incorporate changes in PR#81 from @gluckez to fix conflicts
|
Try to fix intermittent CI failures by removing last nuget/api/v2 URLs in fsharpbinding repo. |
|
@lytico, @knuxbbs - I'd be grateful if you could review this series of PRs (#77, #87, #90, #91, #93) with a view to merging - perhaps into a new Taken together, these changes allow net5.0/net6.0 projects to be created, built and run, and would allow some more extensive testing of DotDevelop to be started - hopefully by some new contributors as well! |
|
@hwthomas @lytico I think having a develop branch is a good idea, as well as using feature branches for developers working on seperate features before they go in testing. There is already a develop branch, but the policies need to be updated to set this as the main working branch. Could you do that? it is already up to date with main. |
|
@hwthomas there are several benefits. You could set up the policies for only allowing to merge branches into develop, so we're sure that the main release branch remains untouched until everything is tested properly. You could set up a CICD pipeline for a pre-release for others to test before making a new release. You can use wildcards to use the latest nuget packages of the dependencies on develop, before fixing them on the main branch, and the pre-release or nightly pipelines would identify issues with updated api's. this way we know we're always using the latest compatible versions. but I'll leave all that to the maintainers xD |
This fixes failures when evaluating project properties See Issue dotdevelop#93
This fixes failures when reserved property $(MSBuildVersion) cannot be found
See Issue dotdevelop#93
…nstalled
This fixes failures when reserved property $(MSBuildVersion) cannot be found
See Issue dotdevelop dotdevelop#93
No description provided.