Update checks so that netstandard2.0/2.1 projects are supported and will build #87

hwthomas · 2022-09-05T10:35:48Z

The checks for the support of netstandard projects (2.0 and 2.1) were outdated

This PR updates those checks for the current versions of Mono and dotnet-sdks

NB This PR requires PR #77 as well so I rebased my branch ns2.1_fix to the tip of branch fix_Issue_75
however git seems to have combined the commits from both these branches (which is correct, of course) but I was expecting them to be done as 2 separate PRs. One day I might get the hang of git!

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

gluckez · 2022-09-05T11:24:07Z

main/src/addins/MonoDevelop.DotNetCore/MonoDevelop.DotNetCore/DotNetCoreVersion.cs

@@ -34,12 +34,14 @@ namespace MonoDevelop.DotNetCore
 {
 	class DotNetCoreVersion : IEquatable<DotNetCoreVersion>, IComparable, IComparable<DotNetCoreVersion>


wouldn't it be more interesting to keep track of which net standard versions are supported by the .net sdks? this way we don't need to compare the sdk's version number, because not every .net sdk supports every net standard version.

looking back, I really don't know why I changed this version from (2, 1, 602) to (2, 1, 30)!. The matrix of supported versions etc has never been a strong point for me. I was just going for the minimum changes to the existing code (and way of doing things) that fixed the netstandard issue. @gluckez by all means update if you have better understanding

@hwthomas If it helps, I will certainly not stop you from merging it ;) And I'll have a look tonight to see if the knowledge about the supported frameworks and netstandard versions can be centralized.

@gluckez Many thanks - I appreciate that.
So far, I'm afraid I've been focussing on getting net5ff and netstandard projects working, and not being too concerned about improving the state of the codebase!

@hwthomas I guess that's why I'm here xD I'm not too familiar with the codebase yet, but if I can make small improvements while learning, I'll give it a go.

knocte · 2022-10-29T05:43:26Z

3 questions:

So this fixes netstandard2.0/2.1 projects don't build #86 ?
Why are there conflicts?
Why is CI failing?

hwthomas · 2022-10-29T11:02:44Z

@knocte 3 (provisional) answers

