.NET Remoting은 정말 더 이상 사용되지 않습니까?

95

모두가 .NET Remoting이 WCF로 대체되는 방식을 말하고 있지만 그것이 얼마나 정확한지 궁금합니다. Remoting이 더 이상 사용되지 않는다는 공식적인 단어를 본 적이 없으며 Remoting이 WCF보다 더 의미있는 시나리오가있는 것 같습니다. Remoting 관련 개체 또는 메서드는 프레임 워크 버전 4.0에서도 더 이상 사용되지 않습니다. 3.5 및 4.0 프레임 워크의 System.AddIn이 Remoting을 사용한다는 것도 저의 이해입니다.

반대로 공식적인 말이있는 사람이 있습니까?

기사에서는 .NET에서 통신 옵션 선택 (즉,이 문서의 최신 버전의로, 3.0)를, 그 상태 :

8 교차 애플리케이션 도메인 통신

동일한 프로세스 내에서 다른 응용 프로그램 도메인에있는 개체 간의 통신을 지원해야하는 경우 .NET Remoting을 사용해야합니다.

물론 WCF를 사용하여 appdomain 경계를 넘을 수 있기 때문에 물론 정확하지는 않지만 해당 시나리오에 대한 공식 권장 사항을 제공합니까?

업데이트 : Clemens Vasters (Remoting 및 WCF를 소유 한 팀)에게이 질문을 보냈습니다.

클레멘스, 당신이 remoting과 wcf를 모두 소유하고있는 팀이라는 걸 이해하고, 소스로 가야 할 몇 가지 질문이 있습니다.

먼저 원격 기능이 사라지는 지 여부에 대한 질문이 있습니다. 특히, 우리는 in-process cross-appdomain 통신을 위해 광범위하게 원격을 사용하는 다소 큰 응용 프로그램을 가지고 있으며,이 원격 사용이 "레거시"로 간주되는지 궁금합니다. 그렇다면 AppDomain.CreateInstance 및 친구가 다른 것으로 대체됩니까?

이것이 그의 대답입니다.

Remoting은 .Net Framework의 일부이므로 사라지지 않습니다. COM은 Windows NT 3.5 / Windows 95 이후로 Windows에 있었으며 사라지지 않았으며 곧 사라지지 않을 것입니다.

즉, Remoting에 들어가는 개발 투자는 매우 적습니다. WCF는 Remoting의 후속 제품으로 COM / DCOM을 관리 코드로 대체합니다.

In-process의 경우 앱 도메인 간 통신 원격은 CLR의 기본 통신 방법입니다. 단시간에 많은 양의 데이터 또는 매우 많은 메시지를 펌핑하는 성능 문제가 발생하는 경우 WCF 및 NetNamedPipeBinding을주의 깊게 살펴 봐야합니다.

.net wcf remoting

— 표
소스

1

내 특정 상황에서 WCF가 Remoting보다 훨씬 느린 이유에 대한 질문은 stackoverflow.com/questions/1295353/… 을 참조하십시오 .

— Mark

1

Remoting은 .NET에 내재되어 있으며 역할 및 작동 방식에 대한 자세한 내용은 Don Box와 Chris Sells의 Essential .NET 에서 찾을 수 있습니다 . 그러나 구성 요소 간 통신이 신뢰할 수 없거나 느리고 거의 모든 전송 (기가비트 LAN 포함)이 프로세스 내 메시징에 비해 신뢰할 수없고 느리면 분리됩니다. 사람들이 WCF가 느리다고 말할 때 그들은 일반적으로 웹 서비스를 생각합니다. in-process 통신에 사용하려고하면 웹 서비스 가 너무 느립니다. 그러나 느리고 불안정한 연결을 허용하고 이러한 조건에서 잘 작동하도록 설계되었습니다.

— 피터은 wOne

3

