Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Extend SupportedSDK list and add Sdk5.0/6.0 templates #90

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from

Conversation

hwthomas
Copy link
Collaborator

@hwthomas hwthomas commented Oct 9, 2022

Guided by commit (d844bc765c) which dealt with extending netcoreapp3.0 to netcoreapp3.1 templates, this PR -

  • Extends SupportedSDK lists in ProjectTemplateWizard, TemplateStringTagProvider, etc

  • Adds Sdk5.0/6.0 templates to MonoDevelop.DotnetCore.addin.xml and MonoDevelop.ASpNetCore.addin.xml

This allows net5.0 and net6.0 projects to be created, and fixes Issue #89

These template updates were overlooked in the menu limit changes in PR #76
Note that the new projects cannot yet be saved (see ongoing Issue #79) Edit: they can after #91

 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
   Incorporate changes in PR#81 from @gluckez to fix conflicts
@hwthomas
Copy link
Collaborator Author

hwthomas commented Nov 8, 2022

To try and sort out the conflicts and failing checks on this (and my other outstanding PRs), I've merged the latest main branch into each of my PR branches. This has now fixed any merge conflicts, and all but this PR now passes on the CI checks.

In my own fork, all the CI runs(https://github.com/hwthomas/dotdevelop/actions) have already passed, but the typical failure here is

2022-11-08T16:08:26.1553159Z   DOWNLOADNUPKG :   
Ssl error : 1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED  
 [/__w/dotdevelop/dotdevelop/main/external/fsharpbinding/MonoDevelop.FSharpBinding/MonoDevelop.FSharp.fsproj]   

which will (almost certainly) pass if I trigger another CI run manually (Edit: Yes, it did!). Can anyone clarify what is going on, and whether there is a "correct" way to fix this? It's very frustrating, and I don't like just blindly triggering another CI run and hoping for the best!

…json

Fix intermittent CI workflow failures by removing nuget/api/v2 urls
@knocte
Copy link
Member

knocte commented Nov 21, 2022

Downloading from nuget has been always error prone for me. Maybe you can make the CI step retry twice before giving up, as a workaround before a migration to .NET6 (in which 'dotnet restore' would be used instead)?

@hwthomas
Copy link
Collaborator Author

@knocte Thanks for your suggestion, though I'm not sure how the CI step, which uses github actions/checkout@v3, could be modified to do this. There seem to be 2 main reasons that the CI workflow fails intermittently - one is the Ssl error : 1000007d: ... OPENSSL_CERTIFICATE_VERIFY_FAILED listed above, and the other is that nearly all nuget/api/v2 URLs now seem to be blacklisted. I've tried to fix this last one with PR #93, which seems to work (so far!).

There are lots of suggestions that the SSL issue can be fixed by adding the flag -DisableParallelProcessing to nuget.exe (running under mono). This is what is already done using a macro in the DotDevelop make file, but I've not found a way of doing something similar in the github checkout@v3 action.

@lextm
Copy link

lextm commented Nov 22, 2022

Maye adding NuGet packages to cache can reduce the frequent CI errors? https://github.com/actions/cache/blob/main/examples.md#c---nuget

@hwthomas
Copy link
Collaborator Author

@lextm That's an interesting thought. I wasn't aware that there could be any persistence between CI runs. If I can find time, I'll try and have a look. Many thanks.

@hwthomas hwthomas mentioned this pull request Nov 23, 2022
@hwthomas
Copy link
Collaborator Author

Merged as part of #96

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants