단순히 .ui는 어떻습니까?

이 구분이 섬이 아닌 경우에도 도움이 될 수 있습니까? 아니면 더 혼란스럽습니까?

또는 이것이 동일한 솔루션에서 WPF와 WinUI Xaml을 구별하는 데 주로 도움이 되는 경우 .winui.xaml 또는 .island.xaml 와 같은 규칙은 어떻습니까? 그러면 기존 도구를 더 쉽게 사용할 수 있습니다.

XAML Islands 시나리오 또는 모든 곳에서 사용할 수 있습니까? 다른 모든 시나리오의 경우 혼란을 일으키고 사람들이 마이그레이션하도록 하는 것 외에(그리고 아마도 이전 버전의 VS와 같은 많은 도구에 대한 이전 버전과의 호환성을 깨는 것 외에) 이것의 가치가 무엇인지 알 수 없습니다. "whatever.winui.xaml"과 같은 규칙은 아마도 덜 파괴적일 것입니다. 그러나 나는 여전히 그것이 다른 곳에서는 아닌 섬의 범위에서만 유용하다고 봅니다.

제목을 변경하면 논의 범위를 XAML Islands로만 좁히고 싶지 않습니다.

나는 .xaml을 계속 사용한다고 말합니다. WinUi의 범위(및 이름)는 창 외에 다른 플랫폼을 포함하도록 변경될 수 있습니다(UnoPlatform을 통해?). 프로젝트 이름이 변경되면 어떻게 됩니까?

나는 NO 쪽으로 더 기울고 있다. Microsoft는 때때로 제품/서비스 또는 해당 사용자(의견)에게 피해를 주기 위해 제품 및 서비스에 대해 너무 많은 이름을 변경했습니다. 이것은 또 다른 이름입니다.

XAML Islands 시나리오 또는 모든 곳에서 사용할 수 있습니까? 다른 모든 시나리오의 경우 혼란을 일으키고 사람들이 마이그레이션하도록 하는 것 외에(그리고 아마도 이전 버전의 VS와 같은 많은 도구에 대한 이전 버전과의 호환성을 깨는 것 외에) 이것의 가치가 무엇인지 알 수 없습니다. "whatever.winui.xaml"과 같은 규칙은 아마도 덜 파괴적일 것입니다. 그러나 나는 여전히 그것이 다른 곳에서는 아닌 섬의 범위에서만 유용하다고 봅니다.

어디에나

XAML은 .xaml 을 유지해야 하지만 기존 XAML과 함께 대체하거나 유용하게 사용할 수 있는 새로운 것이 표시 된다면 .winui 확장이 유용할 수 있습니다. #804 :)

이 요청은 저를 완전히 혼란스럽게 합니다. 무슨 일이 일어나고 있는지 이해하기 위해 이 문제를 두 번 읽어야 했습니다... 이것은 다른 방언보다 xaml 생태계를 정말로 조각화할 것입니다..

지금 할말을 잃었다...

@liquidboy 글쎄, 이것은 이 변경을 하지 않는 것에 찬성하는 적어도 하나의 분명한 피드백입니다 :) 당신의 목소리를 빌려주셔서 감사합니다.

@jesbis 의 아이디어가 마음에 듭니다. 아마도 *.islands.xaml 를 추가하여 Islands 컨텍스트에서 실행되는 XAML 파일과 실행되지 않는 XAML 파일의 차이점을 더 쉽게 구별할 수 있을 것입니다.

궁금합니다. .islands.xaml 를 섬의 XAML 파일에만 적용하는 것이 좋을까요, 아니면 .winui.xaml 를 모든 곳에서 전체 확장으로 사용하는 것이 좋을까요? 나는 그 두 가지 아이디어 중 어느 것이 더 좋은지 잘 모르겠습니다.

내 투표는 ".islands.xaml" 또는 유사 섬에서 권장되는(그러나 엄격하게 시행되지는 않음) 패턴이며 다른 모든 곳에서 .xaml 파일은 여전히 ​​.xaml 파일입니다. 그렇게 하면 섬을 사용하지 않는 사람들에게 불필요하게 영향을 미치는 것을 피할 수 있습니다.

나의 가장 큰 관심사는 모든 도구에서 온다. 다른 확장자는 문제가 없지만 .xaml 파일 확장자에 의존하는 모든 도구는 업데이트해야 함을 의미합니다(R#, XamlStyler 등과 같은 것을 생각하고 있습니다). xaml 주변의 도구 지원은 이미 어려움을 겪고 있는 것처럼 느껴지며, 이로 인해 상황이 더 악화될 것 같습니다.

내 $0.02

아마도 문제 제목은 다음과 같이 변경되어야 합니다.
Xaml Islands에 포함된 XAML 파일은 WinUI 3 프로젝트와 다른 파일 확장명을 가져야 합니까?

나는 거기에 .xaml을 유지하는 것을 강력히 찬성합니다. .ui.xaml 또는 .xaml.ui로 이동할 수도 있지만 기술은 강력하고 계속해서 도움을 받을 수 있습니다. 반면에 불행히도 xaml은 wpf 성능 함정, Silverlight 및 Windows Phone 이후에 약간의 낙인이 있으므로 더 깨끗한 파일 이름이 코너를 돌 때 도움이 될 수 있습니다. 나는 여전히 xaml을 사랑하지만 명확하게 생각하지 않는 한 기술 이름에 대해 더 이상 혼동할 필요가 없습니다.

winui가 크로스 플랫폼이 된다면(많은 Windows 제품이 그러하듯이) 더 적합할 것이기 때문에 단순히 .ui로 사용하는 것이 좋다고 생각합니다.

이것은 미래의 증거가 될 것임을 의미합니다.

코드 파일의 확장자는 .ui.cs이며 이 확장자는 자체 설명이 가능하고 읽기 쉽습니다.

.winui.xaml

즉, .winui.xaml.cs 파일이 있다는 뜻입니까? 이크..

json 형식을 사용합니다. 2020년입니다.

JSON은 가혹하고 작업하기에 그다지 친숙하지 않습니다.

json 형식을 사용합니다. 2020년입니다.

JSON 형식은 사람이 읽을 수 있는 것이 아니라 컴퓨터가 읽기 위한 것입니다. 읽기도 어렵고 보기에도 좋지 않습니다.

.winui 하면 초보자가 포기할 것 같아요. 왜냐하면 우리는 새로운 언어를 배워야 한다고 생각할 것이기 때문입니다. 이제 WinForms와 WPF, UWP와 SL, ASP와 ASP.NET Core가 있습니다. 우리는 그것을 배우는 데 점점 더 많은 시간을 할애해야 하지만 상속해서는 안 됩니다. 나는 우리가 항상 새로운 기술을 만들어야 한다고 생각하지 않습니다.

죄송합니다. 저와 많은 제 친구들은 새로운 것을 배우는 것을 좋아하지 않습니다. 우리가 소수를 기대하지 않는다면, 우리는 기술을 상속받을 수 있고 재사용하고 호환될 수 있도록 만들어야 합니다.

제 생각에는 "어떤 XAML이 무엇인지"에 대한 보다 우아한 솔루션은 이 주석에서 @grokys 가 제안한 것처럼 기본 xmlns 네임스페이스에 의존하는 것입니다: https://github.com/AvaloniaUI/AvaloniaVS/issues/95# 이슈코멘트

UWP에서는 이 작업을 수행하지 않았지만 WinUI용으로 변경할 수 있습니다.

내 의견으로는 "어떤 XAML이 무엇인지"에 대한 보다 우아한 솔루션은 이 주석에서 @grokys 가 제안한 것처럼 기본 xmlns 네임스페이스에 의존하는 것입니다: AvaloniaUI/AvaloniaVS#95 (comment)

UWP에서는 이 작업을 수행하지 않았지만 WinUI용으로 변경할 수 있습니다.

HTML에서와 같이 Doctype과 동일한 기능을 도입할 수 있습니까?

HTML에서와 같이 Doctype과 동일한 기능을 도입할 수 있습니까?

아마도, 하지만 우리는 그럴 필요가 없습니다. 기본 네임스페이스는 서로 다른 플랫폼을 구분하는 것이어야 합니다(결국 코드 숨김에서 수행함).

xaml 주변의 도구 지원은 이미 어려움을 겪고 있는 것처럼 느껴지며, 이로 인해 상황이 더 악화될 것 같습니다.

@keboo 이것은 저에게 정말 큰 힘이 되었고, 우리가 바로잡고 올바르게 하도록 제가 열심히 밀어붙이는 것입니다.
우리가 그들을 구별할 수 없는 세계에 있다는 사실(섬 시나리오의 경우)은 도구가 수년에 걸쳐 어떻게 발전해 왔는지의 산물입니다. 모든 것이 완전히 분리되어 있으며 다른 방언 간의 차이를 합리화하는 것은 거의 불가능합니다. 이를 변경하고 모든 XAML 방언에서 쉽게 공유할 수 있는 XAML 구문 분석 및 컴파일을 만들기 시작합니다. 이 예제에서 WinUI와 WPF는 동일한 기본 엔진을 사용합니다. 도구는 기본 네임스페이스에서 선언한 대로 플러그인 가능해야 하며 필요한 경우 사용자 지정할 수 있습니다. 제 생각에는 이 시나리오가 제대로 작동하려면 그 이상은 필요하지 않습니다. 비록 큰 노력이지만 나에게 그것은 우리 모두가 해야 할 옳은 일입니다.

@stevenbrix 플랫폼은 현재 XAML이 Island 상황에서 사용되는 시점을 이해하지만 이 문제에 대해 읽은 내용은 개발자가 WinUI 3.0 내에서 .xaml 파일이 사용되는 방식을 말하고 이해할 수 있는 방법입니다. 프로젝트.

일반적으로 XAML 도구는 디자인 타임 경험 IMO를 완전히 다시 해야 합니다. Expression Blend는 XAML 디자인 및 개발이 최상위 계층으로 느껴졌던 마지막 시간이었습니다.

XAML의 특성 때문에 서면 형식과 시각적 형식이 모두 있습니다. Visual XAML 디자인은 Intellisense를 좋은 품질로 가져오기 위해 뒷걸음질쳤습니다. 강력하고 성능이 좋으며 프로토타입을 만들고 XAML 디자인을 다듬기 쉬운 환경이 있다면 커뮤니티에 활력을 불어넣을 수 있습니다.

제어 또는 툴킷 공급업체가 수행할 많은 작업을 필요로 하지 않는 플러그인 접근 방식은 여전히 ​​좋은 디자인 시간, 도구 팔레트, 요소 속성 경험을 제공하면서 매우 도움이 될 수 있습니다. XAML이 다른 비전통적인 폼 팩터로 이동함에 따라 디자인 워크플로를 고려해야 합니다. 두 개의 창 보기(Neo 및 Duo), 창 호스팅되지 않은 XAML 표면, 셸 통합, 혼합 프레임워크 프로젝트(xaml 섬, GDI 및 WinUI 믹스), Hololens Spatial 3D, 회전 표면 허브 등

그러나 선언적 마크업은 더 이상 이를 처리하는 이상적인 방법이 아닐 수 있습니다. 아니면 XAML 콘텐츠와 XAML 스타일을 더 많이 분리해야 합니까? HTML과 CSS처럼?

WinUI는 사물을 있는 그대로 이어갈 뿐만 아니라 향후 수십 년을 계획할 수 있는 좋은 기회라고 생각합니다.

아뇨. 요점을 모르겠습니다. 아무 것도 해결되지 않습니다.
있는 경우 이미 xaml 확장을 알고 있는 편집자에게 문제가 발생합니다.
나는 매일 wpf, uwp 및 Forms xaml로 작업하며 확장으로 인해 혼란스러워 한 적이 없습니다.

툴링이 더 쉽다는 것이 Xaml의 요점 아닌가요? 파일 확장자에 대한 고대 개념에 의존하지 않고는 도구가 이것을 알아낼 수 없습니까?

내 말은 일반적으로 UI 프레임워크에서 아무 것도 변경되지 않는 경우, 즉 여전히 XAML인 경우 수행하지 마십시오.

완전히 새로운 UI 프레임워크였다면 문제가 없었을 것입니다.

또한 제안된 islands.xaml 를 사용하여 섬에 대한 XAML 구성 요소를 차별화하려는 이유도 모르겠습니다. 툴링에서 다른 작업을 수행합니까 아니면 솔루션에서 가독성을 위한 것입니까?

내 첫 번째 생각은이 아이디어가 절대적으로 마음에 들지 않는다는 것입니다. 그러나 아마도 나는 그것이 해결할 수 있는 실제 문제를 보지 못하고 요점을 이해하지 못할 수도 있습니다.

xaml이 포함된 파일이 있으면 .xaml 파일로 만들고 싶습니다. 과거에는 UWP .xaml 파일의 이름을 WPF .xaml 파일과 다르게 지정하고 싶다는 생각을 한 적이 없습니다.

다음으로 파일 확장자의 프레임워크 이름은 프레임워크 이름이 변경될 수 있고 XAML이 XAML이기 때문에 좋은 생각이 아닌 것 같습니다.

따라서 제 의견은 다음과 같습니다. 확실히 .xaml을 사용하십시오.

그러나 파일 확장자가 .xaml인 옵션은 무엇입니까?
다른 .islands.xaml 파일 확장자는 무엇입니까? 이는 파일 확장자가 형식을 설명할 뿐만 아니라 파일의 내용에도 사용됨을 의미합니다. 음... 하지만 이것의 장점은 개발자를 위해 선택 사항으로 만들 수 있다는 것입니다. 사용하려는 경우 파일을 .islands.xaml이라고 부를 수 있으며 도구는 이를 다른 아이콘 등으로 선택합니다.

다른 기본 네임스페이스도 유효한 옵션입니다. 그러나 이는 도구의 경우 모든 .xaml 파일을 조사하여 어떤 종류의 파일인지 확인해야 함을 의미합니다. 또한 다른 루트 네임스페이스로 인해 XAML 방언이 다시 약간 분기된다는 의미이기도 합니다.

그러나 이제 완전히 다른 생각:

내가 올바르게 이해했다면 이러한 모든 변경 사항은 동일한 솔루션에서 플랫폼을 혼합하는 XAML Island의 경우에만 정말 도움이 되지 않습니까? WinUI만 사용하면 모든 XAML 파일이 WinUI를 사용한다는 것을 알 수 있기 때문입니다. XAML 아일랜드가 WinUI의 주요 시나리오가 될지 여부는 확실하지 않습니다. 과거에 WPF가 도입되었을 때 우리는 WPF와 WinForms 상호 운용성을 가지고 있었고 솔직히 말해서 저는 개발자가 WinForms 응용 프로그램에서 WPF 컨트롤을 사용하는 것을 거의 본 적이 없습니다. 대신, 그들은 WInForms에서 WinForms를 계속 사용했고 WinForms 대신 WPF로 새 프로젝트를 시작했습니다. 그리고 아마도 WinUI 3에서도 마찬가지일 수 있으며, 저는 그렇게 될 것이라고 생각합니다. XAML 아일랜드는 현대화에 좋은 방법이지만 내 경험에 따르면 개발자는 WPF/WinForms 앱에서 WinUI의 컨트롤이 확실히 필요한 경우에만 이를 수행합니다. 그렇지 않은 경우 이전 스택에서 계속 진행하고 새 스택에서 새 앱을 시작합니다. 이것이 진실일 필요는 없으며 제 경험일 뿐입니다. :-)

즉, 플랫폼의 기본 시나리오가 아닐 수도 있는 시나리오의 파일 이름을 변경하는 것에 대해 이야기하고 있습니다. 그리고 그것이 가치가 없다고 생각하는 이유라고 생각합니다. WPF/UWP/Silverlight/Windows Phone 개발자가 새 WinUI 3 프로젝트를 생성하면 어떻게 됩니까? 그들은 생각할 것이다

그들은 왜 .xaml 파일 확장자를 ...로 변경했습니까?

.xaml 파일 확장자를 제거하지 마십시오.

확장자를 변경하지 마십시오!

몇 년 전에 우리는 Avalonia에서 .paml 확장을 사용하기 시작했지만 문제가 발생했기 때문에 결국 .xaml 로 돌아갔습니다. XAML을 처리하기 위한 도구가 이미 IDE에 있습니다. , 적어도 그것은 뭔가!).

모든 XAML 방언이 고유한 파일 확장자를 가질 것으로 기대한다면 XAML을 사용하려는 모든 프로젝트는 도구의 100%를 처음부터 작성해야 합니다. 심지어 파일 이름 바꾸기 도구와 같은 것도 필요할 것입니다. 코드 숨김 클래스 등의 이름을 바꾸기 위해 매번 다시 작성해야 합니다.

