Skip to content

Commit

Permalink
Merge pull request dotnet#13725 from dotnet/danmosemsft-patch-1
Browse files Browse the repository at this point in the history
Binary serialization is supported
  • Loading branch information
terrajobst authored Nov 16, 2016
2 parents ebfbf57 + 192dab5 commit cb16ed6
Showing 1 changed file with 3 additions and 7 deletions.
10 changes: 3 additions & 7 deletions Documentation/project-docs/porting.md
Original file line number Diff line number Diff line change
Expand Up @@ -74,11 +74,12 @@ Feature owners reserve the right to call out what they don't want to support on

This list, while not complete, is meant as a reference point. We'll add to it as we refine our porting plan. Also, just because something is currently not implemented, doesn't imply it's intentionally unsupported. Feel free to [file an issue](https://github.com/dotnet/corefx/issues/new) to ask for specific APIs and technologies. Porting requests are generally marked as [port-to-core](https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3Aport-to-core).

Binary Serialization is supported post 1.1, however we do not support cross-version or cross-platform binary serialization. For new code you may want to consider other serialization approaches such as data contract serialization, XML serialization, JSON.NET, and protobuf-net.

Technology | More information
---------------------------|-----------------------------------
AppDomains | [Details](#app_domains)
Remoting | [Details](#remoting)
Binary Serialization | [Details](#binary-serialization)
Code Access Security (CAS) | [Details](#code-access-security-cas)
Security Transparency | [Details](#security-transparency)

Expand All @@ -94,12 +95,6 @@ Security Transparency | [Details](#security-transparency)

**Replacement**. For communication across processes, inter-process communication (IPC) should be used, such as pipes or memory mapped files. Across machines, you should use a network based solution, preferably a low-overhead plain text protocol such as HTTP.

### Binary Serialization

**Justification**. After a decade of servicing we've learned that serialization is incredibly complicated and a huge compatibility burden for the types supporting it. Thus, we made the decision that serialization should be a protocol implemented on top of the available public APIs. However, binary serialization requires intimate knowledge of the types as it allows to serialize object graphs including private state.

**Replacement**. Choose the serialization technology that fits your goals for formatting and footprint. Popular choices include data contract serialization, XML serialization, JSON.NET, and protobuf-net.

### Code Access Security (CAS)

**Justification**. Sand-boxing, i.e. relying on the runtime or the framework to constrain which resources a managed application can run, is considered a non-goal for .NET Core. We've already state previously that relying on sand-boxing for security reasons isn't an approach we're feeling comfortable with; there are simply too many pieces in object oriented framework that can result in elevation of privileges. Thus we don't treat CAS as security boundary anymore. On top of that, it makes the implementation more complicated and often has performance implications for the happy path.
Expand All @@ -111,3 +106,4 @@ Security Transparency | [Details](#security-transparency)
**Justification**. Similar to CAS, this feature allows separating sand-boxed code from security critical code in a declarative fashion. This feature was heavily used by Silverlight.

**Replacement**. Use operating system provided security boundaries, such as user accounts for running processes with the least set of privileges.

0 comments on commit cb16ed6

Please sign in to comment.