Runtime: System.Xaml을 .NET Core로 포팅

만세! 공식 인정/인정! 그리고 예, 나는 그 단어들이 "약속"과 동일하지 않다는 것을 알고 있지만 이것은 내가 지금까지 본 어떤 것보다 확실히 낫습니다. @terrajobst 당신은 나의 영웅입니다. :하트: :하트: :하트:

@cwensley 와 @SuperJMN , 여기 있는 모든 사람들 사이에 대화를 나누는 것이 좋을 것입니다. 이상적으로(내 관점에서) 모든 사람은 궁극적으로 새로운 Xaml 라이브러리의 하나의 포트/버전을 사용해야 하며 Xaml의 다른 버전/방언을 가지고 있지 않아야 합니다. 원격으로도 가능한가요? 그렇지 않은 경우에는 괜찮습니다. 하지만 가능하다면 가능한지 알고 싶습니다. :)

또한 저는 현재 "작업 안식년(대단한 고객 LOL)"에 있으며 플랫폼 간 Xaml만 3-4개월 동안 사용할 예정입니다. 나는 말 그대로 풀타임으로 일할 수 있고 필요한 경우 그 시간 동안 이 일을 도울 수 있습니다. 대의를 위한 모든 것(또한, 나는 좋은 타이밍을 위한 기회주의자입니다!)

System.Xaml이 오픈 소스라면 이 프로젝트의 요구 사항과 디자인 목표에 따라 커뮤니티가 이를 .net 코어로 이식할 수 있다고 확신합니다. 프로젝트 관리자는 커뮤니티를 안내하기만 하면 됩니다. .net 커뮤니티의 힘을 활용할 수 있습니다.

@Michael-DST, xaml의 한 방언이 중요하다는 데 동의합니다. 그러나 그 구현은 완전히 다를 수 있습니다. 단일 구현으로 표준화하는 것은 실제로 커뮤니티에 따라 다릅니다.

Mono의 우수한 System.Xaml(MIT 라이센스) 구현의 PCL 259/136 포트인 Portable.Xaml 의 경우, 많은 버그 수정이 있습니다. 아이디어는 동일한 API를 사용하여 MS의 System.Xaml이 수행하는 모든 작업(읽기/쓰기 포함)을 지원하는 것이지만 반드시 이에 국한되는 것은 아닙니다.

확장 기능의 예로 Portable.Xaml은 목록의 항목에 대한 형식 변환기 사용을 지원합니다. 여기서 System.Xaml은 다양한 형식을 지원하기 위해 사용자 지정 컬렉션을 사용하여 구현해야 하는 IList.Add(object)를 사용합니다.

@cwensley 나는 이것에 대한 무지를 주장하지만 .NET Core와 PCL의 차이점은 무엇입니까? 나는 그들이 같은 줄 알았는데? 즉, 특정 PCL 프로필로 설계했다면 .NET Core로 넘어갈 것이라고 이해했습니다... 이것은 얼마 전이었습니다(솔직히 저는 .NET Core에서 RTM/W로 전환되기를 기다리고 있었습니다). 그래서 지금은 새로 고침을 하기에 좋은 때입니다. :피

Portable.Xaml이 실제로 mono의 System.Xaml 포트인 반면 OmniXaml은 구문 분석 분야에서 새로운 인기를 누리는 처음부터 다시 작성했다는 것이 내 이해/감상입니다. 이상적으로는(내 자신의 관점에서) 어떻게든 둘을 병합하는 것이 좋겠지만 그것이 실현 가능하거나 두 기지 사이에서 바람직한지조차 확신할 수 없습니다. 내 생각에는(spelunking/analysis 없이) 기본적으로 하나(Portable.Xaml)의 성숙도와 다른 하나(OmniXaml)의 새로운 매력을 병합하는 것입니다.

이 게시물 에 따르면 @Michael-DST PCL 259는 실제로 .NET Core와 호환됩니다. Portable.Xaml용 nuget 패키지의 대상으로 이미 \lib\dotnet 를 포함했으므로 테스트하지는 않았지만 .NET Core에서 있는 그대로 사용할 수 있어야 합니다.

나는 OmniXaml을 조사할 시간이 없었지만 실제로 처음부터 다시 작성했다면 일이 완전히 다르게 수행되었을 것이라고 확신하기 때문에 두 프로젝트를 병합하는 것은 이치에 맞지 않을 수 있습니다. 또한 Portable.Xaml이 있는 그대로 대부분이 완전한 경우 그러한 이점이 있는지 확신할 수 없습니다. 내가 틀릴 수도 있지만 (;

:) 예, 여기에서 옵션을 탐색하고 있으며 실제로 오픈 소스 세계에 있다는 것에 대한 무지를 다루고 있습니다. 나는 같은 일을 하는 여러 코드베이스가 있다는 생각을 싫어합니다. 그리고 특히 Xaml 커뮤니티가 더 작기 때문에 처음부터 단편화되는 것은 짜증날 것입니다. 어쨌든, @SuperJMN 이 이에 대한 견해를 듣는 것이 좋을 것입니다. 나는 그가 그의 새로운 수정에 대해 꽤 확고한 것처럼 보였다는 것을 알고 있습니다. 예를 들어, 마크업 확장을 위해 IServiceProvider 대신 MarkupExtensionContext를 사용하면 기존 코드를 이 새로운 세계로 이식하려는 모든 사람에게 획기적인 변화가 될 것입니다.

명확히 하자면 모든 PCL 프로필은 .NET Core와 호환됩니다. 우리가 지금 가지고 있는 계약 세트와 팩토링은 PCL 프로필의 진화입니다. 이것은 .NET Core와 즉시 호환되지 않는 "이전 스타일" 이식 가능한 라이브러리(mscorlib 등에 대해 컴파일됨)에는 적용되지 않습니다.

@마이클 DST

@terrajobst 당신은 나의 영웅입니다. :하트: :하트: :하트:

귀하의 열정에 매우 감사드리며, 누구든지 이와 같은 요청을 제출할 수 있음을 분명히 하고 싶습니다. 문제를 제기하고 작업을 요청하기 위해 우리의 후원이나 승인이 필요하지 않습니다 :-) 나는 단지 시간을 절약하고 절름발이가 되지 않기 위해 직접 제출했습니다("버그를 신고하십시오") :-)

LOL @terrajobst 괜찮아요. 제 열정은 농담 반, 진지함 반입니다... MSFT는 수많은 투표 와 광범위한 대화 에도 불구하고 거의 1년 동안 이 문제에 대해 기본적으로 침묵했습니다.

따라서 거의 1년 동안 독방에 갇힌 사람의 문 아래로 식사를 밀어 넣는 것과 같은 일을 했는지 생각해 보십시오. :stuck_out_tongue:

[편집: 그 유추를 읽은 후(그리고 아래에 인용된 것을 본 후), 그것은 끔찍하고 아마도 당시 내가 읽고 있던 기사의 영향을 받았을 것이라고 말해야 합니다 -- 빌어먹을 뉴스, 왜 나에게 그렇게 영향을 미쳐야 합니까?! 더 나은/관련이 있는 사람은 아마도 1년 동안 연기를 뛴 후에 천사 라운드에서 매우 필요한 현금 주입을 받을 것입니다.]

참조: @Harikm86 , System.Xaml의 소유자

저는 XAML을 사랑합니다. Silverlight(예, 제가 말했습니다)에서 Windows Workflow, 그리고 이제 새로운 Universal App 플랫폼에 이르기까지 모든 것을 위한 훌륭한 선언적 언어입니다. Core로 이식하면 XAML에 의존하는 다른 기술을 이식할 수 있습니다. 우리는 이것이 필요합니다!

@rschiefer의 지원을 듣게 되어 기쁩니다! 입력해 주셔서 감사합니다. 아는 다른 Xaml 개발자가 이 스레드에 참여하고 대화/방향을 돕도록 하십시오.

저는 또한 Silverlight의 팬이며 2011년부터 Silverlight의 다음 구현을 추구해 왔습니다(뻔뻔한 플러그: Visual Studio 팀에 더 똑똑한 Silverlight 형태를 보고 싶다는 것을 알리고 싶다면 투표하고 그들에게 알려주세요. 여기 알아 ).

잠시 시간을 내어 "Xaml"이라고 말할 때 .NET 4.x+(또는 "System.Xaml")에 있는 Xaml 시스템/기능 집합을 열망해야 한다는 점을 확인하고 싶습니다. Silverlight 5의 Xaml도 실제로 가능합니다.

(물론 OmniXaml에서 발견된 새로운 개선 사항 을 추가하는 것도 바람직합니다.)

우리 모두가 그 이후로 고통을 겪었기 때문에 인턴 팀이 이식한 UWP의 "새", 나쁜 버전이 아닌 한(위의 내 게시물에서 언급한 투표 참조).

나는 그것을 "Xaml" 시스템이라고 부르는 것을 주저하기도 합니다. 왜냐하면 그것은 행운을 위한 추가 토큰 구문 분석이 있는 XML이기 때문입니다(분명히 필요함). 재미있는 사실: UWP의 Xaml 시스템은 궁극적으로 빌드 프로세스 중에 System.Xaml 어셈블리를 사용합니다. 음... #아이러니.

이상적으로는 이 포트가 배치되면 UWP Xaml 시스템이 더 이상 사용되지 않으며 대신 이 시스템을 사용합니다. 그런 다음 당황스러운 Xaml 역사의 장을 뒤로 할 수 있으며 많은 개발자가 기뻐할 것입니다.

Silverlight를 더 새롭고 더 나은 형태로 되돌리는 것도 나쁘지 않을 것입니다. :) :) :)

@마이클 DST

따라서 거의 1년 동안 독방에 갇힌 사람의 문 아래로 식사를 밀어 넣는 것과 같은 일을 했는지 생각해 보십시오. :stuck_out_tongue:

충분히 공정하다 :스마일:

@마이클 DST

나는 실제로 지금까지 많은 것이 변경되었다는 것을 알고 UWP를 피했고 UWP가 Xaml의 자체 "버전"을 사용한다는 것을 잊었습니다. 상기시켜주셔서 감사합니다.

전적으로 동의합니다. System.Xaml을 이식한 다음 실제 Xaml을 사용하도록 UWP를 수정할 수 있습니다.

전적으로 동의합니다. System.Xaml을 이식한 다음 실제 Xaml을 사용하도록 UWP를 수정할 수 있습니다.

@terrajobst 죄송합니다. 이제 @rschiefer에 새로운 영웅이 생겼습니다. :스마일: :스마일: :스마일:

토론해 주셔서 감사합니다. 이것은 나에게 매우 멋지다(그러나 나는 쉽게 감명을 받을 수 있었다!).

@Michael-DST @rschiefer

@helmsb 네! ㅋㅋㅋㅋ

웹(Angular.js), 앱(Android) 등을 위한 경쟁력 있는 Google의 인기 있는 머티리얼 디자인 기술인 FWIW도 오픈 소스로 제공됩니다. 이 주장이 상사와 상사 같은 존재를 설득하는 데 도움이 되기를 바랍니다.

@dsaf 무슨 말씀이세요?

FWIW 오늘 게시된 기사에서 이 문제를 언급했습니다. Is the Tide Turning on project.json? , 기술 및 MSFT 비즈니스/IP 관점 모두에서 .NET 개체를 설명하기 위해 Xaml이 선호되는 메커니즘을 살펴봅니다.

여러분, Xamarin 거래는 어떻습니까? 이 문제가 앞으로 몇 개월 동안 훨씬 더 바빠질 것이라는 소식이 있습니다. :웃다:

반드시는 아닙니다. UWP의 Xaml 또는 Xamarin의 Xaml 풍미가 일부 교차 플랫폼 라이브러리가 될 가능성이 높습니다. 이는 System.Xaml의 포트 또는 순수하게 관리되는 Xaml 구현이 발생하지 않을 수 있음을 의미할 수 있습니다.

Xamarin의 Xaml 시스템은 폐쇄적/내부적이지만 System.Xaml만큼 성숙하지 않습니다. 코드 자체는 다소 엉성합니다. 또한 POCO 직렬화 등을 수행하려는 경우 금지되는 BindingObject와 밀접하게 결합되어 있습니다.

그리고 위에서 설명한 것처럼 UWP의 Xaml 시스템은 끔찍합니다. 내가 모르는 것을 당신이 알고 있는 것이 아니라면 말이다. :stuck_out_tongue:

"순수 관리 Xaml 구현"이 의미하는 바를 설명할 수 있습니까? FWIW, 여기에서 기대하는 것은 System.Xaml의 직접적인 1:1 포트가 아니라 System.Xaml, Xamarin.Core.Xaml, 그리고 ... 글쎄, 나는 UWP의 Xaml이라고 말하고 싶지만... :wink:

내부적으로는 WPF와 Xaml보다 UWP의 Xaml을 선호한다고 들었지만 Microsoft의 팀마다 의견이 다를 수 있습니다. DotNet의 Xaml은 의심할 여지 없이 더 강력하고 유연하지만 UWP가 축소되는 이유가 되는 단점이 있을 수 있는 설명자의 모든 것과 마찬가지입니다.
그리고 순수하게 관리되지 않는다는 것은 DotNet 독점이 아니라는 점에서 UWP의 Xaml에 대한 한 가지 좋은 점을 언급하는 것입니다. 따라서 잠재적인 미래의 Microsoft.Xaml은 DotNet 외부에서 사용할 수 있도록 관리되는 파사드가 있는 플랫폼 간 기본 구현이 될 수 있습니다. (이 미래 라이브러리가 CoreFX의 구성 요소로 제공되도록 결정되지 않는 한 dotnet/corefx에 포함되지 않는 경우도 있습니다.)

알겠습니다. 혼란스럽습니다. .NET이라고 하면... 4.6을 말하는 거겠죠? 내 이해에 따르면 이것은 본질적으로 플랫폼 간 및 .NET(4.6) 전용인 .NET Core Xaml 라이브러리를 위한 것입니까? "DotNet 독점이 아님"이라고 말하면 "DotNet이 포함됨"을 의미합니까? 이중 부정. :stuck_out_tongue: 이것은 .NET 4.6에서 UWP Xaml을 사용할 수 없기 때문에 분명히 사실이 아닙니다.

