update roslyn workspace 4.4.0

[colombod]

No description provided.

[daveaglick]

@psfinaki and @0xced - do either of you see any issues with this retarget for Stryker consumption? Is it able to consume a .NET 7 library?

@cslong Same question for the AWS stuff?

@alfonsogarciacaro And for Fable?

Just figured I'd check with some of the bigger consumers I know about before a big retarget like this. Thanks all (and thanks @colombod for getting the ball rolling)!

[psfinaki]

Well Stryker definitely works with .NET 7, so AFAIU this should be fine (and maybe even helpful), @richardwerkman correct me if I am wrong.

[richardwerkman]

Stryker runs on .NET 6 at the moment and we try to only update to LTS versions. So that means we would skip V7. Currently, we can't consume .NET 7 packages. @psfinaki it's true stryker works on .NET 7 projects but it runs on .NET 6.

[psfinaki]

Alright, sorry for misleading then, good that I asked :)

[colombod]

I think  I should then use net 6.0 in the binaries and just keep the roslyn workspaces packages to 4.4.0 will push that changes later Dr Diego Colombo PhDOn 29 Nov 2022, at 17:18, Petr ***@***.***> wrote: Alright, sorry for misleading then, good that I asked :) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[rouke-broersma]

Is net6 required for roslyn workspaces 4.4? If not I think this should probably be a separate change. It's also a huge bump from 3.1, and makes it so this library can't be consumed by < net6 so probably a breaking change.

I don't personally disagree with that as netcore3.1 is EOL but it does limit potential consumers and shouldn't be taken lightly, imo.

[colombod]

Is net6 required for roslyn workspaces 4.4? If not I think this should probably be a separate change. It's also a huge bump from 3.1, and makes it so this library can't be consumed by < net6 so probably a breaking change.

I don't personally disagree with that as netcore3.1 is EOL but it does limit potential consumers and shouldn't be taken lightly, imo.

Is not strictly needed but did it because of EOL for 3.1 I'd prefer to move to LTS version

[rouke-broersma]

Is not strictly needed but did it because of EOL for 3.1

In that case I think a separate pr is cleaner.

[daveaglick]

Go team! Thanks for the input everyone, glad I surfaced this one to the community.

In that case I think a separate pr is cleaner.

I agree, and in general I try to stick to the lowest possible target to allow the largest number of consumers. I've been on the consumption end where I'm unable to update my own targeting so I appreciate when projects don't retarget just for retargeting sake.

@colombod let's do this:

• Microsoft.CodeAnalysis.CSharp.Workspaces 4.4.0 only has a dependency on .NET Core 3.1, so let's make this PR just for that update. Then I can get a release out with the updated workspaces library.
• Separately let's do an update to .NET 6 as the latest LTS since .NET Core 3.1 is falling out of support in a couple weeks. That should let Stryker (one of our most active contributors) continue to consume without issue while bumping us to a supported platform. By separating the PRs and releases we can also let anyone who needs to stay on .NET Core 3.1 get the workspaces update and then hang out on that release.

Sound good?

[colombod]

Good let me do that in few minutes

[daveaglick]

Fantastic, thanks! Merging in and doing a release now (it'll take about an hour to run through local tests prior to deployment).

[colombod]

@daveaglick I split to #221

[daveaglick]

Buildalyzer 4.1.7 (and related libraries) with this change to the workspaces dependency have been published to NuGet. I'll work on #221 as Buildalyzer version 4.2.0 next (I like to bump the first minor version number on any targeting changes).