Runtime: 질문 : .Net Core 1.0에서 진행되는 직렬화 지원

https://github.com/dotnet/corefx/blob/2b15de70c1cf9f585c4878a722de4dbe42b4940b/Documentation/project-docs/porting.md#binary -serialization

안녕하세요 @joshfree , 예, 불행히도 그것이 혼란을 일으킨 문서였습니다. 제안 중 JSON.NET은 json 직렬화를 수행하고 protobuf-net은 이진 직렬화를 수행하며 datacontractserializer는 xml 직렬화를 수행합니다. 문제는 이진 직렬화를 수행하려는 경우입니다. protobuf-net은 훌륭한 라이브러리이지만 제한적입니다. Protobuf-nets repo에서 지원되는 유형은 다음과 같습니다.
다음과 같은 사용자 정의 클래스 :
데이터 계약으로 표시됩니다.
매개 변수없는 생성자
Silverlight : 공개
많은 공통 프리미티브 등
단일 차원 배열 : T []
목록 / IList
사전 / IDictionary
IEnumerable을 구현하고 Add (T) 메서드가있는 모든 유형
과거에는 binaryformatter가 항상 있었기 때문에 괜찮 았지만 더 이상 그렇지 않을까요? protobuf-net에서 지원되지 않는 유형의 이진 직렬화에 권장되는 방법은 무엇입니까? 직접 만드시겠습니까?
나는 여전히 이러한 모든 기술에 대해 꽤 초보자이므로 무언가에 대한 요점을 완전히 놓칠 수 있습니다.

또한 이들 중 어느 것도 분산 컴퓨팅 (Azure ...)에서 필요에 따라 예외를 안정적으로 직렬화 (및 모든 관련 데이터 유지) 할 수 없습니다.

@cdrnet point는 Orleans guys IIRC와 같은 사람들에게 큰 고착 점입니다.

@joshfree 포팅 지침이 지적했듯이 기를 .NET Core로 가져올 계획이 없습니다. .NET Remoting과 .NET Core의 AppDomain 개념이 없으면 이진 serializer는 훨씬 덜 유용합니다. .NET Core에서 계속 지원 될 DataContractSerializer (DCS), DataContractJsonSerializer (DCJS) 및 XmlSerializer와 같은 .NET Core의 다른 serializer를 고려하세요. 물론 .NET Core에 빌드 된 타사 serializer를 고려할 수도 있습니다. 아마도 질문을해야 할 것 같습니다. 특히 이진 직렬화 된 페이로드가있는 직렬화기를 찾고 있습니까 (그렇다면 왜) 아니면 관심있는 유형을 직렬화 / 역 직렬화 할 수있는 직렬화기를 찾습니까? 우리는 DCS, DCJS 및 XmlSerializer를 사용하여 대부분의 .NET 유형의 직렬화를 지원하기 위해 열심히 노력해 왔습니다. 이러한 serializer가 작동하지 않는 특정 문제가 발생하면 언제든지 알려주십시오.

@cdrnet 및 @ RichiCoder1 , 귀하의 의견에 감사드립니다. 예외 직렬화에 대한 논의에 대한 공개 문제 dotnet / coreclr # 2715가 있습니다. 거기에 피드백을 추가하십시오. 분산 시스템에서 예외를 직렬화 할 수있는 것이 중요하다는 데 동의합니다. 현재 .NET Core에서 ISerializable이 없으면 전체 .NET 프레임 워크 에서처럼 예외를 직렬화 할 수 없습니다.

안녕하세요 @zhenlan , 아마도 원래 언급 했어야 binaryformatter를 원하는 주된 이유는 예외를 (비) 직렬화하고 예외를 포함하는 사용자 정의 클래스입니다.

주요 사용 사례는 분산 시스템으로, 일부 객체를 바이트 배열로 직렬화하여 tcp / ip를 통해 전송할 수 있습니다. 예를 들어 JSON.NET을 통해 객체를 JSON으로 직렬화하는 것이 더 일반적이라는 것을 알고 있습니다. 예를 들어 해당 문자열을 바이트 배열로 변환하고 tcp / ip를 통해 전송하고 다른 쪽 끝에서 전체 프로세스를 한 번 되돌립니다. 그러나 이것은 바이트 배열로 직렬화하고 바이트 배열에서 원하는 객체로 역 직렬화하는 것보다 훨씬 더 많은 오버 헤드를 가지고 있습니다.