@Peter : 정보를 제공해 주셔서 감사합니다.하지만 몇 가지 가정이 완전히 틀 렸습니다. 하나는 원격이 느리거나 신뢰할 수 없다는 것입니다. 그렇지 않습니다. 매우 빠르고 신뢰할 수 있습니다 (물론 신뢰할 수있는 채널을 통해). 다른 하나는 "웹 서비스"(그것이 무엇을 의미하든)가 느리다는 것입니다. 그들은 아니다. 물론, 진행중인 모든 것이 네트워크를 통한 어떤 것보다 훨씬 빠르지 만,이 질문에 대한 내용은 전혀 아닙니다.

— Mark

54

이를 레거시 기술이라고 부르는 것이 더 정확한 설명입니다.

http://msdn.microsoft.com/en-us/library/72x4h507%28VS.85%29.aspx

이 항목은 기존 응용 프로그램과의 역 호환성을 위해 유지되는 레거시 기술에 한정되며 새로운 개발에는 권장되지 않습니다. 이제 WCF (Windows Communication Foundation)를 사용하여 분산 응용 프로그램을 개발해야합니다.

업데이트 : WCF는 inter / intra / process / inter / intra-appdomain을 구분하지 않습니다. WCF에서 단일 컴퓨터 통신을 사용하는 경우 명명 된 파이프를 사용합니다.이를 사용하면 거의 모든 실제 시나리오에서 좋은 성능을 얻을 수 있습니다.

다양한 분산 통신 기술의 성능 비교는 여기를 참조하십시오 .

— RichardOD
소스

이 기사는 특히 프로세스 간 통신에서 원격 사용을 언급하지 않습니까? Remoting은 여전히 크로스 앱 도메인 통신 (AppDomain.CreateInstanceFromAndUnwrap 및 친구들)에 자리를 잡고있는 것 같습니다.

— Mark

네, 그렇습니다. 이러한 클래스가 "사용되지 않는"경우 ObsoleteAttribute가 msdn.microsoft.com/en-us/library/system.obsoleteattribute.aspx에 적용됩니다 .

— RichardOD 2009-08-18

2

@Mark, @RichardOD :이 기사는 .NET Remoting의 헤드 기사입니다. 프로세스 간 통신을 의미하는 것이 아닙니다. 또한 ObsoleteAttribute가 .NET 3.5에 없다는 사실은 Remoting (및 ASMX 웹 서비스)을 "레거시"로 발표하는 결정이 .NET 3.5 RTM 이후에 이루어 졌기 때문에 아무 의미가 없습니다.

— John Saunders

@John : 4.0에서도 [단종]으로 표시되지 않았습니다 (적어도 아직).

— Mark

@Mark : 4.0 베타 1 을 의미합니다 .

— John Saunders

11

예. Remoting은 더 이상 사용되지 않으며 Microsoft에서 공식적으로 제공합니다. 링크는 다음과 같습니다.

.NET Remoting

기사의 첫 번째 줄은 굵게 표시되어 있습니다.

이 항목은 기존 응용 프로그램과의 역 호환성을 위해 유지되는 레거시 기술에 한정되며 새로운 개발에는 권장되지 않습니다. 이제 WCF (Windows Communication Foundation)를 사용하여 분산 응용 프로그램을 개발해야합니다.

나는 말이 '사용되지 않음'이라고 생각했지만 분명히 '레거시'라고 언급했습니다.

— 저스틴 니스 너
소스

21

IMO 'deprecated'는 'legacy'보다 강력합니다. 'legacy'는 "시작하지 않음"을 의미하고 deprecated는 "이미 시작했다면 지금 중지하십시오. 향후 버전에서 완전히 제거 될 수 있으므로"을 의미합니다.

— ChrisW

1

@ 마크 : 나는 그렇게 읽지 않습니다. WCF는 Remoting과 마찬가지로 프로세스 내 통신에 적용 가능한 것으로 보입니다 (WCF의 NetNamedPipeBinding 참조).

— Michael Petrotta

1

@Mark : 어쨌든 Remoting은 더 이상 사용되지 않습니다. @ChrisW : 가까운 시일 내에 Remoting이 제거 될 것 같지는 않지만 버그 수정이 더 적고 지원이 더 적을 것으로 기대할 수 있습니다.

— John Saunders

1