내가 여기서 무엇을 잘못했는지 알려주세요. 또한 여기서 좋은 목표는 Xaml을 CoreFX의 일부로 제공하는 것입니다. 얼마 동안 이 문제를 둘러싸고 일부 토론이 진행되었습니다 . -- 그리고 확실히, @RichiCoder1 이 틀리지 않았다면 해당 스레드에서 정확히 이 작업을 수행하기 위한 투표가 있습니다... 전에 어디서 귀하의 태그를 본 적이 있는지 궁금합니다! :웃다:

또한 UWP의 Xaml에 대한 내부적인 성향도 들었지만, 그 스레드를 둘러싼 커뮤니티 토론이 시작되기 전이었습니다( Tim Heuer의 Twitter 토론 ). 바늘은 그 이후로 확실히 움직였습니다. 적어도 더 좋았습니다! ㅋ ㅋ ㅋ. "Xaml은 UI용"이라고 오해하는 사람들이 있고 나머지는 작동 방식을 이해하고 있습니다. :stuck_out_tongue:

DotNet이라고 하면 코어와 프레임워크를 포함하는 DotNet을 의미합니다. 그리고 UWP 앱 외부에서 UWP Xaml을 사용할 수 없다는 것을 알고 있습니다. C++ UWP 앱에서 사용할 수 있는 기능을 언급한 것입니다. 따라서 DotNet 독점이 아니라는 것은 C++(또는 잠재적으로 다른 언어)에서 사용하려는 것을 의미합니다. 그리고 XAML을 소유한 팀이 UI 외부의 사용 사례를 심각하게 고려하지 않는 이유는 드물거나 경우에 따라 Microsoft 또는 파트너와 적극적으로 비방하기 때문입니다. 제 개인적인 생각이 아니라 표현력과 힘을 높이 평가합니다.

알겠습니다. @RichiCoder1 설명해주셔서 감사합니다. 나는 지금 _거의_ 완전히 당신을 따르고 있다고 생각합니다... "프레임워크"라고 하면 4.6을 의미합니까?

내 생각에 내부 팀이 UI 외부에서 사용하는 것이 드물다고 느끼는 이유 중 일부는 Tim의 게시물에서 볼 수 있듯이 개발자와의 열악한 참여와 관련이 있다고 말할 것입니다. 나는 약 1년 정도 전까지 MSFT에 참여하는 것에 대해 정말 시끄럽지 않았기 때문에 이것에 대해 유죄입니다. 사실 Tim의 트윗은 내가 Windows 8.0 이후로 모든 사람에게 Xaml 시스템이 완전히 다르고 원래 있어야 하는 것과 다르다고 개인적으로/비공개로 불평한 후 내가 한 투표에 관한 것입니다. UWP(Windows 10) Xaml이 3년 동안 혁신이나 개선 없이 기본적으로 동일하다는 소문을 들었을 때 한 단계 더 올라갔습니다. 돌이켜보면 훨씬 더 일찍 했어야 했습니다.

그것이 중요한 배움의 교훈이었다고 말할 수 있습니다. 나는 이제 생태계에 훨씬 더 통합되어 있고 (또는 적어도 내가 그런 것처럼 느낀다) 내 목소리가 들리는 것처럼 느낀다. 사실, 4개월 조금 전에 내가 한 _매우 중요한_ 투표 가 이번 주 초 권위 있는 Visual Studio 팀에 의해 검토 중으로 표시되었습니다. 내 세상이 흔들렸다고 말하는 것은 절제된 표현입니다. :웃다:

프레임워크에서는 데스크탑 .Net을 참조하는 데 사용하고 있습니다. Core와 Full Framework를 구별하는 가장 보편적인 방법인 것 같습니다.

동의한다. Microsoft의 모든 최근 움직임에 대한 좋은 점 중 하나는 개발자와의 더 나은 참여를 거의 강요한다는 것입니다. :)

나 자신에 대해 매우 흥분! 이제 그 연극이 어떻게 될지 보기만 하면 됩니다. 이는 공유 프로젝트를 사용하는 UWP 앱을 제외하고 Xamarin 도구를 일류로 만드는 것부터 의미할 수도 있고 그보다 더 높은 수준을 의미할 수도 있습니다. 오직 시간(그리고 내 생각에 //Build)만이 알 수 있을 것입니다.

그렇군요... 정보 감사합니다. :+1:

//build에 관해서는... 참으로. :) 개인적으로 UWP를 기반으로 하는(느슨하게?) 새로운 Xamarin의 장점을 활용하여 iOS/Droid로 이동하는 새로운 모델을 보고 싶습니다. 더 강력한 Xaml 모델도 문제가 되지 않습니다. 결국 이 스레드를 4월 28일 이후로 조용히 유지해야 합니다. :stuck_out_tongue:

나는 당신이 그것을 할 수 있기를 바랍니다! :)

UWP 사용자는 .NET 코드를 풀인하지 않는 XAML 구현을 더 쉽게 채택할 것이라고 생각합니다(해당 코드가 .NET Core 항목이더라도).

자체 포함된 블랙박스처럼(또는 UWP에만 의존하지만 UWP는 [아직] 크로스 플랫폼이 아니므로 원하지 않습니다. Silverlight [앱을 Win10 대상으로만 잠글 수 없음]).

그러나 이것은 XAML의 다양한 응용 프로그램(UWP UI, Workflow, WPF/.NET, Silverlight 등)에 대한 추상화 계층 및 플러그형/드라이버를 사용하여 만들지 않는 한 다소 유토픽입니다. DirectX가 HAL(Hardware Abstraction Layer)을 통해 기계로 보이는 것처럼 HEL(Hardware Emulation Layer - http://www.developer.com/net/asp/article.php/968461/What에서 언급 참조)에 대한 가능성도 열어줍니다. -is-DirectX.htm). 물론 조심하지 않으면 성능면에서 지옥의 문을 열 수도 있지만 DirectX가 그것을 끌어낼 수 있기 때문에 그러한 아키텍처는 나쁘지 않다고 생각합니다.

System.Xaml을 .NET Core로 이식하기 위한 +1.
앞으로 모든 플랫폼에서 단일 통합 XAML 언어(.NET Xaml, UWP Xaml, Xamarin Xaml)가 사용되기를 바랍니다.
이를 달성하려면 .NET Core 버전의 System.Xaml이 필요하다고 생각합니다.

+1

대량 알림 알림을 피하기 위해 현재 주제에 대한 관심/반응을 표시하기 위해 GitHub에서 개별 댓글을 +1하는 새로운 방법이 있습니다.

하하 @jasonwilliams200OK 저는 강력한 크로스 플랫폼 System.Xaml 솔루션에 대한 기초적인 관심을 표현하는 커뮤니티 회원의 대량 알림 경고를 신경 쓰지 않습니다. :angel: 다른 주제로 여러분의 고통/성가심/불만을 공유할 수도 있습니다. :눈짓:

어떤 경우에도 유효(및 가치 있는) 포인트. 원인을 위해 내 :+1:을 추가했습니다.

@jasonwilliams200OK

불러주셔서 감사합니다!

FWIW, 방금 Xamarin.Forms 팀을 초대하여 여기에서 대화에 참여했습니다.
https://bugzilla.xamarin.com/show_bug.cgi?id=26740

또는 _여기_ 모든 사람이 _거기_의 대화를 알 수 있도록 하십시오. :웃다:

이 게시물의 댓글에서 훌륭한 토론이 진행 중입니다.
https://blogs.msdn.microsoft.com/dotnet/2016/05/06/net-core-rc2-improvements-schedule-and-roadmap/

기본적으로 Visual Studio에서 진행 중인 것으로 보이는 새 프로젝트 시스템에 대한 JSON 대 Xaml입니다(만세!). 부담없이 참여하세요. :) 이렇게 또 다른 모습을 하게 되어 기쁩니다.

@Mike-EEE, 이 로드맵도 살펴보세요: https://github.com/dotnet/roslyn-project-system/blob/master/docs/Roadmap.md. 새로운 Roslyn 기반 프로젝트 시스템은 .. 소중할 것입니다.

와...이제야 이 소식을 들으니 미쳤네요. 이것은 Scott Hunter가 향후 게시물에 나올 더 많은 정보와 관련하여 앞서 언급한 블로그 게시물에서 언급한 것임에 틀림없습니다. 보기 좋습니다. 로슬린의 힘이 커집니다. 하지만 Xaml 직렬화 프로젝트 정의에 대한 몇 가지 문제를 보는 것이 더 편할 것입니다. :눈짓:

해당 리포지토리의 추가 정보를 참조하세요. https://github.com/dotnet/roslyn-project-system#welcome -to-the-roslyn-c-and-visual-basic-project-system(및 VS MSDN 블로그 링크 ), MEF를 사용하여 다양한 구성 요소를 교체할 수 있을 것 같습니다. 그러면 XAML로 작성된 프로젝트 정의를 구문 분석하기 위해 추가 직렬 변환기를 삽입할 수 있습니다. 개인적으로 JSON이 덜 시끄럽기 때문에 프로젝트 속성 및 종속성 등을 설명할 때 XAML/XML보다 JSON을 선호하게 되었습니다(YAML은 JSON보다 덜 시끄럽고 lang 표준은 std-JSON과 달리 주석을 지원합니다. 그러나 dotnet 세계에서 들여쓰기 인식 구문을 사용하는 YAML 및 기타 언어는 아직 인기를 얻지 못하고 있습니다.

개인적으로 XAML/XML보다 JSON을 선호하게 되었습니다.

보안! 이 사람을 제거하십시오!!! 에헴, 내 말은... :)

나는 두 세계의 장점을 모두 누릴 수 있습니다. @SuperJMN 및 @Grokys 가 이에 대해 더 많이 말할 수 있지만 OmniXaml에서 덜 장황하고 수다스럽게 만들기 위해 노력하고 있다고 생각합니다.

내 문제 w/ JSON은 w/ JSON이 아니지만 .NET 구성의 기초이기도 한 디자인 접근 방식(이는 영감이라고 가정함), 즉 개체의 스키마는 "또 다른 아티팩트"입니다. 개발자는 클래스 정의를 관리/유지해야 하며 _not_ 해야 합니다. 즉, Xaml 프로그래밍에서(알다시피!) 클래스 정의는 문서 스키마 _is_입니다. 결과적으로 이것은 문서 개발에 매우 ​​자연스러운 느낌을 주고 도구화에도 도움이 됩니다.

개발자 정신은 말할 것도 없습니다. :smile: 불분명한 스키마 문서를 찾아 그것을 설치하고 가장 간단한 인텔리센스를 작동시키는 방법을 알아내는 것보다 나를 화나게 하는 것은 없습니다.

JSON과 관련된 다른 문제는 JSON에만 국한된 문제가 아니라 웹 사고 방식에 대한 것입니다. 바로 명명 규칙입니다. .NET 구성도 이 문제를 겪었습니다. 즉, 다음과 같이 POCO를 정의할 수 있습니다.

public class MyPoco {
    public string Property {get; set;}
}

그리고 JSON(또는 app.config)은 다음과 같을 것입니다.

{
 { "property": "Hello world I have inconsistent naming conventions!" }
}

여기서 다시 Xaml은 클래스 정의와 직렬화된 대응물 사이에 정렬되어 있기 때문에 Xaml을 선호합니다.

.NET 구성은 모든 구성 엔터티에 대해 4개의 아티팩트를 생성했기 때문에 .NET 구성이 최악이라고 말해야 합니다.

1. web/app.config의 요소
2. 어떻게든 마술처럼 web/app.config에 연결해야 하는 .xsd 파일(이것이 작동하지 않습니다!)
3. ConfigurationElement 및/또는 ConfigurationSection 요소는 app/web.config에서 값을 가져오고 일관성이 없는 camelCase를 PascalCase에 매핑했습니다 -- 오 미친!
4. 궁극적으로 구성 요소에서 연결된 POCO입니다. (아휴!)

.JSON 문서로 직렬화되는 POCO 개체가 있는지 또는 위에 설명된 관련 없는 매핑도 발생하는지 알만큼 JSON의 프로젝트 디자인을 연구하지 않았습니다. 이에 대한 답을 알고 계시면 듣고 싶습니다.

어쨌든 Xaml은 두 개의 아티팩트만 필요로 하여 이 디자인을 개선합니다.

1. 클래스 파일(.cs)
2. 데이터 파일(.xaml)

마지막으로 읽어보기에 대한 링크를 제공해 주셔서 감사합니다! 나는 파일이 요구하는 바로 그 일을 하지 않는 "저 사람"을 다시 한 번. :웃음:

.JSON 문서로 직렬화되는 POCO 개체가 있거나 위에 설명된 관련 없는 매핑도 발생하는 경우입니다. 이에 대한 답을 알고 계시면 듣고 싶습니다.

[DataContract] 및 [DataMember] 속성을 고려하면 .NET 프레임워크(BCL 수준에서)가 JSON 및 기타 데이터 serailizer를 지원하고 있다고 생각합니다. 그러나 JSON에서 JavaScript(및 기타 많은 언어)로 또는 CSON에서 CoffeeScript로 컴파일러에 의한 네이티브/로우레벨 JavaScript 객체 리터럴 <-> C# POCO 전환 지원은 없습니다. 그러나 모든 XPATH XQUERY XSLT 연결이 있는 XML과 달리 JSON에는 데이터 유효성을 검사하는 스키마 개념이 있으며 JSON.net은 이를 챔피언처럼 지원합니다.

C#6 이상의 경우 다음 문제/제안을 살펴보십시오. https://github.com/dotnet/roslyn/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+author%3Agafter+ 사전 , 특히 https://github.com/dotnet/roslyn/issues/6949 및 내부 링크를 따르십시오. 새로운 C#6 딕셔너리 이니셜라이저 구문과 이러한 제안으로 C#은 의미상 JSON에 더 친숙해지는 것처럼 보입니다.

.NET 구성이 최악이었습니다.

동의합니다. ASP.NET 팀에서 플러그 앤 플레이 패키지로 도입한 "구성" 및 "IOption" 패턴도 즐길 수 있습니다. https://github.com/aspnet/Configuration , https://docs.asp.net/ en/latest/fundamentals/configuration.html , 악명 높은 XML 바인딩 구성 관리자를 대체합니다.