설명해 주신 @SamuelCox 에게 감사드립니다. 이제 당신의 우려를 이해 한 것 같습니다. 이진 직렬화는 가까운 시스템입니다. Xml 또는 JSON과 같은 다른 개방형 표준 기반 직렬화를 고려하는 것이 좋습니다. 지금은 필요하지 않을 수도 있지만 향후 서로 다른 플랫폼 또는 서로 다른 프로그래밍 언어 / 스크립트 간의 직렬화를 지원해야하는 경우 더 많은 유연성을 제공합니다. 데이터의 크기는 확실하지 않지만 페이로드의 크기가 정말로 문제가되는 경우 오늘날 많은 서버에 내장 된 기능인 데이터 압축을 고려할 수 있습니다.

나는 다른 무엇보다 성능 오버 헤드를 더 많이 생각했습니다. 객체에서 바이너리로 직접 직렬화 및 역 직렬화하는 것과 비교할 때 낭비되는 작업이 많이 보입니다. 나는 적어도 해명을 받았기 때문에 지금 이것을 종료하게되어 기쁩니다. 나는 여전히 여기에서 열린 4.6과 코어 1.0 사이에 간격이 있다고 생각하지만 그 이유를 이해합니다.

대화에 조금 늦었지만 여기에 내 두 센트가 있습니다.

BinaryFormatter의 유틸리티가 .NET remoting 및 AppDomains로 제한되어 있다고 믿는 것은 실수라고 생각합니다. (구식) BinaryFormatter와 최신 버전의 차이점은 클로저, 하위 유형 및 순환 그래프를 포함하여보다 이국적인 .NET 개체를 직렬화하는 순전 한 기능입니다. 현재 스레드에 나열된 다른 serializer는이 모든 작업을 수행 할 수 없습니다. Prajna 및 Mobius (일명 SparkCLR)와 같은 Microsoft 프로젝트를 포함한 많은 최첨단 분산 프레임 워크가 작동하기 위해 BinaryFormatter에 의존하는 것은 우연이 아닙니다. 이것은 .NET 세계에만 국한되지 않습니다. Spark는 클로저를 직렬화하기 위해 오래되고 느린 Java 바이너리 직렬 변환기를 사용합니다.

mbrace 프레임 워크에서 사용하는 자체 FsPickler 라이브러리를 포함하여 BinaryFormatter의 기능을 복제하는 다른 (이진 형식이 아닌) serializer가 있습니다. 그러나 CoreCLR은 라이브러리를 CoreCLR로 이식하는 것이 비실용적이라고 생각하는 한 많은 주요 API를 더 이상 사용하지 않습니다.

비즈니스 관점에서 CoreCLR이 분산 컴퓨팅 / 빅 데이터 영역에서 JVM에 대한 실행 가능한 크로스 플랫폼 경쟁자가되는 것을 보는 것은 좋을 것입니다. 이는 POCO 및 클로저 (이진 또는 기타)에 대한 안정적인 직렬화 지원을 제공하는 플랫폼 없이는 발생할 수 없습니다.

peope가 실제로 .NET Core를 사용하기를 원합니까, 아니면 Silverlight와 같은 시간 낭비입니까? 사람들이 실제로 .NET Core를 사용하기를 원한다면 제대로 작동하도록 만드세요. 사람들이 직렬화가 필요하면 구축하십시오. 이들은 실제로 귀하의 제품을 사용하는 사람들이며 그들의 의견은 모든 Microsoft 직원의 집단적 지혜보다 훨씬 더 가치가 있습니다. 이 사람들은 Microsoft와 달리 실제로 .NET에서 미션 크리티컬 항목을 빌드하고 있으며 .NET Core가 무엇이든 원하는 경우 그 유용성을 중단해야합니다. 아무도 당신에게 완전한 재 작성을 위해 .NET을 버리라고 요구하지 않았습니다. 당신은 시간이 지남에 따라 전체 .NET 프레임 워크를 포팅했을 수도 있습니다. 지금 쯤이면 끝났을 것입니다.

https://github.com/dotnet/coreclr/issues/2715 참조

fwiw, CSLA .NET 은 모바일 개체의 개념에 기반하기 때문에 완전 충실도 직렬화에 의존합니다.

Silverlight가 나오고 BinaryFormatter 또는 NetDataContractSerializer가 없었을 때 _and_는 이러한 모든 불쾌한 반사 제한이 있었기 때문에 최소한의 반사를 사용하고 BF 또는 NDCS에 의존하지 않는 자체 직렬 변환기 를 구현했습니다.

Silverlight 이후 세계에서는 BF / NDCS를 UWP, WinRT, .NET Core 등에서 안정적으로 사용할 수 없기 때문에 문제가 남아 있습니다.

그래서 나는 완전한 충실도 직렬화 기가 존재해야한다는 주장이 있다고 생각하지만 .NET의 모든 다양한 화신에 존재한다면 정말 유용합니다 (적어도 imo).

@rockfordlhotka @opinionmachine @eiriktsarpalis 더 많은 사람들이 똑같이 느끼는 것을 듣게되어 기쁩니다 . 이 문제가 종결됨에 따라 corefx 팀이 더 이상 모니터링하지 않을 것이라고 생각합니다. 나는 @forki에서 언급 한 바와 같이 DOTNET / coreclr # 2715에 대한 우려를 잘 할 수 좋을 걸

직렬화 (및 appdomains)를 삭제하는 것이 끔찍한 아이디어라는 데 동의해야합니다. 나는 그 결정이 잘 생각되지 않았다고 생각합니다.

그러나 정말로 나를 얻는 것은 MS가 appdomains 등을 지원하는 데 필요한 코드를 공개하지 않고 커뮤니티에 맡겨서 그들이 할 일을 처리한다는 것입니다.

coreclr이 .net의 "서버"버전이어야한다는 점을 감안할 때 많은 서버 기능이 바닥에 남아 있습니다.

적절한 사례 : StackTrace / StackFrame은 일부 개발자에 의해 "오용"되었고 거의 사용되지 않았기 때문에 corefx에서 제외하기로 결정했습니다 (MS에 따르면). 나는 그들이 그것에 대해 그들의 감각에 도달했다고 믿습니다 (엄청난 반발 후에) 그러나 내 말은 정말로? 누가이 물건을 생각합니까?

그만한 가치는 .net 코어가 정말 만족스럽고 .net의 큰 진전이라고 생각하고 성능 향상은 훌륭하며 여전히 내가 관심을 갖는 거의 모든 기능을 갖추고 있으며 크로스 플랫폼입니다. 이것이 제가 가진 유일한 문제입니다. 적절한 곳에 기능을 삭제하는 데는 많은 가치가 있습니다. 최소한의 접근 방식으로 얼마나 성공적으로 이동했는지 살펴보세요. .net이 최소한의 디자인이어야한다는 말은 아닙니다. 그건 우스꽝 스러울 것입니다. 저는 개인적으로 최소한의 디자인에 동의하지 않습니다.하지만 제가 말하고자하는 것은 MS가 특정 기능을 떨어 뜨렸다 고 비난해서는 안된다는 것입니다.

@SamuelCox , 감사합니다! :-)

그리고 다시 말하지만 여러 가지 이유로 .NET Core에서 API가 누락되었습니다. 이러한 틈새 중 일부는 쉽게 고칠 수 있습니다 (우리는 고칠 수 있습니다). 일부는 고치기가 더 어렵습니다. 그러나 우리는 당신이 겪고있는 문제들 (직렬화에 관한이 전체 쓰레드 세트와 같은)에 대해 여러분의 의견을 듣고 싶습니다. 그리고 우리는 여러분의 시나리오를 차단 해제하는 방법을 찾고 싶습니다.

단일 프레임 워크의 여러 버전에서 임의 개체 그래프의 이진 직렬화는 어렵습니다. 서로 다른 프레임 워크에서 더 어렵습니다. 그리고 '힘들다'는 것은 우리가 작업을 수행하는 것이 어렵다는 것을 의미하는 것이 아니라 보안, 성능, 신뢰성 등 플랫폼의 다른 목표 (우리 모두가 공유하는 목표)에 대해 상당히 광범위한 영향을 미친다는 것을 의미합니다.

Json.NET + TypeNameHandling.All + PreserveReferencesHandling.All + MemberSerialization.Fields는 거의 모든 방법을 제공합니다. FormatterServices.GetUninitializedObject는 없지만 생성자를 사용할 수 있어야합니다.

FormatterServices.GetUninitializedObject가 없습니다.

이것이 제가 생각하는 핵심 문제입니다. 외부 리플렉션 기반 직렬화 프레임 워크를 사용하면 큰 도움이 될 수 있지만 이러한 프레임 워크를 작성하려면이 특정 API가 있어야합니다. CoreCLR 팀에 대한 저의 권장 사항은이 API를 다시 추가하는 것입니다.

어느 시점에서 .NET 커뮤니티 (상업적 또는 기타)는 항상 손을 잡고있는 Microsoft에 의존하는 것을 중단해야 할 것입니다. 이것에 대한 엄청난 요구 사항이 있고 사용할 수없는 것으로 꽤 오랫동안 알려져 있었다면, 대안을 제공하기위한 커뮤니티 활동이 없었던 이유는 무엇입니까? Json.NET은 커뮤니티 대안이며 우리는 항상 그것을 사용합니다. 소스 코드는 참조 소스 에서도 사용할 수 있습니다.

다른 플랫폼에서도 잘 작동하는 것 같고 .NET에서도 잘 작동한다고 확신합니다. 제가보기에 이것은 프로젝트를 생성 할 수있는 최고의 기회입니다 (요구가있는 것 같음). 그 공백을 커뮤니티 대안으로 채우기 초기에

@thecodejunkie 를 원하지만,이를 위해 적절한 API를 노출하려면 여전히 런타임이 필요합니다.

참고 : 이것은 .NET Core에서 작동합니다 : Type appDomainType = Type.GetType("System.AppDomain"); . 그리고 네, 많은 일을 할 수 있습니다 ....

프런트 엔드 서버 응답 성을 30 % 향상 시켰고, 최대로드시 12 개 코어에서 최대로드시 2 개 코어로 줄였으며, redis 캐시 크기를 1.7Gb에서 350Mb로 줄였습니다. 전체적으로 Azure 호스팅을 20 % 줄였습니다 (비트 더 진짜)

BinaryFormatter를 짐작했습니다!

netdatacontractserializer를 사용했습니다.

BinaryFormatter를 사용하면 .Net 4.6.1이 훨씬 느려짐에 대한 답변을 찾고 있습니다.

이러한 API가 다시 돌아올 것이라는 점을 이해하고 있습니다 (직렬화). 이상적이지 않고 부서지기 쉬운 문제가 있지만 최소한 기존 코드가 계속 실행되도록해야합니다.

코어 프레임 워크를위한 또 다른 간단한 객체 직렬 변환기를 설계하는 것도 가치가 있습니다. 하나는 경량이지만 시스템 간 및 잠재적으로 버전 간 문제에 대해 더 탄력적입니다.

취약성 외에도 보안 문제가 있습니다.

@blowdart WRT 보안, https://blog.scrt.ch/2016/05/12/net-serialiception/ 과 같은 것을 의미

네, 그런 종류입니다. 유형을 포함하는 직렬화 형식은 Java가 올해 발견 한 것처럼 위험합니다. 전체 취약점 클래스를 제거했기 때문에 이진 직렬화를 삭제했을 때 매우 기뻤습니다.

트윗 담아 가기
Serializer는 물건을 보내는 것뿐만 아니라 in-proc에도 필요합니다.
바이너리 시리얼 라이저는 적절하게 수행되면 처리중인 수천만 개의 개체를 저장할 때 전체 네이티브 개체 힙보다 성능이 뛰어납니다.
이것 좀 봐:
https://www.infoq.com/articles/Big-Memory-Part-2

직렬화 API는 정상적인 클러스터 프로그래밍에 절대적으로 필요합니다.
개체 인스턴스 CLR-> 텍스트-> CLR을 텔레포트하는 것은 매우 불편하며 엄청난 오버 헤드입니다.
매우 느리고 데이터 그램이 거대하기 때문에 BinaryFormatter를 꺼내는 것은 실수가 아닐 수도 있지만
이는 전체 CLR 직렬화 의미 체계를 지원하는 NFX.Slim 외에 시장에서 유일한 직렬 변환기였습니다.
자세한 속도 및 크기 차트를 참조하십시오.
http://aumcode.github.io/serbench/

[OnSer / Deser] 제품군으로 ISerializable은 플랫폼 내 순간 이동에 많은 의미가 있습니다.
이전 NET과 마찬가지로 필수는 아닙니다. 보관하지 않으시겠습니까?
적어도 복잡한 컬렉션 (예 : 사전)에서 지원합니다. 전혀 어렵지 않습니다.

