왜 우리는 .NET의 많은 풍미를 가지고 있습니까? 좋은가요? [닫은]

.NET Framework 에는 많은 "맛"이 있습니다 .

• 전체 ( "일반")
• 클라이언트 프로파일 서브 세트
• 웹 브라우저의 Silverlight
• Windows Phone의 "Silverlight"
• 컴팩트 한 프레임 워크
• WinRT

새로운 플랫폼에서 C # 코드가 필요할 때 Microsot은 전체 CLR을 가져와 작은 하위 세트로 분류하여 BCL의 기존 어셈블리를 사용하는 대신 기존 어셈블리를 사용하는 대신 새 어셈블리를 만들고 유형을 이동하는 것을 선호합니다. . 예를 들어 Silverlight는 WPF와 동일한 구현을 단순히 참조하는 대신 WPF에 대해 다른 클래스 / 방법을 갖습니다 (서로 약간 다른 서명 또는 매우 다른 구현을 가진 일부 방법으로도) List<T>.

이것이 이상적인 아키텍처입니까, 아니면 레거시의 표시입니까? BCL이 각기 다른 프리젠 테이션 / IO 라이브러리를 가진 모든 플랫폼에서 실행되어서는 안됩니까? 아니면 BCL 및 기타 라이브러리가 너무 부풀어 있고 분리하면 너무 많은 이전 버전과의 호환성 문제가 발생합니까?

빈 캔버스에서 시작하여 이전 버전과의 호환성에 대해 걱정하지 않는다면 현재 상황이 실제로 여러 플랫폼을 처리하는 가장 좋은 방법입니까?

루틴을 여러 패키지로 나누는 Microsoft의 업무는 일반적입니다. 메모리가 제한된 단일 보드 컴퓨터 (.Net Micro Framework)에서 실행되는 .NET 버전이 있습니다. 예를 들어 전체 그래픽 사용자 인터페이스를 실행하는 데 필요한 모든 것을 해당 버전에 포함시키는 것은 의미가 없습니다.

Apple을 보면 iPhone에 Mac에서 찾을 수있는 모든 루틴이 포함되어 있지 않습니다.

.NET이 문제라고 생각하지 않습니다. 다양한 런타임이 있지만 여전히 호환 가능하므로 Portable Class Libraries 와 같은 기술이 작동합니다 (사용자가 나열한 대부분의 런타임에서).

예를 들어, 각 컬렉션마다 다양한 컬렉션 복사본이있는 자체 System.dll / mscorlib.dll 복사본이있는 각 런타임 대신 "System.Collections.dll"이라는 단일 공유 어셈블리를 참조하지 않아야합니까?

왜 이것이 필요한가요? BCL이 런타임 자체의 일부이고 함께 배포되므로 모두 호환 가능 (이동식 클래스 라이브러리 참조)하는 한 중요하지 않습니다.

.NET은 본질적으로 Windows 환경에서 com 객체를 대체하고 확장합니다. 또한 매우 다양한 기술을 식별하는 데 사용됩니다. Adobe가 모든 제품의 이름을 공통 이름으로 사용하도록 이름을 바꿨다면 .NET에서 발생하는 일입니다.