JSON은 데이터의 유효성을 검사하는 스키마 개념이 있으며 JSON.net은 이를 챔피언처럼 지원합니다.

스키마로서의 클래스 정의처럼 들립니다. :) :) :)

C#이 의미적으로 JSON 친화적이 되고 있는 것 같습니다.

하하 물론 _any_ 객체는 이미 JSON 친화적입니다. JSON은 의도한 작업을 수행하는 데 적합합니다. 간결하고 사람이 읽을 수 있는 방식으로 객체 정의를 표기합니다. 그리고 JSON.net이 이 목표를 달성하는 데 큰 역할을 한다는 데는 의심의 여지가 없습니다. _applications_에 대해 설명할 때 더 나은 단어가 없기 때문에 이 대화가 시작되는 영역으로 들어가기 시작합니다. :웃다:

결국 여기에는 (적어도 나에게) 두 가지 시나리오가 있습니다. 서비스 경계 간에 전송될 개체를 설명하는 것(경량)과 이러한 개체를 만드는 응용 프로그램을 설명하는 것(중요함)입니다. 저는 개인적으로 가능한 모든 면에서 일관성을 유지하고 컨텍스트 전환을 최소화하는 것을 좋아합니다. 옵션( IOptions ? :laughing:)을 열어두고 개발자가 자신에게 가장 적합한 형식을 선택하도록 허용하는 한(그리고 가장 효율적이라고 느끼게 하는 도구를 사용할 수 있습니다! ) 그러면 우리 모두가 여기서 이깁니다. :+1:

UWP XAML은 클래식 .NET WPF XAML에 비해 기능이 적습니다. 내가 가장 그리워하는 기능 중 하나는 TypeConverters입니다.

https://msdn.microsoft.com/en-us/library/bb546926 (v=vs.90).aspx(이 기사는 WPF TypeConverters용)에 제안된 대로 고유한 TypeConverter를 만들려고 했습니다.

UWP 에서는 "XML 네임스페이스 ' using:App2TypeConverters '의 알 수 없는 유형 '자동차'"가 표시됩니다.

        <ListBox>
            <local:car></local:car>
        </ListBox>

UWP에 사용자 지정 TypeConverter를 추가할 수 없나요? 아니면 해결 방법이 있습니까? XamlCompiler가 내부 IServiceProvider를 사용하여 TypeConverter를 등록한다는 내용을 읽었습니다. 어쩌면 그것은 어떻게 든 등록 될 수 있습니까?
또한 XAML 컴파일과 관련된 배경 지식에 대해 더 알고 싶습니다. XAML은 여전히 ​​BAML로 생성됩니까? 어떻게든 XAML 컴파일에 연결할 수 있습니까?
따라서 System.Xaml을 여십시오.

Sooooooo... 이것은 System.Xaml이 마침내 파티에 참가한다는 것을 의미합니까? :스마일: :스마일: :스마일:
https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it-easier-to-port-to-net-core/

나는 여기로 들어가 다음과 같이 말할 것이다.
a) .Net Core와 함께 실행되는 XAML을 정말 좋아하고
b) 그런 일이 발생 하면 이미 다른 아키텍처(예: Raspberry Pi의 IoT 푸시)로 이식되고 있으므로 UWP 풍미를 사용하는 것이 가장 합리적입니다.

WPF XAML을 얻는 것은 가능하다면 놀랍습니다.

.NET Core가 기본적으로 처음부터 다시 빌드된 것과 같은 방식으로 지난 10년 간의 학습을 기반으로 XAML도 동일하게 수행되어야 한다고 생각합니다. 진화 WPF/Silverlight/WinRt-XAML은 완전한 실패였습니다. 한 걸음 앞으로, 두 걸음 뒤로(한 걸음은 옆으로). XAML, Expression Blend 등의 약속은 실현되지 않았습니다.

저는 Scott Hunter가 "글쎄, 결코 좋은 결과를 내지 못합니다. Windows 사용자는 Windows 모양의 버튼을 기대하고 Mac의 Mac 버튼을 기대합니다"라고 말하면서 Dotnet Core에서 플랫폼 간 UI를 사용하지 않는 것을 정당화하는 것을 들었습니다. 글쎄요 죄송합니다 - 그는 지난 5년 동안 어디에 있었나요??? 웹은 현재 UI 디자인을 완전히 지배하고 있으며 웹에는 "표준 버튼"과 같은 것이 없습니다. 하지만 어떻게 될까요? 사용자가 해결했습니다. 그 주장은 단순히 모든 증거에 반대합니다. 이러한 웹 UI는 이제 지구상의 상거래를 지배합니다. 그러나 분명히 Dotnet Core에는 충분하지 않습니다. [상상의] "표준 플랫폼 모양과 느낌"에 대한 열망 없이 크로스 플랫폼 XAML을 가질 수 없는 이유는 무엇입니까?

내가 추정하는 주요 기술 장애물은 "XAML"(또는 차세대 UI 플랫폼이 호출되는 모든 것)을 크로스 플랫폼 3D API와 인터페이스하는 방법입니다. MacOS 등에서 Direct3D/Direct2D에 의존할 수는 없기 때문입니다. 이 문제는 그 목표를 달성하는 Unity 등에 의해 해결되었습니다.

XAML 기술 제품군을 오픈 소싱하는 주제에 대해 Microsoft에서 너무 많은 노력을 기울였습니다. 그 안에 숨겨진 비트코인 ​​또는 microsoft.com의 개인 키가 있는지 궁금해야 합니다.

MSFT: 오픈 소스 WPF/Silverlight/WinRT-XAML을 실행하고 UX의 다음 황금 시대를 시작하십시오.

Scott Hunter, @JackUkleja에 대한 귀하의 의견을 들으니 정말 놀랍습니다. 이에 대한 소스/링크가 있습니까? 당신이 말하는 것이 사실이라면, 당신이 말한 것 외에도 여러 측면에서 (놀라운) 무지를 보여줍니다.

1. 이것이 바로 Xamarin.Forms가 해결하려고 시도한 것입니다.
2. 플랫폼별(또는 그대로 흉내내기) UX/상호작용/스타일은 테마로 해결할 수 있고 해결해야 하는 문제입니다. 이것이 WPF가 매우 잘한 일입니다(당신의 관점에서는 개선될 수 있고 개선되어야 하지만).
3. 최악의 경우, 이것은 틀림없이 역사상 가장 훌륭한 프레젠테이션 프레임워크인 WPF를 성공적으로 만든 인재 풀을 신뢰하지 않는다는 것입니다. 더 이상 이 문제를 해결할 수 없다는 말씀이신가요? 아니면 최소한 WPF를 플랫폼 간 방식으로 성공시킨 동일한 마법을 사용하시겠습니까?

좋은 UX는 좋은 UX입니다. 당신이 지적했듯이 웹은 이것을 명확하게 보여줍니다. 기본 응용 프로그램 사용자는 기본 인터페이스에 대한 특정 모양과 느낌에 확실히 적응되어 있지만 다시 한 번 이것은 테마에서 해결할 수 있어야 합니다.

iOS 기기에서 Droid "스킨"(동작 포함)의 애플리케이션을 볼 수 있고 그 반대의 경우도 있다고 상상해 보십시오. 이것은 WPF에서 가능했으며 앞으로 계속 수행되어야 하는 바로 그런 종류의 생각입니다. 즉, 모양/느낌/경험이 애플리케이션을 개발하고 디자인하는 데 방해가 되어서는 안 됩니다. 테마를 적용할 수 있어야 하며 "그냥 작동합니다." 이것은 불행히도 Xamarin.Forms에 대한 비방이었습니다. 다른 플랫폼을 설명하지만 각 대상 플랫폼에서 모든 것이 예상대로 작동하는지 확인하는 것과 관련된 많은 마찰이 있습니다.

@Mike-EEE Scott Hunter가 이 dotnet Rocks 에피소드에서 그런 효과에 대해 말한 것이라고 확신합니다: https://www.dotnetrocks.com/?show=1291

답장:

"역대 최고의 프레젠테이션 프레임워크인 WPF를 성공적으로 만든 인재 풀"

...WPF와 관련된 많은 사람들이 MSFT를 떠나 Google로 이동하여 Angular와 관련되어 있는 것으로 알고 있습니다. WPF의 많은 아이디어가 Angular 및 템플릿과 같은 관련 프레임워크에 나타나고 있습니다. 그러나 이러한 웹 프레임워크를 어떤 방식으로 분할하든지 간에 항상 백그라운드에서 HTML/CSS의 냄새가 날 것이라고 생각합니다. 모든 UI가 문서/의미론 기반이라는 것이 말이 되는 것은 아니며 이것이 HTML의 특성이기 때문에 세상이 여전히 "XAML 코어"를 사용할 수 있다고 생각합니다.

[잭... Google 및 WPF 설계자에 대한 데이터가 정확하다고 생각하지 마십시오.]

@rrelyea 그건 내 이해 였지만 내가 실수했을 수 있습니다. 나는 WPF 팀 중 일부가 Angular에서 작업했다는 것을 읽었다고 맹세할 수 있었습니다. Ian Ellison-Taylor 는 무엇입니까? (지금은 MSFT로 돌아온 것 같지만...)

백그라운드에서 HTML/CSS의 냄새

통합 HTML CSS 표준 또는 이와 관련하여 모든 종류의 표준(C, C++, JavaScript)에 대한 준수 및 수렴이 많을수록 이 세상은 더 나은 곳이 될 것입니다. 고유한 기능을 가진 XAML 대신 HTML+CSS 스택 등에 대한 상위 집합 프레임워크로 또는 단순히 ASPNET의 Razor에 대한 대체 프런트 엔드 엔진으로 렌더링할 수 있습니다. https://github.com/aspnet/Razor/issues/78 : 구근:

@jasonwilliams200OK FWIW/FYI에는 이미 JSIL 에 .NET의 HTML/CSS "표준" 포트가 있습니다. 모든 출력은 100% HTML5와 호환되며 모든 최신 브라우저에서 실행됩니다. 이것은 물론 우리가 열망해야 하는 종류의 생각입니다(그리고 2011년 Silverlight가 중단된 이후로 생각해야 하는 생각이었지만 저는 이만).

즉, (당신의 요점까지) 이상적인/요청은 .NET 개발자가 .NET/C#/F#/VB.NET만 처리해야 하고 CSS/HTML/JS를 만질 필요가 없다는 것입니다. Xamarin .NET 개발자는 iOS/Droid의 토대를 건드릴 필요가 없습니다.

@Mike-EEE, 상위 집합 언어(TypeScript에서 JavaScript로 또는 Less에서 CSS로)에서는 동일한 파일의 상위 집합에서 하위 집합 lang 코드를 사용할 수 있지만 그 반대는 사용할 수 없습니다. 따라서 수퍼 세트의 개념은 폰갭, 코르도바 등이 작동하는 방식을 약간 넘어선 것입니다. :)

하하 예 @jasonwilliams200OK 저는 .NET을 브라우저로 다시 가져오는 우리의 접근 방식/전략에 대한 특별한 경우를 만들지 않도록 하고 싶습니다. CSS/JS를 만지는 것은 바이너리를 만지는 것과 같은 경멸로 보아야 합니다. :stuck_out_tongue:

예를 들어 Xaml(yay)을 사용하지만 TypeScript(boo)에도 의존하는 또 다른 프로젝트 Fayde 가 있습니다. 이것은 궁극적으로 두 개의 호환되지 않는 코드 기반(클라이언트 코드용 TypeScript/JS, 다른 모든 코드용 .NET)으로 끝나므로 시간과 리소스 모두에서 매우 비쌉니다.

ASPNET의 Razor에 대한 대체 프론트 엔드 엔진

Razor는 제 생각에 템플릿 엔진일 뿐입니다. 실제로 해당 링크에서 "...코드에 대한 프론트 엔드 템플릿 엔진의 긴 목록에서 선택할 수 있습니다."라고 언급했습니다.

HTML 페이지 내에서 Razor와 같은 특수한 C#과 유사한 구문에 대해 MS로부터 몇 가지 의견을 들었습니다. 대신 사용자 지정 태그를 사용하는 프레임워크를 선호합니다.

btw, Bridge.net(http://bridge.net) 및 Fayde와 같은 XAML 솔루션과 결합할 수 있는 기타 C# to Javascript 컴파일러도 있습니다.

HTML5/JS/etc에서 다시 XAML. WPF를 다시 구현하는 흥미로운 프로젝트 Granular 가 있습니다. Saltarelle을 사용하여 JS로 컴파일합니다. 실제 예가 여기 에 있습니다.

Granular는 정말 환상적입니다. @ethanhs. 제가 미처 몰랐던 부분입니다. CSHTML5 , JSIL, Bridge.net( @birbilis 가 언급함)과 동일한 접근 방식을 취했기 때문에 실제로 유일하게 실행 가능한 PCL을 사용하여 서버와 클라이언트 간에 코드를 공유할 수 없다는 동일한 문제를 겪고 있습니다. 요즘 하는 방법.

그리고 실제로 그 프로젝트가 훌륭해 보이긴 하지만 Silverlight의 종말 이후 .NET 개발자들이 견뎌야 했던 지옥 같은 상황을 거의 요약한 것입니다. 그것과 약 12명의 다른 사람들 은 브라우저에서 .NET이 작동하도록 "다소" 작업을 수행하지만 Silverlight 경험이 있는 사람들이 기대하는 전체 경험은 아닙니다.

개발자가 Silverlight를 잊게 만드는 단일한 통합 솔루션은 아직 없습니다. 하지만 우리는 점점 가까워지고 있습니다. 적어도 바랍니다. WebAssembly는 유망해 보이지만 한동안 중요한 발전을 보거나 듣지 못했습니다. JSIL 기반 포트/이니셔티브 는 다소 느려진 것으로 보이며 지난 10월 이후로 체크인이 없었습니다.

가까운 장래에 여기에서 돌파구가 있기를 바랍니다. 내년 //build에서 이와 같은 발표를 보고 싶습니다. :하트: :+1:

그것은 XAML에 일어난 지난 몇 년 동안 최고의 일 중 하나가 될 것입니다.
여기에서 투표하세요!

쿨 @bbougot. 거의 15개월 동안 존재한 후 _마침내_ 약간의 관심을 받은 또 다른 투표도 있습니다. 시작하기 위해 끔찍한 Xaml 시스템을 인식하지 못한 거의 3년 동안 계산하지 않았습니다.
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

(진심으로, 가장 명백한 문제에 대한 투표를 인정하는 데 15개월? UWP 팀은 거기에서 무엇을 하고 있습니까? Visual Studio 또는 .NET 팀은 언제 그 배를 인수하고 바로잡을 것입니까? 무엇을 . .. 앗, 그렇군요 방황하고 있었습니다...)

또한 이 스레드에 투표하는 것을 잊지 마십시오. 특히 GitHub 반응과 같은 멋진 편의 시설이 있기 전에 이 문제가 시작되었다는 점을 고려하면 현재 @ 60에서 꽤 잘 작동하고 있습니다. :웃다:

Xaml은 전체 클라이언트 생태계를 통합할 수 있는 잠재력을 가진 유일한 것입니다!
DirectX를 없애고 OpenGL을 안아주세요!
UWP는 PC에서, 전화로, 웹사이트에서 실행됩니다!
비바 잠!

자, 여기 @terrajobst , @harikmenon 및 @karelz 에 시민 질문이 있습니다(최근에 태그를 추가한 것을 보니 축하합니다. 이 질문에 참여하겠습니다!). 단순한 호기심에서 나는 약간의 모험을 하고 이 리포지토리에서 고급(또는 아닐 수도 있는) GitHub 필터링을 확인하기로 결정했습니다. 다른 문제에 대해 많은 표가 있고 그렇지 않은 경우가 있다고 생각합니다.

내가 사용하는 URL은 다음과 같습니다.
https://github.com/dotnet/corefx/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

이 문제에는 현재 82개의 찬성 투표가 있는 것 같고, 내가 맞다면 목록에서 다음으로 가장 가까운 항목은 17입니다. 따라서 이 문제는 이 리포지토리에서 가장 많이 요청/투표된 문제가 됩니다. 맞습니까?

그렇다면 이것이 우선 순위 및/또는 계획과 관련이 있는지 궁금합니다. 분명히 이것은 지금 _매우_ 인기 있는 질문/항목인 것 같습니다(다시, 내가 올바르게 이해한다면). 따라서 아마도 진행 상황에 대한 대화를 시작할 가능성과 관련하여 업데이트나 확인을 듣는 것이 좋을 것이라고 생각합니다. 이 문제는 가능성이 있습니다.

여기에서 관점/맥락을 얻는 것이 좋을 것입니다. 그리고/또는 고객 요구와 관련하여 완전히 오해된 것이 있는 경우. 그것은 일어난다. 😄

당사의 .NET Core 엔지니어는 .NET Standard 2.0(또한 높은 고객 요구 사항)에 중점을 두고 있습니다. 여기 및 여기에서 세부 정보를 참조하십시오. .NET Core를 최신 표준으로 만든 후 해당 목록에 없는 다른 라이브러리를 살펴보겠습니다.

upvotes 쿼리를 지적해 주셔서 감사합니다!

@karelz 답변 감사합니다! 매우 감사. 👍

👼 👼 👼 좋아요/리트윗 하실 분 계실까 해서 글 남깁니다. 👼 👼 👼
https://twitter.com/MikeEEE76/status/776769805722521600

저는 .net 버전 3부터 xaml을 사용해 왔으며 Silverlight의 축소와 죽음까지도 느꼈습니다. 나는 개선을 위한 변화를 좋아하는 사람입니다. 그러나 이제 UWP를 사용하여 앞으로 나아가는 대신 퇴보를 찾습니다. 모든 새로운 기능은 훌륭하다고 생각되지만 데스크탑 앱과 같은 완전한 xaml 지원이 부족한 경우에는 신경쓰지 마십시오. 나는 UWP에서 새로운 앱을 만들려고 노력했고 내가 배운 모든 것이 다시 변경되었다는 어려운 방법을 배웠습니다. xaml 라이브러리가 어디로 이동했는지에 따라 온라인에서 많은 지원을 찾을 수 없습니다. 예를 들어 프레임워크 아래에 있던 표시기가 더 이상 거기에 없고 x:static이 작동하지 않는 속성에 대해 몇 시간 동안 검색하여 예제를 찾거나 수행할 작업을 찾아야 합니다. 이전 xaml에서 새 UWP로 표시하는 링크가 없습니다...

@giworking MS가 클라이언트 개발에 신경을 써야 하는 것은 당연합니다! Satya Nadella의 말처럼 azule은 MS의 핵심이자 미래입니다. azule을 높이는 가장 강력한 에너지는 전체 .net 생태계입니다. 자바에 비해 클라이언트 쪽은 코더와 기업이 MS의 클라우드를 수용하도록 설득하는 거의 유일한 무기입니다(중국에서 .net은 정말 치명적인 상황에 처해 있습니다. 사람들은 자바에 대해 이야기하고 "f k s t xamarin이 무엇인가요?"라고 반응합니다. ....). 그래서 중국 코더로서 xamarin, uwp, typescript 및 cshtml5를 볼 때 전체 클라이언트 측을 xaml+C# 모드로 통합할 수 있다는 것을 알고 있지만 왜 우리 MS 친구들은 if로 중국 시장 점유율을 되돌리세요?

와우, 이 문제는 이제 100개 이상의 추천을 받았습니다! 지지를 보내주신 모든 분들께 진심으로 감사드립니다. 관심 있는 사람이 있다면 @terrajobst 의 엄청난 상표 개발자 참여가 포함된 정말( 정말로! ) 훌륭한 기사가 여기 댓글에 있습니다.
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

(진심으로, 회사 기반 블로그 게시물을 게시하는 모든 MSFT 직원은 게시 방법에 대한 Landwerth 씨의 지시를 따라야 하며 이후에 발생하는 불가피하고 셀 수 없이 많은 댓글에 후속 조치를 취해야 합니다. 너무 많은 MSFT 작성자와 마찬가지로 단순히 게시물이 마르도록 내버려두고 질문을 죽은 사람으로 남겨 두십시오. 물론 이는 청중을 대하는 끔찍한 방법입니다!)

어쨌든, 아직 읽지 않았다면 특히 댓글을 읽을 가치가 있습니다. 이것은 내가 지금 게시하는 이유를 _System.Xaml을 .NET Standard/교차 플랫폼 시대로 가져오려는 열정/열망과 함께 댓글에 언급된 이 문제를 보게 되어 매우 기쁩니다_. 👍

154개의 찬성표... 그리고 계산 중입니다. 😎 그 다음으로 높은 호는 25 화 입니다. #squeakywheel

이 작업을 수행해야 합니다. 어서 타!

수만 명의 Windows 7 사용자를 위한 최초 다운로드/설치 경험을 극적으로 개선하기 위해 .NET Native를 사용하려는 WPF를 대상으로 하는 @ReactWindows 애플리케이션이 있습니다. 또한 React Native를 Linux로 가져오고 잠재적으로 @ReactWindows 공유 코드를 재사용하지만 Xamarin.Forms를 대상으로 할 계획이 있습니다.

NETCore vNext에서 사용할 수 있는 System.Xaml(및 WindowsBase, PresentationCore 및 Xamarin.Forms의 기타 형식/메서드/어셈블리 종속성)이 이 전략에 중요합니다. 기존 어셈블리를 다시 작성하고 대상을 다시 지정하거나 Mono의 System.Xaml에서 누락된 유형/메서드를 채우고 .NET Core용으로 빌드하여 이 결함을 해결할 수 있지만 실제로는 Microsoft가 한 단계 더 나아가 다음을 제공하는 것이 좋습니다. 플랫폼에 필요한.. /cc @rozele @pre10der89

@matthargett 행운을 빕니다. .net 코어에 워크플로를 가져오는 것을 검토할 때 이 문제를 완전히 해결했습니다. 심지어 xaml 팀에 연락하기까지 했습니다. 그들은 System.Xaml을 여는 데 원격으로 관심조차 두지 않습니다. 이유를 모르겠습니다. 보호할 가치가 있는 것은 전혀 없습니다.

4월 말에 2.0 릴리스 이후에 고려될 수 있습니다.

여러분, 다시 말하지만 WF를 netstandard1.x 로 이식하기 위해 System.XAML이 필요하지 않습니다. WF의 핵심이 작동하는 @dmetzgar 의 훌륭한 작업이 이미 있습니다. 누락된 주요 부분은 결국 netstandard2.x 에 다시 돌아올 것이라고 생각하는 트랜잭션입니다.

@dmetzgar 포트의 주요 지침은 코어에 어떤 종류의 디자인 언어도 묶지 않고 사람들이 원하는 대로 워크플로를 직렬화하고 나중에 그 위에 디자이너를 만들 수 있도록 기본 프리미티브를 갖는 것입니다.

물론 이 접근 방식은 현재 XAML 기반 워크플로와 역호환되지 않지만 .Net Core로 무엇이든 옮기는 것은 주요 변경 사항이므로 사람들이 이해해야 합니다.

XAML 디자이너를 위해 활용할 수 있는 OminiSharp가 있지만 다시 말하지만 디자인/직렬화는 WF 코어의 일부입니다. .Net Core의 다른 모든 것과 마찬가지로 슬림해야 합니다.

나는 이 문제가 사람들이 WF를 .Net Core로 옮기고 싶어한다는 점을 분명히 밝혔고, System.XAML 팀에 OSS에 대해 불평하는 것은 생산적이지 못하다고 생각합니다. XAML 팀에는 다른 우선 순위가 있으며 Windows/UWP/Xamarin 비즈니스의 핵심이므로 너무 빨리 OSS를 받을 것으로 기대하지 마십시오. 그 대신 @dmetzgar 에게 .Net Foundation에서 WF 리포지토리를 공식적으로 공개하고 netstandard2.x 릴리스에 대한 일정이나 약속 없이 커뮤니티를 안내하고 실행하도록 안내합니다. 그의 팀이 주도하는 진행 중인 작업이 될 것이며, 분명히 돕고자 하는 커뮤니티의 도움을 받았을 것입니다.

Orleans 프로젝트에서 상황이 얼마나 빠르게 발전하는지 보세요... 작년에 OSSed를 받은 것은 Microsoft Research였으며 .Net Foundation에서 가장 크고 가장 활동적인 저장소 중 하나이며 대부분 커뮤니티의 노력에 의해 주도됩니다(여전히 MSFT 팀 풀타임 근무).

어쨌든, IMHO, 내 생각에 우리는 장난을 멈추고 뭔가를 시작해야 한다고 생각합니다. @dmetzgar 팀은 기본적으로 .net 코어에 접근할 계획이 없는 WF의 주요 사용자를 지원하는 것이 주요 관심사이므로 작업할 대역폭이 없다는 것이 분명합니다. 따라서 커뮤니티 주도( @dmetzgar 팀의 감독) 노력이어야 합니다.

여러분, 다시 말하지만 WF를 netstandard1.x로 이식하기 위해 System.XAML이 필요하지 않습니다...

@galvesribeiro 그건 사실일 수 있지만 이 문제는 System.Xaml을 .NET Core로 이식하는 것입니다. 이 중 .NET 팀이 피드백을 요청하는 리포지토리에서 단연코 가장 많이 요청되는 기능입니다. 피드백을 듣지 않는다면 왜 요청합니까? 어쨌든 WF는 단순히 System.Xaml 포트가 충족할 시나리오 중 _하나_입니다. 아시다시피(또는 그래야 합니다!) System.Xaml은 훨씬 더 많은 작업을 수행할 수 있습니다.

XAML 팀에는 다른 우선 순위가 있으며 Windows/UWP/Xamarin 비즈니스의 핵심이므로 너무 빨리 OSS를 받을 것으로 기대하지 마십시오.

네, 이것이 바로 여기에서 발생하는 일종의 문제이며 우리가 변경하고자 하는 것입니다. :) 그리고 요즘은 'Xaml 팀'이 있는지도 모르겠군요, 있죠?! 정말 이 기술이 중단되었다고 느끼고 우리는 이에 대한 대안을 찾기 시작했습니다.

어쨌든, IMHO, 내 생각에 우리는 장난을 멈추고 뭔가를 시작해야 한다고 생각합니다.

100% 동의합니다. FWIW, @SuperJMN 은 방금 OmniXamlv2.0 을 출시했습니다. 따라서 MSFT가 이 문제에 대한 에너지와 노력의 우선 순위를 지정하는 동안 활용할 수 있는 몇 가지 커뮤니티 노력이 진행 중입니다.

말하자면 @terrajobst 의 인용문과 함께 정확히 이에 대한 좋은 스레드 (즉, 이에 대한 MSFT의 비활성)가 있습니다.

분명히 말씀드리자면 System.Xaml이 플랫폼 간 불가능하거나 해서는 안 된다는 말은 아닙니다. 내가 말하는 것은 System.Xaml이 WPF 및 WF 외부에서는 그다지 유용하지 않으며 NuGet은 해당 명령문에 대한 합리적인 프록시 메트릭이라는 것입니다. 물론 System.Xaml은 UI 영역 외부에서 의미 있게 만들 수 있지만 이는 두 번째 단계입니다. 차라리 지금 바로 리소스를 사용하여 기본 요소가 제대로 작동하고 완벽하게 작동하도록 하고 싶습니다. 게다가 기반이 통합되어 System.Xaml과 같은 상위 수준 구성 요소를 이식하는 것도 훨씬 쉬워집니다.

따라서 이것은 양자택일의 진술이 아닙니다. 실행 명령문입니다.

System.Xaml이 WPF/WF 외부에서 유용하지 않다는 매우 잘못된 설명을 제쳐두고, 이 모든 것은 이 문제를 해결할 의도가 전혀 없는 저에게 프로젝트 관리자처럼 들립니다. Immo와 그가 여기서 하는 위대한 일을 전적으로 지지하기 때문에 내 목표는 그 발언에 대해 비판적인 것이 아닙니다. 그러나, 저는 그런 종류의 언어가 저를 잠시 멈추게 하고 이 문제에 대해 관망(또는 오히려 "내가 볼 때 그것을 믿으십시오" LOL!) 입장에 놓이도록 허용할 만큼 충분히 블록 주위에 있었습니다.

그 동안 저는 .NET Standard 2.0의 현재 노력을 지원하고 그 결과를 기대합니다. 어쩌면 예상보다 나을 수도 있습니다. 최소한 Windows 플랫폼에서 작동하는 .NET Core 프로젝트용 System.Xaml을 회수할 수 있을 것 같습니다. 이는 저에게 충분한 시작입니다. 👍

@Mike-EEE 먼저 죄송합니다. https://github.com/dotnet/corefx/issues/2394 oO 이 두 가지 문제에 대해 회신을 하고 있었습니다. 이 두 가지 문제는 너무 여러 번 연관되어 혼란스러웠습니다.

둘째, XAML이 UI에만 유용하다고 말할 수는 없습니다. TFS 빌드, WF 자체 및 최근에는 UI에서 수년 동안 사용했습니다. Azure ML과 같은 DSL과 XAML을 활용할 수 있는 기타가 있습니다.

내가 말하려는 것은 XAML이 .Net Core로 너무 빨리 이식되는 것을 보지 못한다는 것입니다. Immo가 말했듯이 그들은 먼저 현재 플랫폼에서 올바른 작업을 수행해야 합니다. .Net Core에는 아직 기본 이미지 조작 라이브러리가 없습니다.

완전한 기능을 갖춘 WPF에서 UWP의 취약하고 부족한 기능에 이르기까지 다양한 XAML 구현이 있습니다. 그런 것이 OSS를 받기 전에 통일되고 안정화되어야 합니다. 나는 그 안에서 일하는 팀이 말하는 것이 아니다. 나는 내 자원의 우선 순위를 정해야한다면 그들보다 diff를하지 않을 것이라고 생각합니다.

WF와 관련하여 다시 한 번 죄송합니다. 하지만 제 이전 의견은 대부분 이 문제로 인해 WF에서 코어로의 이식이 그렇게 빨리 이루어지지 않기를 바라는 사람들을 대상으로 했으며 이는 사실이 아닙니다 .

이 두 가지 문제는 너무 자주 관련되어 있어서 혼란스러웠습니다.

하하 @galvesribeiro 저도 그게 얼마나 많이 저를 물었는지 당신에게 말할 수 없습니다(또는 인정하기가 두렵습니다). 걱정하지 마세요. 나는 하나에 관계없이 입력을 주셔서 감사합니다!

FWIW, @cwensley 도 @ Portable.Xaml 에 대해 계속해서 훌륭한 일을 하고 있는 것 같습니다. 최근에 System.Xaml의 모노 기반 적응에 대한 성능 개선을 통해 원래 버전보다 더 빨라졌습니다. 여기 있는 모든 맛/옵션의 원래 System.Xaml 경험에 가장 가깝기 때문에 여기에서 노력을 위한 좋은 출발점이 될 수 있는 것처럼 보입니다. 아침에 카페인으로 인한 2센트만.

System.Xaml을 .NetCore로 이식하십시오.

FWIW, 이 문제에 대해 200개 이상의 투표가 있었고 현재 202위에 있습니다. 다음으로 높은 문제는 47에 있는 dotnet/corefx#13526입니다. WAS 47... 지금은 48에 투표했습니다. :) (가서 사랑을 보여줘, 좋은 생각이야.) #squeakywheel

@Mike-EEE ;-)를 상기시켜 주셔서 감사합니다. 기대치를 설정하기 위해: 우리는 아직 깊이 파고들 준비가 되지 않았습니다. 개인적으로 3월까지 "아직 계획이 없습니다"라고 하더라도 다음 공식 단계에 대해 더 많은 언급을 할 수 있기를 바랍니다. (면책 조항: 나는 최선의 개인적인 추측을 전달하려고 노력하고 있습니다. 공식 팀 약속으로 취급하지 마십시오!).

지난 시간에 이 문제를 조금 논의했을 때 튀어나온 핵심 질문은 200개 이상의 투표 중 어떤 것이 진정으로 System.Xaml과 WPF에 관한 것인지 결정하는 것이었습니다. 많은 사람들이 이 둘을 구별하지 못한다는 가정입니다. 그것에 대해 가장 좋은 방법에 대한 제안이 있습니까? (예: 2개의 특정 문제를 만들고 사람들에게 WPF에 투표하도록 요청하는 대신 "WPF가 아닌 순수한 Xaml")

또한 몇 가지 우선 순위 추정과 함께 System.Xaml에 대한 시나리오의 요약 목록이 있으면 도움이 될 것입니다(현재 긴 토론에 걸쳐 흩어져 있음). @Mike-EEE 우리가 함께 할 수 있도록 도와주시겠습니까? (해당 분야에 대한 깊은 관심과 깊은 지식을 갖고 계신 것 같습니다.)

확실히 System.Xaml 는 사람들이 @karelz를 원하는 것입니다. 누군가 WPF를 여기에서 생각하고 있다면 IMHO가 올바른 위치가 아닙니다. 여전히 System.Xaml을 사용하는 WF, TFS Build 등과 같은 XAML을 활용하는 많은 다른 프레임워크가 있으며 이는 우리에게 큰 도움이 될 것입니다.

@karelz 여기에 답장을 보내주셔서 정말 감사합니다. 시간을 내주셔서 감사합니다. @galvesribeiro 가 언급했듯이 System.Xaml은 단순한 UI 이상이며 불행히도 많은 MSFT가 놓치고 있는 핵심 이해인 것 같습니다. 이것은 다른 직렬화 솔루션을 능가하는 강력한 직렬화 패러다임입니다. 특히 응용 프로그램을 설명할 때 가장 잘 수행되는 작업입니다(결국 이름의 "A"). 불행히도 "응용 프로그램"은 "UI"와 병합되어 여기에서 마찰이 발생합니다.

이 측면을 간과하는 것은 UWP의 주요 실패였으며 아무도 UWP로 작업하는 것을 좋아하지 않는 이유 중 하나입니다. 반대로 Xamarin은 Xaml의 특징에서 이 핵심 측면을 이해한 것으로 보이지만 내부적이며 권위 있는 일류 제품으로 노출되지 않습니다(여기서 이 문제가 무엇인지 대략적으로 설명합니다).

TBH, @cwensley 의 Portable.Xaml 에 있는 System.Xaml 포트는 현재 선두주자인 것 같습니다. 그는 Mono의 System.Xaml(전반적으로 친숙한 API 유지)을 이식했을 뿐만 아니라 새로운 기능을 추가했으며 실제로 System.Xaml보다 _더 나은 성능을 향상시켰습니다.

내 생각에 이 문제는 @cwensley 와 함께 작업하여 앞으로 사용할 권위 있는 플랫폼 간 Xaml 라이브러리를 만드는 것만큼 간단할 수 있습니다.

이 외에도 까다로워지고 이 문제에 대한 (이해할 수 있을 정도로) 복잡한 관점이 추가될 수 있습니다. System.Xaml은 응용 프로그램을 설명하는 표현력이 풍부하고 강력한 언어(사용자 인터페이스 뿐만 아니라)를 제공하므로 Visual Studio(물론 Blend)에 내장된 훌륭한 도구 지원도 있습니다. 따라서 이상적으로는 동일한 훌륭한 경험을 계속하고 어떻게든 Xaml의 디자이너 경험을 크로스 플랫폼 방식으로 유지하는 것이 좋지만 개인적으로는 여기서 논의하는 멋진 케이크 위에 체리를 요구하는 것입니다. :)

또한 여기서 반복해서 Xaml의 약속(및 제공)은 디자이너와 개발자 간의 개발 워크플로 개선이기도 했습니다. 나는 우리가 궁극적으로 이것을 한 단계 더 나아가 개발과 _devops_ 간의 프로세스를 개선할 수 있다고 생각하고 싶습니다. 즉, devops가 아름답게 디자인된 애플리케이션 구성 편집기(Xaml 기반)에서 작동하여 배포된 애플리케이션을 관리하고 유지 관리하는 세상을 보고 싶습니다.

_여기서 전체 아이디어는 코딩에서 배포에 이르기까지 애플리케이션 개발의 전체 비용을 줄이는 것입니다. 멋진 편집자 및 디자이너와 함께 작업하는 것은 마술을 실현하기 위해 코드(및/또는 스크립트)에 손을 넣어야 하는 사람을 찾아서 고용하는 것보다 (자원 관점에서) 저렴합니다._

나는 이것을 비전 관점으로 여러분과 공유합니다. 여러분이 알고 있을 뿐입니다. 그러나 당신이 이 소식을 듣고 얼마나 관심이 있는지는 모르겠습니다. 😉 그래서, 만약 이것이 단순히 "이 문제를 끝내고 당신을 떠나게 하려면 무엇이 필요할까요?" 나는 Wensley 씨와 함께 일할 가능성을 탐구하고 우리가 그의 위대한 업적을 지금까지 활용할 수 있는지(또는 그가 그렇게 하는 데 열려 있는지) 볼 것을 제안합니다. .NET Core Wave 2 릴리스(5월쯤?)를 위한 신뢰할 수 있는 플랫폼 간 Xaml 패키지가 될 수 있도록 각도를 조정할 수 있는 방법이 있다면 훨씬 더 좋습니다. :)

정보 감사합니다, 확실히 관심이 있습니다. 또한 이전 질문이 의도한 대로 나오지 않았다고 생각하므로 몇 가지 사항을 지적하겠습니다.

예, 나는 세부 사항에 확실히 관심이 있습니다. 나는 MSFT 측에서 Xaml != WPF에 대해 이의를 제기하는 사람이 없다고 생각합니다. 나는 확실히 그렇게 하려고 하지 않았다. 나는 내가 완전히 이해하지 못하는 것을 알고 있으며 그 격차를 채우기 위해 노력하고 있습니다. 즉, "순수 Xaml" 시나리오의 동기와 필요성을 완전히 이해하고 있습니다.
(BTW: 나는 당신의 devops 시나리오와 Xaml이 어떻게 거기에 도움이 되는 유일한/가장 좋은 방법인지 잘 이해하지 못합니까? 아니면 시나리오에서 실제로 어떻게 사용됩니까?)

나는 이 문제를 끝내려고 여기에 온 것이 아닙니다. 제발! 그것조차 마음에 들지 않았다. 저는 커뮤니티가 요청을 요약하여 적절한 사람들과 논의할 수 있도록 돕기 위해 왔습니다(이 경우 이사를 생각하세요). 예, 그 중 일부는 저(및/또는 다른 MSFT 몇 명)가 더 높은 곳에서 이를 나타내기 위한 요청을 완전히 이해해야 함을 의미합니다. 따라서 제 질문입니다.

나는 이 문제를 보기 전에 Xaml과 WPF를 구분하지 않은 사람의 좋은 예라는 것을 인정합니다. .NET 팀의 다른 사람들과의 무작위 채팅에서 많은 사람들이 Xaml != WPF를 알고 있지만 여기에서 소개되는 순수한 Xaml을 갖는 "거대한 가치"를 보지 못합니다. 따라서 시나리오에 대한 위의 질문입니다. 시나리오는 동기를 더 잘 이해하고 이야기를 더 잘 알리고 판매하는 데 도움이 됩니다. (명확한 스토리가 없을 때 아무도 펀딩을 꺼린다고 해서 놀라지 않았으면 좋겠습니다. :) - 스토리는 펀딩의 전제 조건입니다)
그럼 앞으로 나아가기 위해 엘리베이터 피치를 생각해 봅시다.

@cwensley 의 작업과 관련하여 - 그리 비싸지 않은 솔루션이 있다는 소식을 듣게 되어 기쁩니다. 그러나 다시 한 번, 솔루션에 뛰어들기 전에 먼저 배경과 이유를 이해하는 것이 정말 도움이 될 것입니다. 나는 그것이 의미가 있기를 바랍니다. (나는 무시하려고 하는 것이 아니라 WHY를 이해하고 동의할 때 앞으로 나아가는 것이 더 쉽다는 것을 반복합니다)

@galvesribeiro 누군가 여기에서 WPF에 대해 생각하고 있다면 그것은 올바른 장소가 아닙니다 IMHO

투표한 200명 이상의 모든 사람들이 Xaml != WPF를 이러한 세부 사항에 대해 진정으로 이해하고 있다는 확신을 공유하지 않습니다. 또한 최소한 몇 가지 살펴봐야 할 것 같습니다. 예, 먼저 Xaml을 가져와 보겠습니다. 그러면 WPF를 요청하는 것이 더 쉬울 것입니다. 따라서 항상 염두에 두고 있는 시나리오는 WPF인 반면 "순수 Xaml"은 이를 향한 첫 번째 단계일 뿐입니다.
그리고 아마도 내가 틀릴 수도 있습니다 (적어도 .NET 팀에서 이러한 의구심을 가진 유일한 사람은 아니지만) ...
또 다른 각도는 "순수 Xaml"을 시나리오 목록(WPF, 위의 devops, 몇 가지 더?)으로 나눈 다음 사람들에게 투표를 요청하는 것입니다. 여기에서 투표한 사람들에게 진정으로 중요한 것은 무엇입니까? 그들이 진정으로 원하는 것은 무엇입니까?
(이것은 지연 전술이나 악의적 인 것이 아닙니다. 여기서 "고객"을 이해하려고 노력하고 있습니다. 그것이 의미가 있기를 바랍니다. 그러한 데이터에 도달하는 더 나은 제안이 있으면 의견을 말하십시오. 다른 접근 방식에 열려 있습니다. )

편집: 평소와 같이 내가 문제에 올바른 방식으로 접근하고 있지 않다고 생각한다면 그렇게 말씀해 주십시오. 최선을 다해 도와주려고 합니다. 최선의 의도로요. 나는 모든 것을 알고 있다는 환상이나 내가 다른 사람들보다 똑똑하다고 생각하지 않습니다.

@karelz WPF를 전혀 좋아하지 않더라도 XAML이 크로스 플랫폼이 아니기 때문에 휠을 재발명하고 고유한 마크업 언어를 작성하는 많은 UI 프레임워크가 있습니다. 아발로니아는 상위 제품 중 하나입니다. 대신 네이티브 XAML을 활용할 수 있을 때 Omnisharp를 사용합니다.

