Library development

[NN---]

Library branches makes very hard for collaboration and publishing.
Right now there are 3 develpoment branches: master, develop_v3, develop_v4.
They are not fully synchronized and no cross merges between them.

There is a big change in develop_v4 making use of unsafe and requiring FullTrust in .NET Framework.
While these limitations might be restricting, this allows writing more performant and type-safe code.

I suggest simplifying this by making one development branch and removing all others by leaving a tag to that release.

@OwnageIsMagic

[OwnageIsMagic]

One development branch would be great.

---

Regardless PartialTrust, there is 2 common sources of it: non default host and loading code not from local disk.
For the first option the most common case is Asp.net, but it's opt-in there AFAIK (Is there any shared asp hosting still alive? haha).
For the second it's a real problem, but since partial trust is REALLY limiting I don't expect that would affect someone not already having troubles with it.

---

Since we are limited in HR, the only manageable way for this project development is code imports from upstream. Writing our own implementations leads to conformance bugs i.e. #195 and misses opportunity to use already reviewed and battle tested code.
So we should develop and provide some guidelines on this topic.

1. Upstreams

	Upstreams (in order of preference)
dotnet/runtime	main source
dotnet/corefx / dotnet/coreclr	netcore3.1 branches and some OOB (out-of-band) packages not migrated to dotnet/runtime
microsoft/referencesource	NetFx BCL and OOB packages licensed as MIT/Apache2.0
mono/mono	somehow in sync with dotnet/runtime, but have different history for pre-Core era
nanoframework	successor of NetNF, doesn't target netstandard and have most of BCL implemented as separate packages

2. Each PR is annotated with source of import.
3. Minimize patching (ideally only #ifdefs and static references fixup).
4. Unless changes are trivial use two phase commit: commit original source in first commit, fix build in second commit. So re-patching updated code should be easy (just applying second commit as patch).

[OwnageIsMagic]

Trust issue affects only net20/net35. Since net40 CAS policy is disabled by default. See also https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/loadfromremotesources-element

[OwnageIsMagic]

About current state of development branch
I think we should drop array based Span before release, since it doesn't fulfill it's most common use cases of stackalloc without unsafe and missing ref T constructor. So it quite useless in presence of ArraySegment.

[OwnageIsMagic]

linking related posts for history
#198 (comment)
#197 (comment)

[NN---]

I understand we do agree regarding dropping Partial Trust support.
This allows using unsafe and copy-paste from the main .NET source code.

[OwnageIsMagic]

Just writing down our reasoning in case someone have any objections.

[NN---]

@OwnageIsMagic Do you have a discord/gitter ?

[NN---]

https://discord.gg/5J2pNQHY

[NN---]

Suggesting next steps:

Fix all branches as tags.
Make Develop_v4 master branch.
Merge changes from other branches if there are.
Release v4.0-beta with FullTrust requirements.
Wait for complains if there will be.
Upgrade compiler to the latest C# with the latest .NET SDK.
Start backporting code from .NET preferably without any code change if possible.
Do not forget to write API tests what is possible.

WDYT ?

[OwnageIsMagic]

Nice plan. I also created #208
Some thoughts:

Start backporting code from .NET preferably without any code change if possible.

There are three possible situations:
New NET 5+ only api -- easy and straightforward -- just copy from source.
Existing api extension -- most of the time source implementation depends on private/internal state. We need to develop some guidance here (i.e. extension methods holder class naming, etc).
Mixed -- type already exist, but only in some subset of all tfm. Would be nice to enforce consistency on file naming/directory structure.

Do not forget to write API tests what is possible.

Since we have the same public surface, we can also import most of the tests. But we have very different infra, so we need to find a way how to integrate them with GitHub Actions.

---

We need to try develop solution for automatic #if tfm guards placement (a lot of them here are placed wrongly) and probably some other automatic backporting (i.e. Array.Empty<T> -> ArrayEx.Empty<T>). It will be out of build tool, cause in-build will result in poor IDE experience (broken intellisense).

---

I'm very annoyed that this package also ships it's own api surface in Theraot.Extensions namespace, in particular by AsUnaryEnumerable that extends unconstrained T -- effectively every type and bunch of As\To\Wrap extensions on collections with unclear semantics. There a lot of utils packages out there and most users probably have own collection of utils like that. Would be great to drop it.

[theraot]

Upgrade compiler to the latest C# with the latest .NET SDK.

You might run into trouble building for older targets as some are out of support.

[NN---]

I think if you have the SDK installed there will be no problem.

[OwnageIsMagic]

@NN--- / @theraot can you give Collaborator status?

[OwnageIsMagic]

Does anybody have link for net30 targeting pack installer?
error MSB3644: The reference assemblies for .NETFramework,Version=v3.0 were not found. To resolve this, install the Developer Pack (SDK/Targeting Pack) for this framework version or retarget your application. You can download .NET Framework Developer Packs at https://aka.ms/msbuild/developerpacks