This PR builds without error on linuxmint, which is based on ubuntu, so I'm not sure why the CI / linux run fails, though the error log shows that the PublicKey used is not being valid. I've now updated this to use the PublicKey from main/external/mono-addins/mono-addins.snk, which I'm hoping will be a valid choice. The ubuntu 20.04 software environment that CI uses contains mono-6.12.0 and msbuild-16.6.0, which won't actually prove the PR, but if it passes CI, it should be OK when building with msbuild 16.9.0 and 16.10.1. I'm not sure of the easiest way to add this latest commit to the PR - some help would be appreciated!

Adding another commit to the PR was the easy bit! The CI run fails, but not with any error related to the PR changes. In fact, a CI run on my own fork fails on the main branch, so it seems that the fault has developed in the CI environment. I've set up a clean ubuntu 20.04 VM, and this builds dotdevelop with no errors. The CI software environment looks to be right (https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software) so I'm not sure where the problem could be. Any thoughts @lytico, @lextm?

seems that some fsharp-stuff is not installed in the CI
maybe it's not in the default mono installation any more

I'll try and add all the mono, msbuild fsharp, gtk-sharp stuff explicitly to the CI environment (just as for the VM) and see if it makes any difference. fsharp ought to be there, but we'll see.

Well, that was interesting. CI run passes OK on the main branch now, so something is not right with some of the pre-installed software. I'm sure my monodevelop.yml has some unnecessary lines in it now, but it does work. Perhaps you could have a look and see what you think, @lytico, and I'll submit a PR if that's the easiest way to go. Is it worth raising a new Issue/PR for the failing CI, just for the record?

has some unnecessary lines

can't see what's the difference. anyway, it's building now, so someone can optimize it again

Is it worth raising a new Issue/PR for the failing CI,

yes, i thing its better to have extra PR for CI-change

maybe kick out MonoDevelop.TextEditor.Cocoa & MonoDevelop.TextEditor.Wpf - we don't need them

maybe kick out MonoDevelop.TextEditor.Cocoa & MonoDevelop.TextEditor.Wpf - we don't need them

I'd prefer to just merge as-is, which lets dotdevelop build with msbuild versions 16.9.0 and 16.10.1

Pruning the (redundant?) Windows and Mac code can be left until dotdevelop is working on .NET 5.0 (!)