위에서 언급한 @stevenbrix와 같이 XAML 파일의 어떤 언어가 파일 맨 위에 있는 기본 네임스페이스를 사용하는지 알 수 있는 완벽한 방법이 있습니다. 첫 번째 단계로 툴링이 이를 준수하도록 하십시오.

그런 다음 XAML 언어 서비스를 열고 디자이너와 상호 작용할 수 있는 API를 제공하면 모두가 혜택을 받을 수 있습니다. ;)

이쁘게 주세요 ;)

하지 말아야 할 또 다른 이유: UWP는 이미 채택 문제로 어려움을 겪고 있습니다. 이름을 바꾸면 "wpf와 거의 같은 것"이 아니라 또 다른 기술로 판매됩니다.
기존 uwp 생태계를 크게 손상시킬 WinUI 3.0 주요 변경 사항에는 이미 더 큰 문제가 있습니다. 다른 것을 추가하지 마십시오.
다른 UI 프레임워크에 사용하더라도 C#이 여전히 C#인 것처럼 여전히 xaml이며 다른 API 세트를 사용합니다. 사용할 수 있는 코드와 API는 변경되지만 여전히 동일한 언어입니다.

나는 반대표를 던지고 아무런 혜택도 보지 못하고 혼란만 가중시켰습니다.