I've done some simple testing with a netcoreapp3.1 Main program and a netstandard2.0 library, which worked OK. I've also built and debugged the GtkSharpTest TestApp from ( https://github.com/dotdevelop/xwt ) which is a more realistic netcoreapp3.1/netstandard2.0 application, but more real-life feedback would be appreciated.
This pending ns2.1_fix PR has recently been 'leap-frogged' by PR use funcloader for cairo library in cairo extensions #81, which has resulted in a merge conflict that wasn't there originally. It's a very simple fix, which just needs ns2.1_fix rebasing to the new HEAD of main, but I've got myself in a mess in the past with things like this, so I was leaving it for now (!)
The CI fails with DOWNLOADNUPKG : Ssl error : 1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED [/__w/dotdevelop/dotdevelop/main/src/addins/MonoDevelop.UnitTesting/MonoDevelop.UnitTesting.csproj] which has been a problem for a year or more. Re-running the workflow usually succeeds, but I don't have the knowledge/experience to know what would fix it properly - and I can only re-run the workflow on my own fork. The 3 combined PRs (Update MonoDevelop.PackageManagement files and NuGet dlls to release-5.8 #91) pass the CI run OK in my fork.

Hope this helps, and thanks again for the feedback.

gluckez · 2022-10-29T12:42:56Z

@hwthomas If the merge conflicts are caused by my pr, maybe there's something I can do to help? I don't have write access here, but I think the issue may be in the changes in MonoDevelop.Core.Tests.csproj. I think a local merge could help identify the conflicts, but could create conflicts in your other pr's, which also include these changes.

hwthomas · 2022-10-29T14:11:10Z

@gluckez Thanks for your offer to help. The conflict is indeed in MonoDevelop.Core.Tests.csproj, where after your PR merge, I need to remove the line

<Compile Include="MonoDevelop.Projects\IntrinsicFunctionsTests.cs" /> but keep your
<Compile Include="MonoDevelop.Utilities\TEST.LibraryTools.cs" />

If I were to rebase branch fix_Issue_75 (which should also rebase all my other subsequent commits) from its current origin of 068675d to the latest main of 0bab871 I think this should fix the conflict as well.

However, I'm not completely sure! And I'm not sure if doing a rebase on my local branch fix_Issue_75 and pushing this upstream is all that needs to be done. I'm particularly wary of changing things that I've already 'published'.

Edit: Or perhaps it's simplest just to deal with this conflict now, and handle any others as they arise?

Any thoughts?

gluckez · 2022-10-29T17:06:58Z

@hwthomas I'm pretty sure merging main into net5ff_nuget and completing only that pr will do the trick. that branch is based on the branches you used for the other pr's, so there's no need to merge them all sequentially. the last branch includes all commits from previous pr's. If you still want to merge sequentially, then you'll have to rebase fix_issue_75 first, then sequentially rebase the other branches as well because it would cause new conflicts in the other pr's.
EDIT: the line that's causing the conflict, is really not that important. It's just a basic unit test to make sure the libraries were still loaded properly, but it can be removed I guess.

hwthomas · 2022-10-30T10:37:40Z

@gluckez Many thanks for that advice - I'd been looking more at merging my commits into main and missed the obvious alternative of merging main into my latest branch. I'll give it a go.

hwthomas · 2022-10-30T17:27:19Z

@gluckez That seems to have worked! I've merged the latest dotdevelop/main into my net5ff_nuget and in my fork CI run 161 (https://github.com/hwthomas/dotdevelop/actions/runs/3356254896) passes OK. Nothing here seems to have changed though, so I'll have to rely on @lytico making sense of it all.

gluckez · 2022-10-30T19:50:16Z

@hwthomas that's because net5ff_nuget includes the commits from this branch, but not the other way around. Your last pr was in fact updated and conflicts are resolved there. If you want to do the same here, you should also merge main into this branch. but it's not needed because all commits from all pr's will be merged if you merge #91 . it does look like the CI failed on that last pr, but that's again due to the certificate errors, I bet it'll run fine if you trigger it again.

hwthomas · 2022-11-01T14:14:46Z

@gluckez thanks again - I've viewed the branches with git log --graph and it all looks much clearer. I'll leave things as they are now and deal with any queries if the PRs eventually get merged.

@gluckez

Incorporate changes in PR#81 from @gluckez to fix conflicts

hwthomas · 2023-01-16T16:32:42Z

Merged as part of PR #96

knocte · 2023-01-17T04:35:37Z

The CI fails with DOWNLOADNUPKG : Ssl error : 1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED (...) Re-running the workflow usually succeeds,

If this above was not actioned, I would simply recommend retrying in CI about 3 times, as a workaround. Later when dotnet restore can be used, the retry workaround can be removed.

knocte · 2023-01-17T04:37:42Z

If this above was not actioned, I would simply recommend retrying in CI about 3 times, as a workaround. Later when dotnet restore can be used, the retry workaround can be removed.

Oops, I've realised I already suggested this, here: #90 (comment)

hwthomas added 2 commits September 4, 2022 17:34

Update checks so .NETStandard2.0/2.1 is supported for Mono versions 6…

2103163

….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

gluckez reviewed Sep 5, 2022

View reviewed changes

hwthomas mentioned this pull request Sep 5, 2022

dotnetcore / netstandard projects not working if .net 5.0 (dotnet 5) is installed #40

Closed

hwthomas mentioned this pull request Oct 13, 2022

Update MonoDevelop.PackageManagement files and NuGet dlls to release-5.8 #91

Closed

Merge remote-tracking branch 'upstream/main' into ns2.1_fix

33700fa

Incorporate changes in PR#81 from @gluckez to fix conflicts

hwthomas mentioned this pull request Nov 23, 2022

Fsharp api v3 #93

Merged

hwthomas closed this Jan 16, 2023

hwthomas deleted the ns2.1_fix branch February 24, 2023 16:33

		@@ -34,12 +34,14 @@ namespace MonoDevelop.DotNetCore
		{
		class DotNetCoreVersion : IEquatable<DotNetCoreVersion>, IComparable, IComparable<DotNetCoreVersion>

Update checks so that netstandard2.0/2.1 projects are supported and will build #87

Update checks so that netstandard2.0/2.1 projects are supported and will build #87

Uh oh!

Conversation

hwthomas commented Sep 5, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gluckez Sep 5, 2022

Choose a reason for hiding this comment

Uh oh!

hwthomas Sep 5, 2022

Choose a reason for hiding this comment

Uh oh!

gluckez Sep 6, 2022

Choose a reason for hiding this comment

Uh oh!

hwthomas Sep 6, 2022

Choose a reason for hiding this comment

Uh oh!

gluckez Sep 6, 2022

Choose a reason for hiding this comment

Uh oh!

knocte commented Oct 29, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hwthomas commented Oct 29, 2022

Uh oh!

gluckez commented Oct 29, 2022

Uh oh!

hwthomas commented Oct 29, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gluckez commented Oct 29, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hwthomas commented Oct 30, 2022

Uh oh!

hwthomas commented Oct 30, 2022

Uh oh!

gluckez commented Oct 30, 2022

Uh oh!

hwthomas commented Nov 1, 2022

Uh oh!

hwthomas commented Jan 16, 2023

Uh oh!

knocte commented Jan 17, 2023

Uh oh!

knocte commented Jan 17, 2023

Uh oh!

Uh oh!

hwthomas commented Sep 5, 2022 •

edited

Loading

knocte commented Oct 29, 2022 •

edited

Loading

hwthomas commented Oct 29, 2022 •

edited

Loading

gluckez commented Oct 29, 2022 •

edited

Loading