모든 사람이 JSON을 사용하도록 만드는 것은 바이너리 직렬 변환기 (BinaryFormatter가 아님)보다 시간이 느리기 때문에 절대적으로 나쁜 생각입니다.
모두가 비즈니스 로직없이 트위터와 유사한 앱을 만들고있는 것 같나요?

@itadapter 는 선택할 수있는 니트가 하나 있는데, 이는 JSON.Net이 마을에서 유일한 직렬화 게임이 아니라는 것입니다. MsgPack, Protobuf 및 Microsoft의 자체 Bond도 있습니다. (편집 : 두 번째 링크는 Protobuf를 호출합니다). Json이 유일한 옵션은 아닙니다. 그래도 흥미로운 의미론 (예외)으로 .Net 객체를 직렬화하는 데에는 여전히 큰 문제가 있습니다.

뿡 빵뀨
예, 물론입니다. 아래 차트에서 볼 수 있듯이 JIL은 가장 빠른 JSON 세릴 라이저이지만 텍스트 기반 시리얼 라이저는 바이너리를 건드릴 수 없습니다. Protobuf는 진정한 다형성과 복잡한 그래프를 지원하지 못하는 대신 매우 빠릅니다.

내가 말하는 것은 :

• 이진 직렬 변환기는 특히 숫자 데이터가 많은 경우 비즈니스 도메인 개체에 대해 항상 더 성능이 좋습니다.
• 일반적으로 직렬 변환기는 시스템간에 데이터를 이동하는 데만 필요한 것이 아니라 Big Memory 접근 방식이 보여주는 것처럼 프로세스 내부에서도 필요합니다. 일반적인 접근 방식은 아니지만 실질적인 의미가 있습니다 (예 : 캐시 및 메모리 내 소셜 그래프 탐색).
• "Teleportation"은 MS Remoting과 유사한 기술로 정직하게 망가졌습니다. 일반적으로 원격 작업을 올바르게 수행하면 (끔찍한 복잡성없이) 클러스터 시스템에서 매우 유용합니다. 우리는 항상이 접근 방식을 사용하며 기본 개체로 프로그래밍이 훨씬 더 쉽습니다. DOMAIN 개체를 가져 와서 그대로 다른 방법으로 보낼 수 있습니다.

인기있는 serializer를 보여주는 "Typical Person"의 벤치 마크 :
http://aumcode.github.io/serbench/Specimens_Typical_Person/web/overview-charts.htm

이 스레드의 누군가가 알지 못하는 경우를 대비하여 ISerializable 등의 바이너리 직렬 변환기가 corefx에서 제공되었습니다.
https://github.com/dotnet/corefx/tree/master/src/System.Runtime.Serialization.Formatters

@zhenlan 내가 생각하는 .NetStandard2.0 작업의 일부입니까?

@ RichiCoder1 네, 맞습니다.

@zhenlan은 훌륭합니다!

@zhenlan Standard 미리보기에서 사용할 수있는 직렬화 가능 속성을 찾을 수없는 것 같습니다. 나는 그것을 놓치고 있습니까?

@justinhelgerson 거기 있어야합니다.

공지 사항 블로그 게시물의 지침에 따라 2.0 Preview1 SDK를 설치 했습니까?

.NET Core 프로젝트를 만든 후 .csproj 파일에 클래스 라이브러리를 만든 경우 <TargetFramework>netstandard2.0</TargetFramework> , 콘솔 앱을 만든 경우 <TargetFramework>netcoreapp2.0</TargetFramework> 있는지 확인할 수 있습니까?

BTW,이 스레드의 많은 사람들이 이진 직렬 변환기에 관심이 있으므로 .NET Core 2.0의 [Serializable] 축소에 대한 dotnet / corefx # 19119에 대한 토론에 관심이있을 수 있습니다. 의견이 있으시면 저희에게 알려주십시오.

@zhenlan 빠른 답변에 감사드립니다. NuGet을 통해 미리보기를 설치했지만 .csproj 파일을 수동으로 업데이트하지 않았습니다. 그게 트릭이었습니다! 축소에 대해 읽고 사용 사례에 영향을 미칠 경우 입력을 제공 할 것입니다.

@justinhelgerson , 스케일 백 변경 사항은 미리보기 1에는 없지만 (아직 작업 중입니다!), 곧 일일 빌드 또는 향후 미리보기로 시도 할 수있을 것입니다.