하지 말아야 할 또 다른 이유: UWP는 이미 채택 문제로 어려움을 겪고 있습니다. 이름을 바꾸면 "wpf와 거의 같은 것"이 아니라 또 다른 기술로 판매됩니다.
기존 uwp 생태계를 크게 손상시킬 WinUI 3.0 주요 변경 사항에는 이미 더 큰 문제가 있습니다. 다른 것을 추가하지 마십시오.
다른 UI 프레임워크에 사용하더라도 C#이 여전히 C#인 것처럼 여전히 xaml이며 다른 API 세트를 사용합니다. 사용할 수 있는 코드와 API는 변경되지만 여전히 동일한 언어입니다.

@dotMorten Ha, C#에서도 같은 생각을 했습니다. .xaml 파일을 .winui 라고 부르는 경우 일관성을 유지하기 위해 .cs 파일을 .wincode 호출해야 합니다. :-)

어쩌면 나는 여전히 뭔가를 놓치고 있을지 모르지만 나에게 그것은 더 많은 혼란을 야기하고 그것의 진정한 이점을 보지 못합니다.

내 2센트, _.xaml_을 사용하세요.
흩어지지 말고 하나로 묶어주세요.

WPF와 WinUI 간에 작은 XAML 스니펫을 공유하려면 어떻게 해야 합니까? 나는 약간의 겹침이 있어야 한다고 생각합니다, 그렇죠? 공유 프로젝트를 덜 유용하게 만들 것입니다... 아니면 정말 큰 차이가 있습니까? 대부분 동일한 유사한 XAML인 경우 동일한 확장을 유지합니다. 형식이 전환 XAML과 대부분 다른 경우 확장을 변경하는 것이 다소 더 적합할 수 있습니다. 진짜 질문은 형식이 원본에 얼마나 가깝습니까?

XAML은 Windows뿐만 아니라 iOS, Android, macOS를 대상으로 하는 Xamarin에서도 사용됩니다.

.xaml을 .winui로 바꾸면 Xamarin이 XAML 파일에 대해 .xaml을 유지하고(iOS 또는 Android에 .winui를 사용하는 이유) UWP/WPF...와 같은 Windows 대상이 XAML 파일에 대해 .winui로 이동하는 상황이 생성됩니다. .

TL;DR 하나의 파일 형식/규칙 두 가지 이름(Windows의 경우 .winui, Xamarin의 경우 .xaml)이 혼란스럽습니다.

확장자는 xaml이라는 콘텐츠 구문으로 .xaml 여야 합니다. 다른 확장자는 혼란만 일으킬 뿐입니다.
.winui.xaml 와 같은 항목에 투표합니다.

".xaml"과 함께 유지, 강력한

Microsoft는 병적인 명명 문제가 있습니다!

그리고 이것은 정말로 그들 모두를 능가합니다.

아니

동일한 프로젝트 파일 내에 UWP XAML 및 WPF XAML이 필요한 경우 대신 새 Custom Tool 를 사용하세요.

이렇게 하면 도구는 XAML 파일이 UWP XAML 또는 WPF XAML을 사용하는지 감지하고 msbuild 대상을 통해 올바른 컴파일러로 보냅니다.

더 나은 방법은 XAML 언어를 표준화하여 공통 컴파일러, 바이너리 형식 및 프레임워크 라이브러리를 개발할 수 있도록 하는 것입니다.

그렇게 할 것입니다!

당신이 묻기 때문에, 아니 하지 마십시오.

도구가 차이점을 확인하기 위해 파일을 읽을 수 없는 경우 WORSE CASE는 ".winui.xaml" 등의 필요하지 않은 규칙이어야 합니다. 다시 키가 NOT-REQUIRED 입니다. xaml 확장 파일만 제대로 작동하지만 일부 향상된 도구가 누락되었을 수 있습니다.

나는 이 이면의 아이디어를 이해하지만 나쁜 해결책이라고 생각합니다.
첫째, WinUI는 파일 형식이 아니라 프레임워크 상용 이름입니다. 누군가가 버전 4에서 이름을 UniversalUI 또는 다른 이름으로 변경해야 한다고 결정하면 어떻게 됩니까? 파일 형식과 다른 파일 확장자와 다른 프레임워크 이름으로 끝납니다. 악몽일 수도 있다.

