Mono Upgrade Modern .NET Class Library Profiles

Yes, that is fine and well, it will allow current projects to move on. But when you say .NET Standard 2.0 is the new default, I think a lot of new projects will be using that. I'd rather not continue to put focus into a "legacy" target if I can avoid it. Performance wise using reflection and emit at build time and generating assemblies for my project will be superior and would work with both Compabitility Levels (Win!), I just need a way past this annoying snag.

 

I'm well aware that .NET Standard is the new thing, I meant that there seems to be an increased focus on AOT platforms. Will .NET Standard 2.1 have System.Reflection.Emit on AOT platforms too? If not I'll consider Reflection.Emit a nice tool to build custom assemblies both for auto generated code but also for doing things my regular C# isn't allowed to do... like access private fields efficiently. FieldInfo.GetValue can access the fields, it's just a suboptimal path with other limitations like not accessing unsafe pointers properly.

 

@JoshPeterson thanks for the clarification, it is as I suspected.

Can you shed some light on how to make a dll obtain the full trust necessary to access private fields of another dll within my own unity project? Obviously I could bypass it through unsafe but only if I make assumptions about the .net runtime which I'd rather not do.

 

As I was researching this I stumbled upon several references to this being possible under the right circumstances, some said gac, some mentioned signing, others trust, they were all very vague. Trying to go back and find these I've found several posts from microsoft employees saying not possible at all, so perhaps I was chasing a rumor to begin with.

For all intents and purposes I could use Reflection.GetValue for most things, it's slower but would do the trick, except when trying to access fields of unsafe types like char*. Any ideas on how to make a char* survive the cast to object in GetValue because all I seem to be getting is the first char as a value.

 

Note that Unity is used in a lot of contexts where build size absolutely doesn't matter - internal company apps, interactive exhibits, ... especially in a brand communication context. A lot of times, this requires the use of obscure and uncommon external libraries that more often than not rely on .NET Full instead of .NET Standard.

Please don't remove the "I want everything" option, even if you only keep it for Desktop platforms.

 

Thanks for the clarification. I couldn't find the point where that was decided throughout this thread and was a bit frightened by your start post which still says as goal ".NET Framework (Full) - Deprecate/Remove".
- Might make sense to clarify at the bottom of that first thread what the current thinking is.

 

I don't know if this is the correct thread to ask this question, but im a little confused with the current Unity Mono/.NET state. So my first question is there any way to "avoid" Mono by using .NET core/standard will Unity always use Mono no matter which .NET im using?

Also how can I confirm/check that the Unity Mono implementation behaves the same as the "normal" .NET implementation?

This might sound like a weird question, but I have a very specific case The the System.Net.Sockets have a SendAsync method, in the "normal" .NET implementation the Completed event is not called until all bytes are sent (or a error happens). In some Mono implementations this isn't true and the Completed event can (only in some cases) be called before all bytes were sent (in this case you have to check how many bytes were sent and then call SendAsync again with the remaining bytes). So it would be a problem if I don't check the "TransferedBytes" property, which isn't needed in the "normal" .NET and then suddendly the Unity Mono version has a different implementation and my networking code breaks on some targets.

And maybe there are other cases where the Mono implementation is different in some special cases, so what's the best way to deal with these situations? The SendAsync method isn't even documented how it should behave, there is no official statement if the Completed event should only be called if all bytes are sent or if it should already be called when some bytes are sent, which makes it an even more special case. (But it would make more sense if it is only called after all bytes are sent, like in the "normal" .NET implementation)

(Even more off-topic: This networking code is in a own dll which I also use for my other C# projects like Windows desktop stuff, all of them use the "normal" .NET, so I could add the check to the code in this case, but it feels a little dirty to add "Unity/Mono specific" checks just because their Mono imlementation might do something different)
https://docs.microsoft.com/en-us/do...ockets.socket.sendasync?view=netframework-4.8

 

Is your github fork still a good place to dig-in on understanding Unity's implementation-specific behaviors for .NET Apis?

e.g. https://github.com/Unity-Technologies/mono/tree/unity-2019.1-mbe for 2019's ".NET 4.x Equivalent" Scripting Runtime Version

... and digging in here for the SendAsync question?
https://github.com/Unity-Technologi...ass/System/System.Net.Sockets/Socket.cs#L1859

 

I would love to know, why in 2020 august, mono 5.x version and .net 4.7, there is still no support for 3/4 of interopService functions like: Marshal.getActiveObject(string progID)`?? or type.getTypeFromprogID(..)

Is this anyhow still archivable??

any answer on this would be nice