Port to Framework/NET45

[ezdiy]

• Get rid of netstandard abuse, as far as compiler errors are concerned
• Replace Buffer.MemoryCopy with Unsafe.CopyBlock for NET45

This is largely untested in a wider setting (I'm using only a subset of bepu on rather date mono runtime), but could be of interest for people in #80 and #59

[RossNordby]

This is indeed a good example of the kind of changes required for older frameworks.

I can't merge it though- there are performance implications. Also, at a glance, I'm not sure what is causing the test to fail- default initialization shouldn't, so presumably it's something subtle with the copies. That particular failure can happen when NaNs infect everything.

[AshleighAdams]

Also, what is up with all the style changes? Perhaps you can generate a .editorconfig @RossNordby to prevent peoples' VS settings messing stuff up.

[SupinePandora43]

Why there's a lot of =default?

[RossNordby]

Differences in zeroing requirements on framework versus NS2.0. Vector<T> is an empty stub in NS2.0, so the compiler doesn't see any fields requiring initialization. In the framework version, it requires initialization, hence defaults.

2.4 targets .NET 6 and makes use of Unsafe.SkipInit and SkipLocalsInit instead.

[damian-666]

recommend closing this

porting to Net 6 is sort of a huge deal.. but we have Wpf core and net 6 dlls are much faster, net standardard is not really supported.. best to avoid it. recommend closing this.. it took me months but i think most people got through it. Is anyone really stuck with legacy .net45

still ?
for tooling or whatever reason?

even if the shared dll is linked to netstandard2.0 and the exe is 6, rebuilding the dll to net6 gives it a huge performance boost..