둘째, 기존 도구 및 문서와의 호환성을 깨뜨릴 수 있습니다. 미래의 개발자는 WinUI 파일이 내부적으로 xaml이라는 것을 분명히 할 수 없었으므로 xaml 문서를 관련 문서로 찾지 못할 것입니다.

셋째, Microsoft 제품에서 사용되는 UI 언어를 더 많이 조각화합니다. Xaml의 표준으로 더 나아가야 하므로 제품이 그렇게 중요하지 않습니다. C#은 Xamarin, Net Core, Windows 10 또는 WPF에서 동일합니다. 왜 XAML이 달라야 합니까?

사람들이 프로젝트를 정렬하고 코드를 구성하여 혼동되지 않도록 하십시오.

json 형식을 사용합니다. 2020년입니다.

@rickydatta 2020년에도 웹은 JSON 대신 HTML을 사용하여 사용자 인터페이스를 정의합니다. HTML 및 XAML과 같은 마크업 언어가 UI를 정의하는 데 좋은 이유는 여러 가지가 있습니다. JSON은 여러 면에서 훌륭하지만 UI를 정의하는 데에는 적합하지 않습니다. UI에 JSON을 사용하고 데이터 바인딩, 정적 리소스 참조 등과 같은 기능을 빌드하려고 하면 읽을 수 없게 됩니다. 하지만 여기서는 주제가 아니므로 그대로 두도록 합시다. JSON을 원하신다면 새로운 이슈를 만들고 커뮤니티가 이에 대해 어떻게 반응하는지 봅시다. :-)

나는 여기에 댓글을 달지 않으려고 정말 노력했습니다. 이것의 대부분은 이미 언급되었습니다. 그러나 나는 굴복했습니다. 죄송합니다. 나는 약하다.

하지마

변화를 만들고 싶다면 부정적인 것보다 더 큰 이점이 분명히 있어야 합니다.

잠재적인 이점은 무엇입니까?

• WinUI 컨트롤이 완전히 포함된 .xaml 파일과 포함하지 않은 .xaml 파일이 있는 사람들의 혼동을 방지할 수 있습니다.
• 잠재적으로 다른 .xaml 파일 콘텐츠로 작업하는 방법을 결정하는 도구를 활성화하는 데 도움이 됩니다.

그게 다야
나는 이 전체 스레드를 세 번 다시 읽었으며 여기에 나열된 다른 잠재적인 이점을 볼 수 없습니다.

잠재적인 단점은 무엇입니까?

• 혼란을 야기할 것입니다.
  -- "이 새로운 확장은 무엇입니까?" "열려면 무엇이 필요합니까?" "...와 어떻게 다릅니까?" "왜 바꿨어?"
  -- 기존 UWP XAML 및 WinUI3 요소를 혼합할 때 일부 WinUI 컨트롤만 포함하는 파일에 어떤 확장자를 사용합니까? 아니면 바로 이 제안이 이 기능이 사라질 것임을 의미합니까? (참고로, 파일 확장자를 변경하라는 제안을 하는 것만으로도 이미 더 많은 혼란과 FUD를 도입하고 있는 것입니다. 파일 확장자와 같은 것이 여전히 변경될 수 있는 경우, 아마도 더 안정적일 때까지 어떤 용량으로든 WinUI를 살펴봐야 할 것입니다. . 여러 사람들이 나에게 Flutter를 조사해 보라고 했습니다. 아마도 거기에 더 나은 미래가 있을 것입니다.)
  -- 기존 WPF 앱에서 Xaml Islands의 판매 포인트 중 하나에 대한 나의 이해는 XAML 작업에서 기존 기술과 지식을 재사용할 수 있는 능력을 의미한다는 것입니다. 이 변경 사항은 XAML만이 아니라 배워야 할 또 다른 사항이며 채택에 대한 또 다른 잠재적 장벽임을 시사합니다.)

• 불필요하다.
  -- 사람들이 솔루션 내에서 파일을 분할하려는 경우 이미 여러 가지 방법으로 이를 수행할 수 있습니다. 다른 프로젝트; 다른 디렉토리; 파일 이름의 접두사 또는 접미사 다중/하위 확장 사용 또는 VS 솔루션 탐색기 내에서 파일을 중첩할 수 있습니다. 새로운 확장 프로그램이나 모든 사람이 다중/하위 확장 프로그램을 사용하도록 하는 것이 이러한 옵션보다 더 나은 방법은 확실하지 않습니다.
  -- [기본값] 파일 내의 네임스페이스는 이미 사용 중인 XAML 방언과 가능한 XAML 언어를 도구에 알려줍니다. (이 영역에는 문서화되지 않은 문제가 있어 이것이 불가능할 수 있지만, 그렇다면 파일 확장자를 변경하는 것이 해당 문제에 대한 최상의 솔루션인 이유에 대한 추가 정보가 필요합니다.)