@Mark-진짜 질문은 무엇입니까? 원격은 레거시 기술로 간주됩니다. 그것이 사실이기를 원하지 않는 것 같습니다. 그럴만 한 이유가 있을지 모르지만 그것은 실제로 Microsoft의 현재 권장 사항과 일치하지 않습니다.

— Michael Petrotta

1

@John : 그렇군요. 저는 특히 in-process cross-appdomain 통신 (AppDomain.CreateInstanceFromAndUnwrap 및 친구들 사용)을 수행하고 있으며 WCF를 사용하여 깔끔하게 (또는 고성능으로)이 작업을 수행하는 방법을 찾지 못했습니다. 대신 WCF를 사용하게되어 기쁩니다 (다른 시나리오에서 많이 사용합니다).하지만이 경우 원하는 방식으로 작동하는 데 문제가 있습니다. 특정 시나리오에 대한 또 다른 질문을 게시하겠습니다.

— Mark

6

.NET Core로 마이그레이션하려면 어쨌든 Remoting에 대한 다른 솔루션을 찾아야합니다.

.NET Remoting은 문제가있는 아키텍처로 확인되었습니다. 더 이상 지원되지 않는 교차 AppDomain 통신에 사용됩니다. 또한 Remoting에는 유지 관리 비용이 많이 드는 런타임 지원이 필요합니다. 이러한 이유로 .NET Remoting은 .NET Core에서 지원되지 않으며 향후 지원을 추가 할 계획이 없습니다.

출처 : https://docs.microsoft.com/en-us/dotnet/core/porting/libraries#remoting

— 장 클로드
소스

1

여기서 .NET Core에서 사용할 수있는 대안에 대한 토론을 찾을 수 있습니다. github.com/dotnet/corefx/issues/18394

— Jean-Claude

여기에서도 언급 됨 : docs.microsoft.com/en-us/dotnet/core/porting/…

— Jean-Claude

2

Microsoft .NET Service Bus의 기술 책임자 인 Clemens Vasters (즉, Remoting과 WCF 모두를 의미) 가이 포럼 게시물 에서 WCF와 Remoting에 대해 이야기 합니다. 게시물을 요약하기 위해 그는 Remoting보다 WCF를 권장합니다.

.NET 4.0이 내부적으로 원격 기능을 사용하는지 확실하지 않지만 Clemens에게 질문을 보낼 수 있습니다. 그가 답을 알고있을 것입니다.

— 요하네스 H
소스

11

Microsoft 직원이 어떤 형태의 표준보다 새롭고 다른 모든 것과 호환되지 않는 새로운 방법을 사용하도록 권장합니까? 충격적인.

— quillbreaker

14

WCF는 어떤면에서 다른 모든 것과 호환되지 않습니까? 그리고 Remoting은 무엇과 호환됩니까?

— John Saunders

2

호환성을 찾고 있다면 WCF가 유일한 선택입니다 (물론 asmx를 제외하고 "레거시"이기도합니다). Remoting은 호환성이 요구되는 시나리오에 적합하지 않았습니다.

— Mark

3

나는 당신의 제안을 받아들이고 클레멘스에게 물었다. 그의 대답 : "Remoting은 .Net Framework의 일부이므로 사라지지 않습니다. 프로세스 내에서 크로스 앱 도메인 통신 Remoting은 CLR의 기본 통신 방식입니다."

— Mark

1

그는 계속해서 "WCF와 NetNamedPipeBinding을 진지하게 살펴보아야합니다."라고 말합니다.

— John Saunders

2

이제 (2015) 교차 응용 프로그램 도메인에서도 매우 명확하다고 생각합니다. https://msdn.microsoft.com/en-us/library/vstudio/ms180984(v=vs.100).aspx

원격 AppDomains 간이 항목은 기존 응용 프로그램과의 이전 버전과의 호환성을 위해 유지되는 레거시 기술에 한정되며 새로운 개발에는 권장되지 않습니다. 이제 WCF (Windows Communication Foundation)를 사용하여 분산 응용 프로그램을 개발해야합니다.

그런 다음 교차 응용 프로그램 도메인에도 WCF를 사용해야합니다.

— 아르만도
소스