Workflow Foundation은 XAML의 큰 사용자/고객이며 Port WF에서 .Net Core 스레드로의 사람들은 항상 이에 대해 묻습니다.

예, 예를 들어 UI 및 WF와 같은 원하는 사용법과 함께 플랫폼 간 System.Xaml 에서 기대되는 것에 대한 기대치를 설정하거나 원시 기능 세트를 그려야 한다는 데 동의합니다.

@karelz

또한 최소한 몇 가지 살펴봐야 할 것 같습니다. 예, 먼저 Xaml을 가져와 보겠습니다. 그러면 WPF를 요청하는 것이 더 쉬울 것입니다. 따라서 항상 염두에 두고 있는 시나리오는 WPF인 반면 "순수 Xaml"은 이를 향한 첫 번째 단계일 뿐입니다.
그리고 아마도 내가 틀릴 수도 있습니다 (적어도 .NET 팀에서 이러한 의구심을 가진 유일한 사람은 아니지만) ...

그래서... 그게 뭐가 문제야? WPF와 같은 플랫폼 간 솔루션은 꽤 좋은 일이 될 수 있습니다. Xamarin은 플랫폼 간 데스크톱 GUI를 수행할 수 없습니다.

@jnm2 나쁘지는 않지만 그것이 주요(90% 이상) 시나리오라면 두 가지 모두를 계획해야 합니다. WPF 없이 Xaml을 갖는 것은 그러한 경우에 도움이 되지 않을 것입니다(적어도 별로). 그리고 WPF가 커밋되고 곧 올 것이라는 잘못된 환상을 (잠재적으로) 만들 수 있습니다.

WPF/GUI를 .NET Core로 가져오는 것은 현재 주로 서버 시나리오와 콘솔 앱을 대상으로 하는 .NET Core의 큰 단계가 될 것입니다.

System.Xaml이 있는 @jnm2 는 WPF와 같은 것을 다른 플랫폼(https://github.com/AvaloniaUI/Avalonia)으로 가져오려고 _시도하는_ 사람들(저와 같은)을 크게 도울 것입니다.

합리적인 시나리오처럼 들리는 @grokys - 좀 더 자세히 설명해 주시겠습니까? 얼마나 큰 도움이 될까요? 그것 없이는 무엇이 도전적입니까?

또한 (WPF가 아닌) 크로스 플랫폼 데스크톱 UI 프레임워크인 Eto.Forms 에 Xaml을 사용하고 있습니다. 이것이 내가 처음에 Portable.Xaml 프로젝트를 만든 이유이며 지금까지 나와 내 사용자에게 잘 작동하고 있습니다.

저는 이것을 "권위 있는" 크로스 플랫폼 xaml 구현으로 만드는 데 반대하지 않습니다(@Mike-EEE가 말한 대로). 그러나 나는 여가 시간에만 이 작업을 수행한다는 것을 명심하십시오(;

@karelz
UI 프레임워크 뿐만 아니라 XAML에서 HTML까지 다양한 장면에서 사용할 수 있습니다.

@Kation 정확히 무슨 말인지 자세히 알려주실 수 있나요?

BTW: 맨 위 게시물에서 시나리오 요약을 시작했습니다. 시나리오가 없으면 설명하고 이해가 되면 거기에 추가하겠습니다.

@karelz
Visual Studio의 강력한 XAML 편집기를 사용하여 사용자 지정 구성 요소 콘텐츠를 빠르게 만들 수 있습니다.
그런 다음 XAML을 사용하여 특정 시나리오에서 HTML 콘텐츠, 훨씬 더 많은 SVG 콘텐츠를 생성할 수 있다고 생각합니다.
이것은 .Net 4.5용 XML 프레임워크에 대한 반제품 XAML입니다. https://github.com/Kation/WebPresentation

XAML에서 HTML 또는 SVG를 생성하려는 이유를 모르겠습니다. 여기서 XAML의 가치는 무엇입니까?
멋진 VS 편집기가 있다는 값입니까? HTML 편집기도 있습니다. 직접 사용하지 않는 이유는 무엇입니까?
아니면 내가 요점을 완전히 놓치고 있습니까?

@karelz
일부 프로젝트에서 템플릿과 스타일로 WPF와 같은 콘텐츠를 생성하고 싶기 때문입니다.

@karelz 대화에 다시 한 번 감사드립니다. 나는 그것을 대단히 감사합니다.

나는 모든 것을 알고 있다는 환상이나 내가 다른 사람들보다 똑똑하다고 생각하지 않습니다.

아, 부럽다. 😉

따라서 항상 염두에 두고 있는 시나리오는 WPF인 반면 "순수 Xaml"은 이를 향한 첫 번째 단계일 뿐입니다.

예, 이것은 다시 제가 언급한 결합입니다. Xaml은 순수하고 단순한 직렬화 패러다임입니다. 애플리케이션과 애플리케이션에 포함된 구성 요소를 정의하고 설명할 수 있습니다. 먼저 Xaml에 설명된 _console 응용 프로그램_의 예는 다음과 같습니다.
https://github.com/DevelopersWin/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml

콘솔 입력 및 출력을 사용하여 사용자에게 표시할 항목에 대한 지침을 제공하는 Xaml에 설명된 명령이 있음을 알 수 있습니다. 이것은 WPF 또는 "UI"와 아무 관련이 없습니다(기술적으로 이것은 CLI가 UI라는 의미에서 UI이지만 차이점을 발견할 수 있기를 바랍니다). 또한 파일에서 바로 마크업 확장과 정적 멤버 선언을 사용하는 것을 볼 수 있습니다. 이것은 JSON이나 다른 데이터 형식에서 본 적이 없는 것입니다. 이것이 바로 IMO Xaml의 힘입니다.

"순수 Xaml" 시나리오의 또 다른 예로서, 다음은 새로운 형식에 구애받지 않는 MSBuild에 대해 제안하는 파일입니다.
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Processor.xaml

(레벨을 올리면 동일한 작업을 수행하는 다른 형식을 볼 수 있습니다. 이것은 Xaml 버전일 뿐입니다)

이것은 다시 이론적인 빌드 프로세스에서 수행할 단계를 설명하는 ( System.Windows.Input.ICommand ) 명령 세트인 프로세서 파일입니다. 다시 말하지만, WPF나 UI는 없지만 콘솔로 메시지를 내보내는 것을 볼 수 있습니다.

앞에서 언급한 여기에서 지적하고 싶은 기능 중 하나는 이 파일에서 가져온 Visual Studio의 기본 제공 도구입니다.

작업을 수행하거나 외부 스키마를 정의하지 않고 Visual Studio는 단순히 "불을 켜고" 내가 작업 중인 파일의 클래스 스키마를 기반으로 하는 드롭다운 및 기타 디자이너 인터페이스가 있는 속성 편집기를 제공합니다(이렇게 하면 devops 시나리오가 더 쉬워지길 바랍니다. 이해하다).

프로세서 파일 외에도 프로세서에 보내는 데 사용할 수 있는 이론적인 프로젝트 또는 입력 파일이 있습니다.
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Project.xaml

여기서 나는 버전(외부 파일에서)을 제공하는 데 사용되는 _markup extension_을 사용하고 빌드를 위해 수집된 파일을 제공하는 쿼리를 사용하려고 합니다(실제로 이 작업을 수행하고 싶지 않을 수도 있습니다. 최종 빌드 시스템이지만 그 가능성을 보여주고 싶었습니다).

BTW, 이 예제 코드는 완전히 작동하므로 해당 리포지토리에서 SLN을 가져와 Xaml 버전을 실행할 수 있어야 합니다. 결과는 다음과 같아야 합니다.

(참고: My Machine에서 작동 하므로 마일리지가 다를 수 있습니다. 😄)

BTW: 귀하의 devops 시나리오와 Xaml이 어떻게 도움이 되는 유일한/가장 좋은 방법인지 잘 이해하지 못합니다. 아니면 시나리오에서 실제로 어떻게 사용됩니까?

네, 글이 좀 길어지는 것 같아서 들어갈까 말까 고민했습니다. 바라건대 이제 위의 비주얼 디자이너 구성 요소가 내가 여기에서 보고 있는 것을 설명하는 데 도움이 될 수 있습니다.

저에게 이것이 궁극의 최종 게임이고 제가 이 모든 것에 대해 왜 그렇게 궁지에 몰리는지 알고 참고하십시오. _그 이유는 결국 애플리케이션의 수명 동안 총 소유 비용을 줄이기 때문입니다._

따라서 여기서 핵심은 POCO 기반 개발입니다. 여기서 편집 및 디자인은 응용 프로그램 프로세스 내에서 사용되는 POCO에서 발생합니다. 알다시피 개발자와 디자이너는 UI 도메인을 처리하는 POCO 요소를 설명하는 Xaml 파일에서 작업합니다(원하는 경우 여기에 "Xaml"의 기존 "WPF"가 있습니다).

제 세계에서는 개발이 라이브 환경에 배포된 애플리케이션을 관리/유지하는 데 사용할 Xaml 파일을 devops에 제공하도록 이 프로세스가 확장되는 것을 보고 싶습니다.

이것을 라이브 구성 파일로 생각할 수 있습니다. 로드 방법을 수정해야 하지만 최종 결과는 Visual Studio의 위 스크린샷에서 볼 수 있는 것과 같습니다. 최종(데브옵스) 사용자는 강제로 코드에 손을 넣어야 하는 대신(또는 조직이 그에 따라 필요한 값비싼 인재/기술을 고용하도록 강요받는 경우), 대신 제한적이고 검증된 시각적 편집 컨트롤을 사용하여 구성하고 응용 프로그램을 유지합니다.

_여기서 아이디어는 코드를 알고 이해하는 것이 아니라 이를 수행하는 데 필요한 노력(및 기술) 때문에 배포 후 응용 프로그램을 유지 관리하는 비용이 상당히 절감된다는 것입니다._

이에 대해 언급하지 않은 한 가지 측면은 해당 컨트롤이 실제로 사용자 지정할 수 있다는 것입니다. Visual Studio에는 이러한 POCO 속성에 연결된 시각적 편집기를 정의하기 위한 (노화되기는 하지만) 광범위한 API가 있습니다.
https://msdn.microsoft.com/en-us/library/microsoft.windows.design.model.designmodevalueprovider(v=vs.90).aspx

이 모든 것은 추가 작업, 오버헤드 또는 노력 없이 Visual Studio에서 바로 사용할 수 있습니다. 따라서 여기서 궁극적인 아이디어는 개발 프로세스뿐만 아니라 궁극적으로 데브옵스 프로세스에서도 도움이 되는 강력한 편집자와 디자이너 제품군을 만드는 것입니다.

다시 말하지만 이것은 모두 환상적이며 실제적인 실제 기반이 없습니다(아직). 확실히 이것은 완전히 제 생각은 아니지만 Windows Forms 기반 구성 편집기 를 사용하는 패턴 및 사례 그룹에서 영감을 받았습니다. 나는 단순히 이 빨판을 한 단계 더 발전시켜 Xaml의 힘을 통해 그것을 사용하는 것을 보았습니다.

@karelz에 대해 추가 질문이 있으면 알려주세요. 다시 한 번 대화에 감사드립니다. 그것은 공유할 수 있는 기회를 제공할 뿐만 아니라 내 생각과 신념을 검증할 수 있는 기회도 제공합니다. 그리고 모든 것을 알고 있다는 생각으로 돌아가서(예, 저는 유죄 👼), 사물에 대해 열린 마음을 유지하려고 노력하고 모든 답을 가지고 있지 않다는 것을 깨닫습니다. 이것은 확실히 내가 계속해서 더 잘하려고 노력하는 과정입니다. 다시 한번 감사합니다!

@karelz - Avalonia는 현재 OmniXaml을 XAML 엔진으로 사용하고 있으며 이것이 꽤 잘 작동하지만 여전히 버그와 누락된 기능이 있습니다. Portable.Xaml과 마찬가지로 OmniXaml은 항상 작업할 시간이 많지 않은 자원 봉사자에 의해 유지 관리됩니다.

실제로 System.Xaml을 열지 않기로 결정했다면 테스트 스위트를 출시하는 것이 좋은 절충안이 될 수 있습니다. 최소한 그런 식으로 OmniXaml 및 Portable.Xaml과 같은 타사 구현이 가능한 한 규정을 준수하도록 할 수 있습니다.

.net 생태계에 필요한 것은 기본적으로 사람이 읽을 수 있는 직렬화 형식(Javascript 세계의 JSON과 같은)입니다. 이 형식은 dot 데이터 유형을 사용하고 POCO를 스키마로 직접 사용해야 합니다. 그런 다음 해당 형식을 사용하여 POCO 개체를 설명할 수 있습니다. 이러한 설명은 강력하고 정적으로 입력됩니다. UI 레이아웃, 런타임 앱 구성, 프로젝트/워크플로 설명 또는 두 .net 프로그램 간의 통신이 될 수 있습니다. 그리고 웹/자바스크립트와 같은 다른 생태계와의 통신도 포맷을 구현하면 가능합니다. 그러나 .net 생태계를 중심으로 설계되어야 합니다. 이것이 JSON/BOND/Protobuf/XML이 충분하지 않은 이유입니다.

역사적으로 XAML은 어느 정도 책임을 완수했습니다. 이제 문제는 이 역할이 얼마나 좋은가 하는 것입니다. 충분하다면 XAML이 netstandard로 만든 다음 .net으로 구현해야 한다고 생각합니다. 그러나 가능하면 다른 형식도 고려해야 합니다. 지난주에 http://www.ammyui.com/ 이 나온 것 같아요. 단순성에 중점을 두지만 XAML로 변환되는 UI 설명 형식입니다. XAML이 충분히 간단하지 않았기 때문입니다. 나 자신은 (객체, 컬렉션 및 인덱스) 이니셜라이저를 기반으로 roslyn repodotnet/roslyn#16648에서 하나의 형식을 제안했습니다. 그리고 내 제안은 실제로 Entity 프레임워크 팀의 @bricelam 이 작성한 이 블로그 게시물 에서 가져왔습니다. 그의 게시물과 내 제안 스레드에는 몇 가지 예가 있습니다.

내 요점은 .net에 대한 기본 형식이 있어야 한다는 것입니다. XAML이든 뭐든 마찬가지입니다.

@grokys OmniXaml 을 언급하고 싶었고 @SuperJMN 을 여기 대화에 초대했지만 그는 참여하고 싶어하지 않는 것 같습니다. 설정인지 무엇인지 확실하지 않습니다(저도 gitter에서 시도했습니다 -- 당신이 그와 함께 일하기 때문에 아마도 그를 여기로 끌어오는 것이 더 나은 행운을 가질 수 있습니다 😄 ). 물론 OmniXaml도 이 대화에 참여하는 것을 환영합니다.

@gulshan +💯 👏 ! ㅋ. 이 모든 것의 혼란스러운 부분 중 일부는 Xaml이 MSFT 형식 및 기술이라는 것입니다. MSFT와 기업 모두를 중심으로 구축된 모든 투자와 도구로 인해 기존 노력과 투자를 활용할 수 있도록 연속성을 보장하는 데 공백이 있는 것처럼 보이는 이유는 참으로 이해할 수 없습니다.

그렇긴 하지만, 저는 Ammy와 함께 하는 것을 좋아하고 이에 대해 계속해서 열린 마음을 갖고 있습니다. 또는 하나를 시도하십시오. 👼

처음부터 데이터 파일에 신경을 쓰는 이유를 반복하는 것이 중요하다고 생각합니다. 데이터 형식 사용의 주요 가치는 다음과 같습니다.

• 명령형 언어 불가지론 . 파일을 사용하기 위해 프로그래밍 언어를 알 필요는 없습니다.
• 디자이너/공구 친화적. _비주얼 디자이너를 사용하거나 제품에 대한 시각적 디자이너 경험을 가능하게 하면 TCO 가 낮아집니다 _.

즉, 나에게 개인적으로 중요한 것은 다음과 같습니다.

• 개발자/디자이너 통합 워크플로
• 파일을 손으로 편집할 수 있는 비주얼 디자이너 경험.
  
  
  
  • 위에서 설명한 대로 확장 가능한 편집기 API가 있는 PropertyGrid(속성 창).
  
  
• 마크업 확장
• 최고라는 케이크: 개발 외부의 시나리오 내에서 위의 모든 것을 활용할 수 있는 능력(위의 devops 예).

이 모든 것이 충족되면 "다른 .NET 형식"을 고려할 의향이 있지만 분명히 Xaml을 해당 형식으로 유지하고 확장하는 것을 선호합니다. 이는 결국 MSFT 기술이므로 지적 재산입니다.

@Mike-EEE 형식을 POCO로 역직렬화할 수 있는 경우 이러한 모든 기능이 작동해야 합니다. VS의 속성 창은 XAML이 아닌 시나리오에도 나타납니다. 그러나 한 가지 우려되는 점은 편집기 지원 없이도 가독성이 높다는 것입니다. 경우에 따라 원격 서버에서 구성 파일을 편집해야 하고 vim만 있습니다. JSON과 비교할 때 XML(및 XAML)은 IMHO와 관련하여 그다지 좋지 않습니다.

그러나 XAML에는 간단한 직렬화 형식으로 모방하기 어려운 연결된 속성과 같은 몇 가지 고유한 기능(실제로는 XML이 아닌 기능)이 있습니다.

먼저 WPF에 투표하고(마침내 xamarin.froms에 작별 인사를 할 수 있도록) xaml

VS의 속성 창은 XAML이 아닌 시나리오에도 나타납니다.

맞습니다. 그러나 완전히 사용자 정의 가능한 편집 컨트롤 등을 사용하여 Xaml의 경우와 같이 거의 "밝혀지지" 않습니다. 여기에서 내가 틀렸다면 수정해 주세요. 단순히 이러한 형식의 속성에 커서를 놓고 열거형 필드(예:)에 대한 드롭다운 렌더링을 가질 수 없습니다. 이 경험은 기본적으로 WinForms의 다음 형식이자 버전이며, 이것이 바로 WinForms가 좋은 이유 중 하나입니다(WinForms는 여전히 인기가 있습니다!).

JSON과 비교할 때 XML(및 XAML)은 IMHO와 관련하여 그다지 좋지 않습니다.

예, Xaml이 정확히 간결하지 않다는 데 동의합니다. Xaml이 얼마나 장황한지에 대한 불만을 듣게 될 것입니다. 이것은 OmniXaml이 서식과 관련된 개선 사항을 제공함으로써 주목을 받고 있는 곳입니다. 또한 TOML 및 YAML 등과 같은 다른 형식과도 경쟁하고 있습니다.

비 XML 기능) 첨부된 속성과 같은 ...

그리고 마크업 확장. 😄 비전의 특징입니다.

@gulshan 이 여기에서 보고 있는 것은 본질적으로 "데이터 AST(추상 구문 트리)"입니다. Xaml(또는 .NET 데이터 형식)을 심각하게 개선하는 방법에 대해 이야기하고 있다면 이것이 올바른 방법입니다. Roslyn에 의해 구동될 수도 있습니다. 사실, 나는 바로 이 아이디어에 대해 uservoice 투표를 했습니다 ( 해당 블로그 게시물 과 함께). 불행히도 그것은 설명하기가 어렵기 때문에별로 인기가 없습니다, 하하. 기본적으로 여러 형식으로 쓸 수 있는 AST(데이터) 트리가 있습니다. 그렇게 하면 개발자(및 도구)가 가장 의미 있는 형식(미학적으로든 그렇지 않은 경우든)에 따라 작업할 수 있습니다.

그래서 나는 마침내 xamarin.froms에게 작별 인사를 할 수 있습니다.

@groege 측면에서 귀하와 동의합니다. 😎

@Mike-EEE 이전에 Data AST 제안을 확인하지 않았습니다. 예, 개념적으로 .net에 대한 기본 직렬화/객체 표기법 제안과 유사합니다. 아이디어는 추상적이기 때문에 이해하기 어렵습니다. 😄

XAML과 관련하여 .net 기반의 강력한 형식의 데이터 직렬화 형식은 많은 XAML 태그 확장의 필요성을 줄여줍니다. 그러나 일부 표현식(생성자 없이)으로 초기화할 수 없는 일부가 남아 있습니다. 이러한 마크업 확장 기능 중 일부가 C# 자체의 일부였으면 합니다.

글쎄요 @karelz 로부터 답장을 받지 못했기 때문에 Xaml에서 콘솔 애플리케이션을 정의할 수 있다는 것을 알게 된 후 그가 모니터 앞에 앉았다고 가정할 수 있을 뿐입니다.

(나쁜) 농담은 제쳐두고 추가 질문이 있으면 알려주세요.

또한 This Week in .NET 에서 .NET Core에서 만들어지고 있는 꽤 멋진 엔진처럼 보입니다. 이 게시물의 첫 번째 댓글이 모든 것을 말해줍니다 . :)