• 역사를 무시합니다.
  -- 이전에 WPF, Silverlight 및 Windows Phone을 대상으로 하는 프로젝트가 포함된 솔루션으로 작업한 적이 있습니다. 그들은 모두 다른 XAML 방언을 사용했지만 어떤 것이 사용 중인지 또는 파일 내에서 무엇을 할 수 있는지에 대해 한 번도 혼동하지 않았습니다. 저는 UWP 및 Xamarin.Forms용 XAML이 포함된 솔루션으로 작업했지만 이 문제의 이면에 있는 가정에서 예상되는 혼란을 경험하지 않았습니다. 나는 또한 유사한 솔루션을 가진 다른 많은 개발자들과 이야기를 나눴고, 다른 확장을 사용하는 것이 도움이 될 것이라고 말하는 사람을 본 적이 없습니다.
  -- XAML의 다른 방언이 있다는 것에 대해 들었던 모든 비판 중에서 파일 이름 지정에 따른 혼란은 결코 그런 비판 중 하나였습니다.
  -- 개발자들은 일반적으로 정당한 이유 없이 파일과 프로젝트의 이름과 구조를 어떻게 지정해야 하는지 알려주는 것을 좋아하지 않습니다. 유사한 내용의 파일이 포함된 프로젝트 작업과 같은 시나리오에 대한 지침 및 권장/제안 사례를 문서화하는 것이 훨씬 더 나을 수 있습니다.
  -- 파일에서 여러 확장자를 광범위하게 사용하지 않는 한 가지 큰 이유는 파일 탐색기(또는 OS에서 제공하는 선택기와 대화 상자를 포함하여 파일 시스템의 내용을 나열하는 모든 것)가 기본) 알려진 파일 확장자를 숨기도록 구성됩니다. 이렇게 하면 MyClass.winui.xaml 가 MyClass.winui 처럼 보이게 되어 파일이 무엇인지, 어디에서 왔는지, 왜 표시되는지 등에 대한 질문과 혼란을 야기할 수 있습니다.
  -- 다중/하위 확장자를 추가하면 파일 길이가 늘어나 MAXPATH 관련 문제가 발생할 가능성이 높아집니다. 언젠가는 이것이 문제가 되지 않을지 모르지만 우리는 아직 거기에 있지 않습니다. 이제 도구에 확장자에 대해 추가 6자가 필요했기 때문에 개발자가 파일(및 클래스, 일반적으로 두 파일이 동기화 상태로 유지되므로)에 덜 설명적인 이름을 지정하도록 강요받는 것을 보고 싶지 않습니다.

• 툴링 개발자에게 더 많은 작업을 제공합니다. (Microsoft 내부 및 외부 모두.)
  -- 처리해야 할 케이스가 더 많습니다.
  -- 문서화하고 테스트할 더 많은 시나리오.
  -- 버그 수정 및 새로운 기능에 소요되는 시간이 줄어듭니다. 현재 XAML 도구가 다른 기술에 비해 부족하고 사용자 지정 도구를 만드는 데 느린 것으로 인식되는 경우 새 도구를 빌드하는 속도를 느리게 만드는 작업을 수행하는 이유는 무엇입니까?

• 매우 나쁜 선례를 남길 위험이 있습니다.
  -- 이런 일이 발생했다면 현재의 모든 .xaml 파일을 .wpf , .uwp , .xamarinforms 등으로 바꾸는 것이 적절하지 않은 이유는 무엇입니까? 또는 .xaml2006 , .xaml20009 , .xaml-uwp5 사용 위치가 아니라 기본 네임스페이스가 핵심 문제인 경우? 이 경우와 같이 최소한의 잠재적인 이점이 있지만 많은 사람들은 Microsoft가 파일 이름 지정을 제안하는 방식으로 볼 수 있습니다. (누군가 여기 토론을 보고 그런 제안을 하지 않았다면 놀라지 않을 것입니다.)
  -- 하위 확장자를 기반으로 파일을 다르게 처리하는 MS가 제공한 도구를 알지 못하지만 수정하게 되어 기쁩니다. 하지만 이렇게 하면 Visual Studio(및 Windows Shell을 포함한 다른 것들)가 이러한 시나리오를 처리할 수 있습니다. 그런 다음 기능이 있으면 복잡하지만 불필요한 이름 지정 제안을 광범위하게 도입하려는 유혹이 일부 개발자에게 너무 많이 도입되어 나머지 개발자에게 혼란을 초래할 수 있다고 상상할 수 있습니다.

