Upgrade to .net 6

[taooceros]

It's pretty easy to upgrade (just replace all net5.0 with net6.0), so I don't see a reason we don't want to upgrade.

[jjw24]

This need to be delayed to later.

• dont upgrade Flow.Launcher.Plugin, otherwise we will need to do another force upgrade on plugins
• this will be a force upgrade for users who are not upgrading to the next release immediately, otherwise they wont be able to use the new plugins using the new api. Also means we need to repoint the manifest default branch.

personally feel a bit too soon to do so considering we just done it for 1.8.0

[jjw24]

also those that are using this pr build, please list what areas have been tested, so reviewer doesnt have to test all again.

[taooceros]

It's similar to our dotnet 5 upgrade. Plugin will work even though they don't upgrade.

[taooceros]

yeah it's true that it may be a bit early. Appveyor hasn't finished their visual studio 2022 image🤣. However, it's easy to do, so I just create one for test.

[taooceros]

This need to be delayed to later.

• dont upgrade Flow.Launcher.Plugin, otherwise we will need to do another force upgrade on plugins
• this will be a force upgrade for users who are not upgrading to the next release immediately, otherwise they wont be able to use the new plugins using the new api. Also means we need to repoint the manifest default branch.

personally feel a bit too soon to do so considering we just done it for 1.8.0

that probably means we take half year to finish the 1.8.0. Probably a bit slow🤣

[jjw24]

Yeah true, but to others, we just done a force, if we do this it's going to feel like another force update so soon.

[jjw24]

It's similar to our dotnet 5 upgrade. Plugin will work even though they don't upgrade.

Yeah they will work but there is potential that 1.8.x users download new plugins with the new api then will break. Any plugins built with 6 will also break for these users.

[taooceros]

It's similar to our dotnet 5 upgrade. Plugin will work even though they don't upgrade.

Yeah they will work but there is potential that 1.8.x users download new plugins with the new api then will break. Any plugins built with 6 will also break for these users.

hm that's true

[taooceros]

@jjw24 I think it is possible to add multiple framework target here. So there's no issue of forcing people to use net6.0. We can remove it in the future.

[jjw24]

interesting. let's test it out

[taooceros]

.Net 7 may be released in November. Do we want to directly go to .Net 7 if we are not planning to release soon (Or give preview a try)?

[jjw24]

I have been actually daily driving this .net 6 change atm and I'm thinking of merging it to dev once tested some scenarios, so maybe hold off 7 or do it in a separate PR?

[jjw24]

@taooceros can you try doing a fresh build of this branch locally using visual studio 2022, are you getting any build errors?

[taooceros]

I can build it successfully on vs2022

[jjw24]

I am getting the Fody error where the DLL is locked down by another process, tried doing a clean of both project and the .nuget folder as well as restarting VS2022. Did you get this error?

[taooceros]

I am getting the Fody error where the DLL is locked down by another process, tried doing a clean of both project and the .nuget folder as well as restarting VS2022. Did you get this error?

I did. But it disappear after a restart.

[jjw24]

In VS2022 with the Plugin project, I can build the entire project without issues if the target is only for .Net 6 - <TargetFrameworks>net6.0-windows</TargetFrameworks>, as soon as I revert back to <TargetFrameworks>net6.0-windows;net5.0-windows</TargetFrameworks>, I get this error on every rebuild:

[jjw24]

I am getting the above error consistently with two separate machines. I don't think it's necessary to target .Net 5, if any user is having issues later on running older flow version installing plugins using the new .Net 6 plugin API we can just ask them to upgrade Flow.

I will remove the .Net 5 target framework.