@Mike-EEE 나는 당신에게 답을 빚지고 있다는 것을 알고 있습니다(내 받은 편지함에 중요하다고 표시되어 있고 브라우저에서 열렸습니다).
지금까지 나는 답장을 훑어볼 수 밖에 없었습니다(모든 세부 사항과 통찰력에 대해 모두에게 감사드립니다!). 답변할 수 있습니다... 죄송합니다. 지금 너무 많은 화재와 고층 빌딩이 진행 중입니다.

모든 좋은 @karelz! 여기에서 귀하의 노력과 대화에 감사드립니다.

다음은 오픈 소싱 WPF에 대한 투표입니다. XAML의 다른 모든 버전은 비교하면 쓰레기입니다. 그리고 진지하게 여러분, 이것에 대한 루프를 완료하고 유닉스 및 MacOS용 .net 코어/XAML STORE 가 있습니다.

@Mike-EEE 매우 죄송합니다. 이 문제에 대해 다시 이야기할 시간이 없었습니다 :(

오, 걱정하지 마세요. @karelz 지금 모두가 바쁘다는 것을 알고 있습니다. 나는 무엇보다 대화를 감사합니다. 나는 내 머리에서 많은 것을 얻었다. 그걸 보고 반성하는 게 좋을 것 같아요. 게다가, 우리는 지금까지 이미 1년 이상을 기다렸습니다... 몇 개월 정도 더 기다려야 합니까? :)

그들은 Silverlight 5 ..를 html5 이동, win8 이동/winrt...& 이제 uwp & win10 및 xamarin ..공통으로 공개해야 합니다. 헐리우드와 같은 라라 랜드에서 길을 잃은 한심한 당신이나 뭐...

어떻게 Silverlight 5에서 모든 쓰레기로 갈 수 있습니까? 어떻게? 어셈블리 인터페이스를 항상 깨뜨릴 때 어떻게 사용자를 존중한다고 말할 수 있습니까? 자신의 nuget 패키지 이름을 바꾸고 nuget에서 이전 패키지에서 새 패키지로 자동 이동하는 방법을 제공하지 않습니다. 여전히 모든 사람을 무한대로 사용하는 것과 같습니다. 아이디어를 만들고 코딩하기 전에 명확하게 생각하기에는 너무 멍청하기 때문에 베타 테스터입니다.

xamarin 형식의 ios/android/uwp 프로젝트에 대한 필요성을 제거해야 합니다. 각 플랫폼에 대한 프로젝트를 갖는 것보다 다중 플랫폼을 지원하는 훨씬 더 나은 방법이 있다고 생각합니다.

이제 모든 것을 하나의 f 아래로 가져옵니다. 프레임워크 당신은 와이프(wpf/silverlight 적용 범위 및 xaml 언어를 권장하지만 xamarin에 모든 것을 가져오고 싶지만 스타일/템플릿에 데이터 유형을 추가할 수 있습니까? .. 많은 사람들처럼 이상한 누락이 있는지 확인하고 f. nucrapget이 작동하는지 확인하십시오. 한 번만 .. 도대체 왜 모든 종속 어셈블리에 너겟 패키지를 설치해야합니까?참조 된 dll과 동일 ..?당신은 비전이 없습니다 ... niet 없음 ... capout ...이 모든 시간은 ms 쓰레기에 갇혀 있습니다. .. 나는 내 자신의 f. 세계적인 수준의 SDK를 구축할 수 있었습니다.

나는 MS 없이는 하루를 보낼 수 없다. 나는 심각하게 scala-js를 고려하고 있다. 아니면 그냥 swift.. 집을 떠날 시간이다! 난 지쳤어

거의 2년이 걸렸지만 UWP는 마침내 Xaml 모델에 대한 마크업 확장을 지정했습니다.
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

참고로 노에시스는 지난주에 v2.0 제품을 출시했는데 상당히 인상적입니다. Xaml 시스템은 이미 마크업 확장 기능을 갖추고 있으며(C++에서는 C#도 제공 중) 사양에 도달하는 데 7년이 걸리지 않았습니다. 이제 인디 개발자에게도 무료입니다. AmmyUI 지원 을 고려하면 Xaml 모델이 ATM으로 전환되는 한 이것이 내 목록의 맨 위에 있다고 말하고 싶습니다.

http://www.noesisengine.com/

@karelz님, 아마도 이것에 대해 댓글을 달 수 있을 것입니다. 그러나 현재 발생하고 있는 UWP Xaml "사양"이 이 문제와 상관 관계가 있는지 알고 있습니까? 그렇지 않다면 가능한지 아십니까? 미친 생각이지만 도움이 될 수 있다면 하나의 가격으로 두 가지 문제를 해결하는 것이 좋을 수도 있습니다. UWP 투표에서도 거기에 메시지를 남겼지만 여기에서도 핑을 할 것이라고 생각했습니다.

@Mike-EEE UWP Xaml "사양"은 다른 조직(Windows에서 생각함)에 의해 구동될 가능성이 높습니다. 사용자 음성에 대한 세부 정보를 요청하는 것이 아마도 가장 좋은 채널일 것입니다.

네, 그게 두려웠습니다. 😛 거기에서 답장을 받았지만 솔직히 말해서 나에게는 별로 의미가 없습니다.

내가 괴로워할 수 있는 바에 따르면, 그들은 사양 프로세스에 대해 계속 비공개 접근 방식을 취할 것으로 보입니다. 이것은 지난번과 같은 결과를 가져오고 아무도 사용하거나 채택하고 싶지 않은 API로 끝나는 것처럼 보이기 때문에 우려됩니다.

아마도 그들은 개발자들이 자신의 작업에 대해 불평하는 것을 비밀리에 즐깁니다. :)

어쨌든, 이 글을 읽고 있고 투명한 오픈 소스 협업 및 개발을 지지하고 이 도메인에 대한 asp/.NET Core 이니셔티브의 성공에 참여하는 것을 즐겼다면 잠시 시간을 내어 자세히 살펴보십시오. WPDev UserVoice로 보내 동일한 작업을 수행하도록 권장하는 메모를 보냅니다. 링크는 이전에 언급되었지만 이메일에서 이 글을 읽는 사람들을 위해 다시 한 번 알려드립니다.
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

나는 @birbilis 에게 전화를 걸어 그의 이전 기여에 대해 감사를 표해야 합니다. 우리 모두가 여기에서 사용하는 프로세스를 홍보하기 위해 누구든지 빌려줄 수 있는 추가로 친절한 말을 해주시면 대단히 감사하겠습니다. 👍

한숨 ... uservoice처럼 사람들이 물건에 투표하도록 하고 결국 인기가 있더라도 그것에 대해 아무 것도 하지 마십시오!

업데이트:
https://github.com/microsoft/xaml-standard

@Mike-EEE가 이것으로 매우 기뻐할 것이라고 확신합니다 ;P

대단한 움직임입니다. @RichiCoder1 을 공유해 주셔서 감사합니다.

불행히도 UI 전용입니다. Sharepoint 및 WF와 같은 XAML의 다른 용도는 아마 없을 것입니다.

그러나 그렇습니다. 최소한 지원되는 모든 플랫폼에서 XAML을 표준화하는 데 도움이 될 것입니다.

호수!

그들이 그것을 레이어로 나누기를 바랍니다.

예를 들어 UI가 아닌 기본 XAML 레이어와는 별도로 XAML 3D 레이어를 보고 싶습니다.

@galvesribeiro 누군가가 문제를 만든 것 같습니다. https://github.com/Microsoft/xaml-standard/issues/23 +1하겠습니다. 최종 표준이 분리되지 않을 이유가 없습니다.

@Mike-EEE가 이것으로 매우 기뻐할 것이라고 확신합니다 ;P

ㅎㅎ 그리고 맞아요, @RichiCoder1! 모든 것이 잘못되고 고장났고 있어야 할 곳이 없었지만 이제 시작입니다. ;) 알려주셔서 감사합니다. 👍

그리고 누군가가 https://github.com/Microsoft/xaml-standard/issues/23을 만드는 것을 보게 되어 매우 기쁩니다. 그래서 저는 그렇게 할 필요가 없습니다. ;) ;) ;)

XAML Standard!!에 WF(Workflow Foundation) 포함을 고려하십시오.

@Suriman 투표 부탁드립니다!
https://github.com/Microsoft/xaml-standard/issues/23

그래서 저는 묻고 싶지 않습니다. 좋은 리포지토리/발행 시민이 되기 위해 그렇게 합니다. 하지만 이 문제가 더 이상 필요합니까? 내 말은, 그 리포지토리는 이미 이 문제가 할 수 있는 것보다 훨씬 더 자세한 내용이 포함된 50개 이상의 문제를 기록하고 있습니다. 그것은 이미 자신의 삶을 가지고 있는 것 같습니다!

이 문제를 계속 공개해야 하는 이유가 있습니까? 내가 뭔가를 완전히 오해하지 않는 한(매우 가능성 있음) Xaml Standard를 사용하여 여기에서 목표를 달성했다고 생각합니다. 그것은 커뮤니티 중심이며 개인적으로 가장 중요한 모든 것입니다. :)

@Mike-EEE 두 문제 사이에는 미묘한 차이가 있습니다. 하나는 XAML 자체 내에서 사용 가능한 API를 표준화하는 것(엄격히 XAML 자체에서)이고 다른 하나는 XAML을 System.Xaml과 유사한 .NET Standard 구성 요소로 지원하는 것입니다.

@lokitoth 는 이에 대한 대화를 확실히 열려 있습니다. 저는 여전히 모든 새로운 부분을 애쓰고 있기 때문입니다. 새로운 .NET Standard2.0에서 "바로 작동하는" 코드를 보여주는 @terrajobst 의 훌륭하고 유익한 비디오 를 시청하도록 제안하는 것으로 시작하는 것이 가장 좋습니다. 저는 개인적으로 이것이 System.Xaml에 어떤 영향을 미치는지에 대해 생각하지 않았습니다. 내 생각은 "그냥 작동"해야하지만 아마도 나는 지금 여기에서 착각하고 있다고 생각하기 시작했습니다 (정말로 너무 좋습니다).

그리고 솔직히 말해서, Xaml Standard 리포지토리에서 이 스레드 중 몇 개를 읽은 후, 저는 이전 제안에 대해 일종의 내 자신을 발로 차고 있었습니다(☕️ 커피 덕분에 그렇게 했습니다, 맹세합니다! ☕️). 보기에 "Xaml Standard"는 해당 리포지토리에서 주로 논의되고 있는 "MSFT UX/UI Standard"로 더 잘 명명됩니다. 현재로서는 강력한 직렬화 기술인 Xaml이 전혀 제시/전시/강조되지 않고 있으며(여기서 노력한 소수의 용감한 목소리를 제외하고) 일부 연결 끊김/혼란도 초래하고 있습니다.

저는 개인적으로 이것이 System.Xaml에 어떤 영향을 미치는지에 대해 생각하지 않았습니다.

.NET Standard 2.0 컨텍스트에서 종속성 트리를 로드할 수 있는지 여부를 파악하려면 어셈블리를 검사해야 합니다. 순수한 .NET인 경우 작동할 가능성이 높습니다(.NET Core의 도구 체인으로 가져올 BAML, Embedded Resources 등과 같은 전체 컴파일 시간 항목 집합이 있지만)

보기에 "Xaml Standard"는 해당 리포지토리에서 주로 논의되고 있는 "MSFT UX/UI Standard"로 더 잘 명명됩니다.

제 생각에는 UWP/Xamarin.Forms의 컨텍스트에서 발표되는 기능에 가깝습니다. 즉, "BigXaml"에 노출되지 않았을 수 있는 두 플랫폼에 중점을 둔 개발자가 주로 기여하는 것입니다. 몇 가지 "모든 WPF XAML 언어 가져오기" 문제가 열렸습니다.

팀이 해야 할 정리 작업이 많이 있고 현재 새 문제의 비율이 기여하는 사람들의 수에 비해 상당히 높다는 점을 감안할 때 팀이 문제를 해결하는 데 시간을 좀 더 주고 싶습니다.

@Mike-EEE @terrajobst @terrajobst @cwensley @mellinoe
Xaml Standard에서 문제를 만들었습니다.
https://github.com/Microsoft/xaml-standard/issues/57

@juepiezhongren, 머리를 들고 대화에 기여해 주셔서 감사합니다!

@lokitoth https://github.com/Microsoft/xaml-standard/issues/23 이 일광에 적합하지 않다고 결정되었기 때문에 이 문제를 그대로 유지하게 되어 기쁩니다.

그러나 당면한 문제를 더 잘 설명할 수 있는 새로운 문제를 만들었으며 여기에 찬성 투표 및/또는 기여를 추가하면 굉장할 것입니다. https://github.com/Microsoft/xaml-standard /이슈/145

명확히 하자면, 당신이 찾고 있는 것은 실제로 _JavaScript_+HTML5+CSS3 생성 아티팩트입니다. TypeScript는 실제로 JS용 트랜스파일러입니다. .NET 변환기를 만들어 브라우저에서 효과적으로 실행되는 표준 호환 JS를 만드는 대신(예: JSIL ), MSFT는 C# 작성자의 귀중한 시간을 사용하여 효과적이고 궁극적으로 이와 경쟁할 무언가를 만들기로 결정했습니다.

나는 이것을 시작하지 말라고 말하고 싶지만, 나는 결코 멈추지 않았다고 생각합니다. 😛

또한 또 다른 요점은 CSHTML5 가 @weitzhandler 를 찾고 있는 것과 매우 유사하지만 클라이언트/서버 어셈블리(예: PCL) 간에 공유 코드를 허용하지 않는다는 것입니다. 따라서 여전히 유지해야 할 두 개의 서로 다른 호환되지 않는 코드 기반이 남게 되어 .NET과 JS(또는 TypeScript 😉) 간에 동일한 비용/비즈니스 문제가 발생합니다. 이 문제는 엄격한 NodeJS 솔루션에는 존재하지 않습니다.

내 꿈은 도트 넷 코어가 있는 데스크탑 앱에 Android xml ui 쓰기 스타일을 사용하는 것입니다! 네 진짜로 요!!

XAML을 .NET 코어로 이식하려는 모든 노력은 기꺼이 자원하겠습니다.

CoreWf (net standard 2.0의 WorkflowFoundation)에 대한 수정 사항 에서 Xaml 에서 DynamicActivity 로드 를 허용하려면 System.Xaml 또는 더 호환 가능한 Portable.Xaml 구현이 필요할 수 있음을 알 수 있습니다. System.Xaml을 사용하여 기본 DynamicActivity를 로드하는 .net 프레임워크에서 CoreWf를 실행하고 있지만 Portable.Xaml을 사용하는 .net 코어의 잘못된 구문 분석 상태로 인해 여전히 실패합니다.

한 가지 질문은 System.Xaml에 대한 코드가 Mit 라이선스 참조 소스 리포지토리에 추가되지 않은 이유입니다. 라이선스, 특허 또는 기타 문제가 있습니까? 문제가 없다면 이 코드를 참조 소스에 추가하면 커뮤니티에서 CoreWf를 지원하는 데 필요한 이식을 수행할 수 있습니다. 참조 소스 리포지토리 는 Microsoft가 System.Xaml을 지원하도록 커밋하지 않습니다. System.Xaml을 열도록 요청하는 문제를 추가해야 합니까?

System.Xaml이 열려 있지 않으면 WorkflowFoundation에 대한 Xaml 코드를 구문 분석하고 토큰화하는 올바른 단계를 설명하는 테스트 형식으로 문서(Xaml 사양 외) 또는 지원을 받을 수 있습니까?

안녕하세요 FWIW @karelz 여기에 DevOps 시나리오에 대한 몇 가지 생각을 넣었습니다.
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/31381861-innovate-the-xaml-designer-dawg

Visual Studio Xaml Designer의 몇 가지 멋진 사건을 기반으로:
https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/

내가 그것에 있는 동안 여기에서 언급할 것이라고 생각했습니다. 👍 게다가, 이 스레드는 충돌로 인해 기한이 지났습니다. 😆

@weitzhandler 업데이트해야 합니다. mono-wasm이 알파 방식이기 때문에 js를 잊어버릴 시간이 거의 다 되었습니다.

@weitzhandler 2년 또는 3년이 필요하지만 전체 스택이 아니라 .net용 범용 스택입니다.

CoreRT는 https://github.com/dotnet/corert/pull/4480 에도 있습니다. 내년에 프로덕션 준비가 된 HTML+CSS+C# 콤보를 기대합니다.

제안된 .net 호환성 팩 에는 System.Xaml 가 포함되어 있을 수 있으며 이 문제와 연결되어 있을 수 있습니다.

분명히 이 문제는 compat pack 2.1에 연결되었습니까? 누군가 확인할 수 있습니까? 나는 그것이 netfx-compat-pack으로 태그가 지정되었지만 버전이 아닌 것을 보았습니다. 하지만 지금까지 발생한 모든 일을 처리하겠습니다. 😄

실망하기는 싫지만 compapt 팩의 문제를 일괄 업데이트할 때 실수로 이것을 2.1로 표시한 것 같습니다. 나는 제안서의 아마도 상태를 반영하기 위해 Future로 옮겼습니다.

@Mike-EEE xamarin.wasm이 도착할 것 같습니다.
https://github.com/mono/mono/pull/5924#issuecomment -343551464

업데이트를 주셔서 감사합니다. 저를 생각해주셔서 감사합니다. :) @terrajobst 정말 실망스럽습니다. 하지만 시간을 내어 체크인하고 업데이트해 주셔서 감사합니다. 나는 당신이 여전히 이 스레드를 더 이상 구독하고 있는지 여부를 확신할 수 없었습니다. 👼

우리는 뻔뻔하게 프로젝트를 연결하는 데 시간을 할애하고 있기 때문에(공식 Xaml 수정을 받기까지는 시간이 좀 걸릴 것입니다), 저는 잠시 시간을 내어 ExtendedXmlSerializer v2를 도우며 지난 1년을 보냈다는 점을 언급하겠습니다. 최근 출시된 것. 마크업 확장 및 연결된 속성 (POCO에서 작동, DependencyObject 필요 없음)에 대한 실험적 지원과 protobuf 스타일 매개변수 직렬화 기능이 있습니다.

System.Xaml이 도착하기를 기다리는 동안 Xaml-ish 기능을 찾고 있거나 추가하려는 경우 자유롭게 확인하거나 피드백을 제공 하거나 (더 나은 방법은) 리포지토리에 PR을 제출하십시오. 👍

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/

@danmosemsft 는 3.0 데스크톱 이니셔티브의 일부로 SDK 프로젝트에서 Workflow Foundation xaml을 지원합니까?

@lokki 나는 계획을 모른다. @terrajobst @karelz?

@danmosemsft
".NET Core의 일부로 UI 프레임워크 제공"이라는 문제가 없는 이유는 무엇입니까?

이 문제는 UI 프레임워크의 부족에 대해 구체적으로 이야기하지 않으며 여기 사람들이 그것을 깨닫지 못하는 것 같습니다.
https://github.com/Microsoft/xaml-standard/issues/232 를 참조하십시오.

@weitzhandler 이 문제는 이제 나에게 훨씬 더 의미가 있습니다. 설명해주셔서 감사합니다.

.NET Standard에 포함된 System.Xaml 가 특히 XAML Standard와 함께 유용하다는 것을 알 수 있습니다.

"데스크톱 이니셔티브"를 올바르게 이해했다면 Windows만 대상으로 하는 한 과거에 사용할 수 있었던 .NET 라이브러리를 사용할 수 있어야 합니다(앱이 환경에 동적으로 적응할 수 있는지 확실하지 않음 기본 앱이 수행할 수 없는 경우 [예: Windows OS를 찾지 못하면 시작되지 않음] 플랫폼별 항목을 호출하는 여러 .NET Core 어셈블리를 만들어 수행할 수 있습니다. 앱이 실행 중임을 감지한 플랫폼에 따라 요청 시 로드)

@birbilis 가 충분하지 않습니다. 동일한 XAML은 모든 플랫폼에서 동일하게 렌더링되어야 합니다.

데스크톱 이니셔티브는 XAML에 관한 것이 아니라 .NET Core가 최소 공통 분모 사일로가 아니라 특정 플랫폼을 대상으로 할 수 있는(또는 이상적으로는 실행 중인 플랫폼에 동적으로 적응하는) 앱을 허용하고 그 중에서 가장 잘 사용하고 플랫폼별 통합 등을 수행합니다. 이 기능 위에 기능 기반 API를 구축하여 특정 기능의 가용성을 쿼리하는 앱을 작성할 수 있습니다. 또한 추상화/호환성 API는 API 작성자가 지원하는 데 관심이 있는 각 플랫폼에 대한 다른 구현에 연결하여 빌드할 수 있습니다.

현재로서는 Portable.Xaml 이 System.Xaml에 매우 가깝다고 생각합니다. 문제를 찾으면 피드백을 주십시오.

WPF 팀(@dotnet/wpf-developers)은 .NET Core 3.0용 WPF의 오픈 소싱을 발표했습니다 . 그 일환으로 .NET Core 3.0용 미리 보기 빌드에는 이제 System.Xaml이 포함되며 해당 소스는 https://www.github.com/dotnet/wpf에서 사용할 수 있습니다.

BTW