-
Notifications
You must be signed in to change notification settings - Fork 432
MarshalByRefObject #7
Comments
Move all API's in *Remoting* namespace to remoting extensions this caused the following APIs to removed: MarshalByRefObject.CreateObjRef #7 BinaryFormatter APIs #8 Thread.CurrentContext which is remoting specific ApplicationActivator.CreateInstance APIs which are remoting specfic We should also clean out more application activation APIs after we remove CAS.
(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. |
Why don't we leave MarshalByRef as-is and simply not implement it on other netstandard types? |
@KrzysztofCwalina so your vote is for (3)? I will put a PR together with what that looks like and we can review. |
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. |
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. |
The closer isn't bad for (3) so we chose that option with PR #13. |
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). |
After further consideration on #7 we decided to go with option 2 which removes CreateObjRef and its unique closure.
Decided to go with option (2) 80799d9. |
In README, I read in "Requirements":
It seems to me that the decision taken in this issue violates the requirement, doesn't it? P.S. I don't need |
@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. |
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 ? |
We are excluding Remoting APIs from the standard and as part of that we need to decide what to do with MarshalByRefObject. There are a few options:
I'm tentatively leaning towards option (2) but I'm interested in other opinions.
The text was updated successfully, but these errors were encountered: