MarshalByRefObject about standard HOT 11 CLOSED

@AlekseyMartynov you're quite right - that readme needs an update. What we did do is only remove members where we were forced to to snip dependencies on whole technologies that we did not want to drag into the standard. We did not remove members for other reasons, such as where we know a platform will not full implement certain members (example: AppDomain.CreateDomain is not going to be implemented on .NET Core as it has chosen to not allow creating new app domains). Of course, we hope and believe that platforms implementing the standard rarely do not fully implement members in the standard. Such cases would need to be documented. When writing code targeting the standard, it is still important to do some testing on all the platforms that you want it to run on, to be sure.

from standard.

(1) is very intrusive on existing code, and it makes it impossible to write certain kinds of remotable objects in a portable library, the vast majority of which only need to derive from MBRO.

(2) CreateObjRef is almost never overridden by remotable objects, so it doesn't seem that bad to not have it be part of the standard. But this is also a case where, if you did need to override it, there'd be no way to do so without it being part of the standard, right? We talk about reflection in general being a workaround when we don't include members, but that wouldn't apply here.

(3) Other than cleanliness, this seems to have the fewest downsides: the standard will have some extra interfaces in it that most implementations simply won't care about.

We shouldn't do (1). I'd be ok with (2) or (3). (3) seems like it's the least risky.

from standard.

Why don't we leave MarshalByRef as-is and simply not implement it on other netstandard types?

from standard.

@KrzysztofCwalina so your vote is for (3)? I will put a PR together with what that looks like and we can review.

from standard.

Sorry, I meant: ship it OOB (not in netstandard) MarshalByRef (and dependencies) without any changes. If existing code uses the APIs, it will be able to compile without any issues after referencing the OOB component.

from standard.

Shipping it as OOB would change the base types for a lot of types in the standard which I would like to avoid.

I've put together a PR (#13) that shows the full closure of option (3) and it doesn't look too bad.

from standard.

The closer isn't bad for (3) so we chose that option with PR #13.

from standard.

While doing this work for .NET Core there were a number of questions about this so I'm reopening to reconsider options.

After chatting with @jkotas he feels we should go with option (2).

from standard.

Decided to go with option (2) 80799d9.

from standard.

In README, I read in "Requirements":

We’ll not necessarily bring all the types that .NET Framework has, but that we’ll bring types in their entirety without subsetting members.

It seems to me that the decision taken in this issue violates the requirement, doesn't it?
Is it a corner case handled in a special way, or should we be ready to find arbitrary class members missing from .NET Standard 2?

P.S. I don't need MarshalByRefObject or its members. Asking out of curiosity, to better understand how the list of APIs is composed.

from standard.

Hummm for me the real question is can we create another app domain in .net core ? I have an application that use app domain isolation + remoting to communicate with plugin (such as System.AddIn does) what about those king of applications with .net core ?

from standard.