The new templates for .net6.0 (see https://aka.ms/new-console-template) require C#10.0, which is not available under Mono. However, .net6.0 projects can be created using the .net5.0 template, and the framework updated to .net6.0 in the csproj file.

Provided that export MSBuildEnableWorkloadResolver=false is set before running DotDevelop, .net6.0 projects (simple ones at least!) will build and run as well as .net5.0 ones (and debug using the Samsung.NetCoreDbg debugger).

After NuGet release-5.8 significant changes have been to the NuGet.Client code, so further upgrading the DotDevelop PackageManagement code will not be so straighforward as in this PR. However, this opens up many more questions as to how DotDevelop might be extended further, and how to clean up the interface between the IDE GUI and the 'native' IDE components.

@lytico My original preference was for Option 2, partly because I was unsure of how to specify a branch in the .gitmodules submodule entries. Now that the dotdevelop/nuget-binaries repo has been updated (thx!) it would be as easy to do things either way, so if that would help, I can change it.

You'll have noticed that I have rebased each branch in the cumulative PRs (#77 , #87 , #90 , #91) to the tip of the previous one, as I thought that this might make less work for the maintainers.

I've also combined all together into a single branch hwt-dev in my fork (https://github.com/hwthomas/dotdevelop/tree/hwt-dev) and, taken together, they now allow DotDevelop to create, build, and debug (with the SamsungNetCoreDbg) simple .net5.0 and .net6.0 projects. If you have any time to try this out, I'd be interested to have any feedback.

This is superb work. BTW I'm wondering if this might help pave the way to be able to build dotdevelop with dotnet6 alone (without Mono/MSBuild)?

@knocte promising, but might not be optimistic, as Samsung .NET Core debugger might not be able to debug very big projects yet. More testing is required.

@hwthomas disregard my earlier deleted comment, since this last pr seems to share all the commits of the others. If we merge this one, can the others be closed? and is it ready to merge?

@knocte thanks for your encouraging comment - it was much appreciated!

However, I don't think that my PRs will help in any way with building DotDevelop from dotnet alone. They involve code changes that simply update DotDevelop to handle .net5.0 and .net6.0 (and which weren't in place when MonoDevelop was archived).

The mono version of msbuild (which msbuild) is run from a script in /usr/bin which in turn calls mono /usr/lib/mono/msbuild/15.0/bin/MSBuild.dll, so that with

• dotnet-sdl-5.0 or dotnet-sdk-6.0 installed, msbuild --version returns Microsoft (R) Build Engine version 16.10.1 for Mono

whereas, with

• dotnet-sdk-5.0 installed, dotnet msbuild --version returns Microsoft (R) Build Engine version 16.11.0+0538acc04 for .NET
• dotnet-sdl-6.0 installed, dotnet msbuild --version returns Microsoft (R) Build Engine version 17.0.0+c9eb9dd64 for .NET

Building DotDevelop with

msbuild -p:Configuration=DebugGnome main/Main.sln completes with 1441 Warnings, 0 Errors, but

dotnet msbuild -p:Configuration=DebugGnome main/Main.sln fails with

error MSB3644: The reference assemblies for .NETFramework,Version=v4.7.2 were not found. 
To resolve this, install the Developer Pack (SDK/Targeting Pack) for this framework version or retarget your application  

AFAIK there is no .net5.0/6.0 Developer Pack for .NETFramework 4.7.2 for linux, so I don't know how to proceed from here.
Can anyone advise? It would make a good Issue to raise (and perhaps fix/reduce the 1441 Warnings at the same time!)

@lextm I'm unable to comment on the Samsung .NET Core debugger capabilities, but I am reasonably encouraged by the fact that I have only used DotDevelop for the debugging, editing, and testing of the PRs described above (and not Rider or any other IDE). More testing is certainly needed (which I've tried to make a bit easier with my hwt-dev branch) but we also need more eyes to scrutinise code changes, and this requires a more active developer community, which is another issue...

@gluckez The 3 PRs are sequential, as each needs the previous one, and if they had all been rebased to the current commit in dotdevelop/main (commit 6d6f43c) there would have been merge conflicts.

From my point of view, they can all be merged and then deleted, but as I've mentioned before, it would be good to have a dev branch so that more testing could be done before merging into main. At present, I'm waiting for a comment from @lytico in order to resolve the conversation from 14 days ago.

AFAIK there is no .net5.0/6.0 Developer Pack for .NETFramework 4.7.2 for linux

should be installed:

dotnet/sdk#10981

@hwthomas I just tested your changes, pulled from your own repo, and everything seems fine.
I was able to build it without any issues, create a .net5 project and run it. (Im on ubuntu 22.04, and even have staging repositories enabled, so I'm definitely on the most recent system)
I only had one issue, where the makefile was overwriting part of my PATH and couldn't find dotnet, but that was easily resolved.
I think this can just be merged and because your branch also includes the changes from the other pr's, there's no need to merge them sequentially.

The dev branch is definitely a +. I do this myself on my own fork, where I merge all my own changes to dev, and test like that. If everything is fine, I pull in all changes from upstream into my main branch, and merge with that one first before making a pr here. I have policies in place on my own fork to set develop as the main working branch. @lytico what do you think?
I don't think the absense of the dev branch should not be an impediment for this pr to be merged though, these are very useful changes. great work!

Thanks for your hard work in the past 2.5 years, guys. It's such a long journey.

Once all are merged, it is really a huge milestone for this fork that .NET 6 based development can be performed with

• a working code editor
• .NET Core build system
• .NET Core debugger

As .NET 7 is not an LTS release, and .NET 8 is one year away, this milestone can ensure this Linux centric open source IDE has enough time to evolve further, and adapt to .NET 8 on time.

I am reasonably encouraged by the fact that I have only used DotDevelop for the debugging, editing, and testing of the PRs described above (and not Rider or any other IDE)

Brilliant!

dotnet msbuild -p:Configuration=DebugGnome main/Main.sln fails with
error MSB3644: The reference assemblies for .NETFramework,Version=v4.7.2 were not found.

I wonder if this would not happen in case we translated all the .csproj and .fsproj to SDK style? (So, .NETCore/.NET5/.NET6, you know.)

@knocte I actually tried working on it in Rider and got a bunch of errors that I don't get when working in DotDevelop xD.
I think if all csproj were converted to net core sdk style projects, it would compile without the need for mono, so indeed it wouldn't happen.
It's something I've worked on a little bit before, and got a fork of the mono-addins repo where I actually already did convert it to .net standard projects, so I think if it's done little by little we could eventually get there.

so I think if it's done little by little we could eventually get there.

Agreed. So let's get this ball rolling? I see that dotdevelop already points to a fork (https://github.com/dotdevelop/mono-addins), why don't you propose that conversion as a PR there?

@knocte don't tell me to get the ball rolling xD I've already started. I have my own fork of mono-addins where I ported the entire thing to .net standard. and am using that fork to build dotdevelop. It seems to work fine, but I have no experience porting old projects to the new sdk style projects. I'll make a pr there, but we should make sure it's on our roadmap as well and that's the direction we want to go in next. I was thinking it might also be interesting to publish those external projects as nuget packages.
@lextm @lytico @hwthomas what do you think?

EDIT: closed my pr, as pointed out by it's not going to be as simple as the way I implemented it.

Merged as part of PR #96

@gluckez dotdevelop on .NET 6 or 7 is clearly a good direction for the next phase. Performance wide it will boost the IDE experience significantly.