요약하면, 제안은 제한된 상황에서 이론적 이점을 위해 혼란과 더 많은 작업을 가져올 것입니다. 이렇게 했다면 윈도우 개발을 포기했을 것이다.

목소리를 빌려주신 모든 분들께 감사드립니다. 우리는 당신을 들었다! 충분한 피드백을 수집했으므로 .xaml 확장자를 변경하는 것은 불가능 하다고 단호하게 말할 수 있습니다.

생태계를 조각화하거나 제3자 도구를 깨는 것은 우리의 의도가 아닙니다(많은 것들이 있습니다). 우리는 XAML이 언어이고 WinUI 3이 XAML을 사용하는 UI 프레임워크라는 데 동의합니다. 이러한 모든 이유와 다른 이유로 xaml 확장을 계속 사용하는 것이 좋습니다.

우리 팀은 여전히 ​​숙제를 해야 하고 나중에 커뮤니티와 상의해야 할 다른 대안을 평가해야 합니다. 예를 들어:

1. 아무것도하지 마세요. XAML Islands 개발 경험은 다음과 같습니다. 다른 프로젝트의 XAML 파일(큰 문제가 아닐 수도 있음). WInUI 3은 동일한 네임스페이스를 사용하며 프로젝트에서 사용되는 유일한 XAML 언어이기 때문에 중요하지 않습니다.

2. 네임스페이스를 사용하여 XAML을 기반으로 하는 UI를 구분합니다. 오늘날 WPF XAML 및 UWP XAML은 동일한 네임스페이스를 사용합니다. 아마도 WinUI 3은 Xamarin Forms가 수행하는 것과 같은 다른 네임스페이스를 사용해야 하므로( "http://xamarin.com/schemas/2014/forms") 컴파일러, 도구 및 디자이너 파일을 구별할 수 있습니다. 반대로 이것은 오늘날에도 일어나고 있지만 이것은 방언을 생성할 것입니다. 이론적으로 이것은 개발자가 문서/블로그에서 XAML 예제를 복사하여 붙여넣는 것을 용이하게 하지만 불행히도 네임스페이스를 포함하지 않는 많은 샘플이 있습니다.

3. 섬을 위해 무언가를 하십시오. 모든 UI 프레임워크에서 차별화할 필요가 없습니다. 우리는 규칙을 사용할 수 있습니다. 예를 들어 미래에는 XAML Island가 있는 WPF 앱이 특정 폴더(islands 폴더?)에 XAML 파일을 포함할 수 있습니다. 이는 UWP 지역화(Strings/en-US/Resources.resw)와 유사합니다.

귀하의 피드백에 다시 한 번 감사드립니다 . 더 많은 아이디어가 성숙되면 새로운 토론을 열겠습니다.

섬 파일에 대한 스니핏 또는 doctype 스타일 라인을 포함하면 도구에 충분해야 합니다.

좋은 절충안이기 때문에 .ui.xaml 아이디어를 좋아한다면. 여전히 유효한 XAML 확장이며 올바른 편집기와 아이콘을 선택하는 데 도움이 될 수도 있습니다. 또한 형식을 찾기 위해 수십/수백 개의 XAML 파일을 열고 구문 분석하는 것보다 더 효율적입니다.

@marb2000 WinUI 3은 XAML을 사용하는 UI 프레임워크입니다.

해야 함: WinUI 3은 XAML을 사용할 수 있는 UI 프레임워크입니다. XAML을 사용할 필요가 없고 XAML 언어에 대한 종속성이 필요하지 않기 때문입니다.

우리는 XAML이 언어라는 데 동의합니다.

좋습니다. XAML이라고 하는 많은 네임스페이스는 WinUI에서 이름을 바꿔야 합니다. XAML 언어와 관련이 없는 모든 것입니다.

UWP가 강조되지 않는 것을 목격하는 것은 고통스러웠습니다. 이제 채널 9에서 UWP 콘텐츠를 검색하면 Xamarin 콘텐츠가 표시됩니다. 너무나 뻔한 책략입니다. UWP를 다른 것으로 변형하려는 시도를 중단하십시오! 재투자하고, 두 배로 줄이고, 작동하게 만드십시오. UWP에는 코스 수정이 필요하지 않으며, Xamarin 및 Office 팀이 참여해야 합니다. Microsoft 내부 정치가 UWP를 죽이고 있습니다.

@Noemata 공식 쪽지인가요?