Remove .NET 4.6.1 support; netstandard2.0/.NET 4.7.2 new minimum

[tillig]

This enables a Mac with VS Code and Mono to at least build Autofac. It doesn't allow .NET 4.6.1 tests to run but it can build.

I'm starting to think maybe dropping .NET 4.6.1 specific support might be OK for Autofac 6. .NET 4.7.2 does support netstandard2.0, it's been out since 2018, and we could still build for that, which would keep WCF and other .NET desktop framework extensions working. (That's an orthogonal discussion, but it'd make this VS Code integration way easier. I could do that as part of this PR if needed.)

There's a small fix that also snuck in here, where I noticed the DefaultDiagnosticTracer might have a memory leak with respect to how it tracks what traces are in progress. I had a whole... there was a whole thing where I started a branch to work on diagnostics, then thought about getting build support in there, then... anyway, it was hard to back that out and cherry pick and I just left it. I can re-branch and fix all this up if needed. My Git-fu is somewhat lacking.

[tillig]

Oh, I also saw we still had a bunch of partial trust tests hanging out, which don't really make sense when the assembly isn't explicitly annotated for that. These were remnants from the old days of code access security and AllowPartiallyTrustedCallersAttribute that just don't exist anymore.

[tillig]

By way of information for .NET 4.6.1... it appears .NET 4.6.1 is supported as part of the operating system(s) with which it ships:

• Windows 7 SP1
• Windows Server 2008 R2 SP1
• Windows 8.1 Update
• Windows Server 2012
• Windows Server 2012 R2
• Windows 10

When they say "Windows 10," they mean "Windows 10 with no updates," or at least I assume so, since on that same page they talk about how .NET 4.6.2 is supported as part of "Windows 10 (Update 1607)."

Server 2012 R2 ended mainstream support on October 9, 2018. Windows 10 (Update 1607) ended mainstream support on April 9, 2019. (It's hard to tell when "unpatched Windows 10" ended mainstream support, but I have to assume it was before that.)

Point being, this effectively puts .NET 4.6.1 in an unsupported position as of about April 2019 at the latest. It's likely reasonable to assume that folks have moved on, or if they can't then they're still on unsupported operating systems and they have other problems to solve than wondering why they can't take Autofac 6.

[alistairjevans]

I think if people can still use a .NET Framework version with Autofac, thats good enough.

So if we target ns2.0, and that runs on 4.7.2, that's more than sufficient from my perspective.

[tillig]

Fair enough. Should I include that in this PR?

[alistairjevans]

I would; but perhaps rename the PR? That supported platform change is now kinda the major change of this PR...

[tillig]

The removal of .NET 4.6.1 is now included.

• Removed target framework
• Removed #if references to NET461
• Removed references specific to .NET 4.6.1.

Huge benefit here - you can do a full build and test of the whole thing on Windows or Mac now, opening up the opportunity for a new set of contributors to participate.

I did update the scanned assembly to netstandard2.1 because the Omnisharp analyzer mechanism got bent out of shape that the tests (netcoreapp3.0) were trying to use Autofac at netstandard2.1 but the scanned assembly was forcing a downgrade to netstandard2.0. It doesn't really matter, just gets it to quit complaining.

[tillig]

I do see a lot of IDEXXXX "info" suggestions for improvement now, things I didn't see before. Looks like stuff coming from .editorconfig that just hasn't been fixed yet. I might do a housekeeping PR later to clean some of that up, modernize the code.

[alsami]

I'm starting to think maybe dropping .NET 4.6.1 specific support might be OK for Autofac 6. .NET 4.7.2 does support netstandard2.0

TFM net461 mostly also supports netstandard2.0. Some users might not run into problems, some might. Here a good post by terrajobst describing the initial design idea and potential problems with net461 and netstandard2.0

[alistairjevans]

Is it worth changing to a linux appveyor agent from now? Potentially faster builds?

[alsami]

Is it worth changing to a linux appveyor agent from now? Potentially faster builds?

I guess the machine image used would be smaller so it should definitely be a bit faster.

[tillig]

We could update the build, for sure... But could that be a separate PR? This has sort of morphed a bit from adding VS Code support so I can work on some diagnostics stuff (my daily driver recently, for reasons I won't get into, is a somewhat underpowered Mac and the VS-in-a-Windows-VM experience there is sub-par) to removing net461 and I feel like I'm heading into yak shaving territory.

[alistairjevans]

Yes, we can do that at any point really.

[tillig]

Awesome. Let me know if I should approve/merge my own PR. Which, like, I'm totally fine with, just checking with the group. :D

[alistairjevans]

Yep, crack on! I had a look at the changes this morning and everything looks good. 🧗‍♂️