Support .NET Standard 1.1

[Tyler-IN]

I think you can support the netstandard1.1 framework profile by just adding this target framework to the InlineIL project, a one-line change. I only needed to drop support to 1.4, but just happened to try 1.1 too. This opens up usage of the project under some some reduced functionality (sandboxed) environments.

I made a copy of that (sans t4) in my repo and linked against it. Fody appears to be able to process it properly.

This would also inadvertently, indirectly support .NET 4.5 and other downlevel platforms.

[ltrzesniewski]

Yes, the InlineIL assembly can target practically anything. I simply followed Fody's target framework policy, which follows the .NET Core support policy in this regard.

I suppose I could add the netstandard1.1 target if you need it, but be aware that anything less than v2 is basically really not recommended for use anymore.

[Tyler-IN]

I saw this same response to the issue regarding .NET 4.5 support.

There are platforms I need to support that use older Mono runtimes or have restrictive profiles on newer runtimes (CoreRT, others) that make use of downlevel .NET Standard profile. For example, .NET Standard 1.1 does not provide a mechanism to access Files, only Streams. Yet it has Spans by way of System.Memory. I am of the opinion that the .NET Standard framework profile is outside of the Fody target framework policy. If you conflate the .NET Standard with the compatible framework equivalent, it's not. I do see mention of .NET Framework and .NET Core versions, but not .NET Standard.

Target framework

• Classic .NET: See Support ended in NET Framework version history. i.e only 4.5.2 and above is supported.
• .NET core: Follows .NET Core Support Policy.

No explicit code is in place to check for non supported versions, and throw an error. As such earlier versions of .net may work as a side effect. It's all up to the individual weavers that you use and what version they are able to support.

Any bugs found must be reproduced in a supported version.

Downstream weavers are recommended to follow the above guidelines. Downstream weavers are recommended to follow the above guidelines.

Reasons While it may seam trivial to "implement support for earlier versions of .net" the long term support implications are too costly. For example to support earlier versions of .net require

Custom VMs to verify problems. Added complexity to setting up build environment. Bugs in unsupported versions in .NET may be manifest as bugs in Fody.

For reference, .NET Standard 1.3 is a subset of .NET Fw v4.6, 1.4 is a subset of v4.6.1, and so forth.

Even though older .NET Standard versions do allow support of older platforms, that is not their only purpose. A .NET Standard v2.0 package that only makes use of the .NET Standard v1.0 subset isn't really benefiting itself or it's consumers in any way.

I'd like for the project to support for .NET Standard 1.4 and 1.1. In the mean time, having an out-of-tree build of the InlineIL assembly will be a workaround. Another alternative is of course compiling IL directly.

And if possible, could you cite the recommendation you referenced or is it your own recommendation based on the Fody policy? I can pass it on, but the consumers of my libraries don't use Fody directly.

be aware that anything less than v2 is basically really not recommended for use anymore.

[ltrzesniewski]

Ok, I can add netstandard1.1, it's not an issue for me.

But as I've never used .NET Standard under 2.0, is there a reason you picked 1.1 instead of 1.0? Is there any incompatibility I should be aware of?

If possible, could you cite the recommendation you referenced, or is it your own recommendation? I can pass it on.

I remember the .NET team pushing to adopt 2.0 very hard on Twitter, but I don't know if there's an "official" recommendation.

[Tyler-IN]

.NET Standard 1.0 lacks System.Reflection.CallingConvention used by StandAloneMethodSig, and the System.Runtime.InteropServices.UnmanagedType (where T : unmanaged) type constraint.

If you #if !NETSTANDARD1_0 around those parts of the InlineIL library, you could support .NET Standard 1.0 too.

[ltrzesniewski]

Thanks, I should have just tried it by myself instead of bothering you. I'll add 1.1, I don't want to bother too much since I don't expect anyone to ask me to support 1.0.

[Tyler-IN]

I agree it is very important to maintain systems as well as libraries, and upgrade frameworks where possible. I'm assuming you're referring to this as far as the .NET Team on upgrading to .NET Standard 2.0...

I know we said target The lowest netstandard but we really want everyone to re-baseline at netstandard 2.0. At the very least add a netstandard 2.0 target. #dotnetcore #dotnet — David Fowler (@davidfowl) June 17, 2018

I think the idea is that anyone that can support .NET Standard 2.0 should add a profile to support it. E.g. support the lowest .NET Standard, and separately, dedicatedly, at least also support .NET Standard 2.0, that way if you target .NET Standard 2.0 and depend on something, you don't pull in a bunch of unnecessary dependencies that are only needed for downlevel .NET Standard 1.x.

That's why there's a lot of libraries out there that multi-target old and new .NET Standard versions, so you don't pull in the whole BCL if you already have the functionality in your runtime.

[ltrzesniewski]

I understood "re-baseline at netstandard 2.0" as "ditch 1.x" 😄 The 1.x dependency graph seems to be one of the primary reasons indeed.

[ltrzesniewski]

I released v1.3.6, it should be available on NuGet after validation and indexing.

[Tyler-IN]

According to https://www.nuget.org/packages/InlineIL.Fody/ there's the implicit reference to .NET Standard 1.6.1 showing up for anyone that consumes InlineIL.Fody while targeting .NET Standard 1.1. It's not a big deal, especially if the PackageReference is decorated with PrivateAssets="All". I had no problems updating 5 in-house dependencies to use the new version.

To "fix" this confusing dependency though, you'd need to add <DisableImplicitFrameworkReferences Condition="'$(TargetFramework)'=='netstandard1.1'">true</DisableImplicitFrameworkReferences> to the projects that support it.

IMO this isn't a bug as much as an undesirable "feature." Just so ya know.

[ltrzesniewski]

Ok, thanks! I've noticed this dependency but I've assumed it's not an issue (I never really used 1.x).

But given that the reference to the InlineIL assembly is removed, I guess you're right and I should remove the dependency.

[Tyler-IN]

I don't think the implicit reference to the framework library actually shows up for or means anything to dependents. I think it will only show up on the NuGet info for your package, not child packages or anything. The .NET Standard 1.1 package is (obviously) implicitly referenced regardless. I'm pretty sure it's a non-issue. Just wanted to let you know what it was about, and how to clean it up if you wanted.

[ltrzesniewski]

Thanks, if it's not an issue for you I may just as well leave it in. It looks like your DisableImplicitFrameworkReferences suggestion makes the build fail though.

[ltrzesniewski]

BTW apparently <PackageReference Update="NETStandard.Library" PrivateAssets="all" /> is the way to remove the reference.