커뮤니티 피드백을 들어주셔서 감사합니다. 저는 WinUI 3.0(Win32 + WinUI + C++)이 정말 기대됩니다. 이것은 우리가 기다려온 프레임워크처럼 느껴집니다! 립 GDI 😉

(Win32 앱 모델) + (WinUI 3.0 UI) + (.NET 또는 C++ 언어)

따라서 이것은 기본적으로 UWP UI이지만 전화와 같은 수명 주기와 샌드박스가 없습니까? 데스크탑 앱에 흥미로운 것 같습니다. 그러면 저는 이것을 실험할 것입니다.

업데이트에 감사드리며 WinUI 3.0의 초기 기능 세트가 잠기고 WinUI 3.0에 포함될 수 있는 새로운 제어 또는 제어 기능이 제안됨에 따라 더 많은 업데이트가 제공되기를 바랍니다.

아 그리고 데스크탑의 WinUI가 어떻게 작동하는지 그리고 UWP, WPF 및 Win32와 다른지 예방 하는 데 매우 유용할 것입니다.

아마도 Build!에서 얻은 아키텍처 다이어그램과 함께 프레임워크와 API의 조합에 포함된 훌륭한 매트릭스일 것입니다.

정말 대단합니다. 모든 것에 감사합니다!
xplat 섹션은 특히 Uno가 레이더에 있다는 사실을 알게 되었습니다.

우리의 초점은 여전히 ​​Windows 10 및 8.1이지만 일부 사용자는 여전히 Win7에 사용자 및 고객이 있다는 피드백을 듣고 시간이 지남에 따라 시장과 옵션을 평가할 것입니다.

이 UI 프레임워크의 이식이 이식성을 염두에 두고 설계되었다고 가정하면, 최소한 UI 코어(렌더링/입력)가 .NET Core 3+를 지원하는 모든 Windows OS에서 작동할 수 있을 정도로 충분합니다. Windows 7에는 어떤 제한이 있을까요? 이다? 사람들이 데스크탑에서 사용하는 대부분의 기능은 그냥 작동하는 것처럼 보이며, 그렇지 않은 특수/플랫폼 특정 기능의 경우 핵심 UI 시스템의 일부가 되지 않도록 하고 (Win10, Win8.1, Win7 Nugets 등).

또한 HTML(슬프게도 Xamarin은 아님)로 할 수 있는 것처럼 모든 장치(Win32, Android, iOS 및 WASM)에서 동일한 모양과 느낌을 가진 플랫폼 간 XAML이 있었다면 우리 회사는 몇 년 전에 뛰어 들었을 것입니다.

또한 여러분이 이것을 "마라톤(훌륭한 번지 게임도)"이라고 생각하게 되어 기쁩니다. XAML 공간에서 단편화가 적을수록 모두에게 더 좋고 많은 지름길을 선택하면 시작한 곳으로 돌아갈 수 있습니다. ;)

데스크톱의 WinUI가 작동하는 방식과 UWP, WPF 및 Win32와 다른 방법에 대한 문서가 매우 유용할 것입니다.

우리는 그것을 위해 노력하고 있으며 이것이 발전하는 대로 더 많은 것을 공유할 것입니다!

이 UI 프레임워크의 이식이 이식성을 염두에 두고 설계되었다고 가정하면, 최소한 UI 코어(렌더링/입력)가 .NET Core 3+를 지원하는 모든 Windows OS에서 작동할 수 있을 정도로 충분합니다. Windows 7에는 어떤 제한이 있을까요? 이다?

@zezba9000 WinUI는 .NET을 사용하지 않으며 WinUI와 함께 .NET Core를 사용할 필요가 없습니다. OS API를 기반으로 구축된 기본 프레임워크이며 Win8/Win10에 없는 새로운 기능에 의존합니다. Win7 - 경우에 따라 특정 컨트롤과 같은 상위 수준의 추가 기능뿐만 아니라 핵심 기능을 위한 것입니다.

데스크톱의 WinUI가 작동하는 방식과 UWP, WPF 및 Win32와 다른 방법에 대한 문서가 매우 유용할 것입니다.

우리는 그것을 위해 노력하고 있으며 이것이 발전하는 대로 더 많은 것을 공유할 것입니다!

이 UI 프레임워크의 이식이 이식성을 염두에 두고 설계되었다고 가정하면, 최소한 UI 코어(렌더링/입력)가 .NET Core 3+를 지원하는 모든 Windows OS에서 작동할 수 있을 정도로 충분합니다. Windows 7에는 어떤 제한이 있을까요? 이다?

@zezba9000 WinUI는 .NET을 사용하지 않으며 WinUI와 함께 .NET Core를 사용할 필요가 없습니다. OS API를 기반으로 구축된 기본 프레임워크이며 Win8/Win10에 없는 새로운 기능에 의존합니다. Win7 - 경우에 따라 특정 컨트롤과 같은 상위 수준의 추가 기능뿐만 아니라 핵심 기능을 위한 것입니다.

Windows 7 호환성을 위해 - 필요한 모든 OS 수준 API에 대한 일종의 대체 Shim뿐만 아니라 XAML에 대한 자체 호환 렌더러를 구축하려면 일부 타사가 필요합니다.

현재로서는 이것이 가능한지 알 수 없습니다. WinUI 비트가 OS에서 제거되면 다른 플랫폼에서 일종의 호환성 구성 요소를 제공할 수 있는 방식으로 오픈 소스 프로젝트에 삽입되기를 바랍니다. 사용자 지정 렌더러가 있는 Xamarin, Uno 또는 .Net Core를 생각해 보세요.

OS API를 기반으로 구축된 기본 프레임워크이며 Win7에는 없는 Win8/Win10의 새로운 기능에 의존합니다. 일부 경우 핵심 기능의 경우

내 생각에 "핵심 기능"을 구성하는 것은 물론 렌더링 및 입력 외에 OS 특성에 의존하는 것이 아닙니다. 이러한 경우에는 누구나 확장할 수 있는 추상화 계층이 됩니다. 기본 수준에서 이론상 사용자 지정 소프트웨어 렌더러로 UI를 렌더링하고 원하는 경우 가상 커서로 사용자 지정 XInput 백엔드로 입력을 수행할 수 있어야 합니다. 그런 종류의 모듈화를 할 수 있다면 거의 모든 것을 할 수 있고 플랫폼 지원을 확장하는 것이 매우 쉬워집니다(게임에서 수행되는 것처럼). 당신은 이 지역에서 조금 더 많은 시간을 보내고 길을 따라가면 모든 것이 훨씬 덜 노력할 것입니다. WPF XAML이 이런 방식으로 디자인되었다면 UWP 앱에서 가져와서 사용할 수 있었습니다. 그렇지 않으면 기술 부채는 끝없는 루프가 될 것입니다.

트레이 아이콘 지원 등은 "WinUI Windows 기본 기능(Win7-Win10)" 패키지에 포함될 수 있습니다. 푸시 알림과 같은 것은 "WinUI Windows 확장 기능(Win8-Win10)" 패키지에 포함될 수 있습니다.

그것이 의미가 있기를 바랍니다.

@mdtauk , @zezba9000 그것은 모두 이론적으로 가능하며 팀에 많은 플랫폼 추상화 전문 지식이 있습니다. 모든 것이 그렇듯이 비용, 일정 및 예상되는 이점으로 귀결됩니다 😊

개발 및 테스트 비용(예: 모든 것이 오래된 보조 기술과 함께 작동하도록 하는 것과 같이 잠재적으로 명확하지 않은 영역으로 확장될 수 있음) 외에도 장기간에 걸친 지원 비용을 고려해야 합니다.

2020+에서 Win7에 새로운 고객이 생길 것으로 예상하십니까? 피드백과 명확한 사용 사례는 우선 순위를 정하는 데 도움이 됩니다.

개발 및 테스트 비용(예: 모든 것이 오래된 보조 기술과 함께 작동하도록 하는 것과 같이 잠재적으로 명확하지 않은 영역으로 확장될 수 있음) 외에도 장기간에 걸친 지원 비용을 고려해야 합니다.

2020+에서 Win7에 새로운 고객이 생길 것으로 예상하십니까? 피드백과 명확한 사용 사례는 우선 순위를 정하는 데 도움이 됩니다.

@jesbis WinUI 3.0(Linux, Android, iOS, iPadOS 및 MacOS)용 Win7에 호환성을 추가하는 데 많은 이점이 있지는 않지만 기본 UI 프레임워크에 의존하지 않는 크로스 플랫폼 솔루션을 제공하는 데는 이점이 있을 수 있습니다.

@mdtauk
@jesbis WinUI 3.0(Linux, Android, iOS, iPadOS 및 MacOS)용 Win7에 호환성을 추가하는 데 많은 이점이 있지는 않지만 크로스 플랫폼 솔루션을 제공하는 데는 이점이 있을 수 있습니다.

동의합니다. 웹 어셈블리를 추가하면 Linux보다 훨씬 더 중요합니다.

2020+에서 Win7에 새로운 고객이 생길 것으로 예상하십니까? 피드백과 명확한 사용 사례는 우선 순위를 정하는 데 도움이 됩니다.

아니요 우리 회사는 그렇지 않습니다. 나는 모든 반복에서 XAML이 어려움을 겪는 것을 본 영역에서 더 많은 디자인 인수를 제공했지만(내 관점에서) MS가 거기에서 시간을 보내고 싶지 않은 이유를 완전히 알았습니다. 그러나 WinUI가 다른 사람들이 필요한 경우 이 작업을 수행할 수 있을 만큼 충분히 능력이 있다면(이는 내가 알아차린 경향이 있음) 지금 WPF의 경우와 같이 Windows 종속성의 토끼 구멍에 빠지지 않고서도 멋질 것입니다.

우리 회사가 보고 싶어하는 것은 Android 및 WASM 지원이 UNO(3년 전)보다 조금 더 공식적이라는 점을 명확히 하기 위한 것입니다. 우리는 일반적으로 Win32 API가 크게 필요한 시스템 설정 및 로컬 컴퓨터 모음의 상태를 제어하는 ​​관리 소프트웨어를 만듭니다(UWP는 우리에게 결코 작동하지 않지만 HTML 빌드 시스템과 달리 컴파일 시간 오류 때문에 UI를 좋아합니다). 클라이언트 + 우리는 균일한 경험과 느낌을 가진 Win32 + Android + 브라우저 UI 경험이 필요합니다. HTML은 기본 코드 기반이 C#에 있기 때문에 필요하지 않은 불필요한 추상화와 복잡성을 추가하기 때문에 큰 골칫거리입니다.

나중에 더 나은 피드백을 바랍니다.

또한 WASM은 다른 플랫폼에 비해 우리가 원하는 가장 큰 목표입니다. 지금까지!!
그것은 우리의 안드로이드 / iOS / 모바일 문제뿐만 아니라 웹 포털 문제를 해결합니다.

피드백을 들어주셔서 감사합니다!

Desktop + WASM은 금이 될 것입니다!

와우, 외쳐주셔서 감사합니다, @jesbis! 전혀 예상치 못한 일이며 대단히 감사하고 존경합니다. 👍

Windows 7에 대한 논의는 상당한 노력(비용은 말할 것도 없고)이 WinUI 3.0에 상당한 지연을 야기할 것이기 때문에 약간 산만합니다. Windows 7은 1월에 단종되며 모든 고객에게 Windows 10으로 업그레이드할 것을 권장합니다. 제 고객은 여기에서 다른 고객과 일치하지 않을 수 있지만 Windows 8.1도 우리에게 관심 있는 플랫폼이 아닙니다.

업데이트에 상당히 만족합니다. WinUI의 다가오는 목표는 매우 밝고 유망해 보입니다! Xplat 부분도 예상하지 못했던 부분인데 굉장히 반가워요. 개선 사항과 WinUI에 대한 유용한 기능을 사용할 수 있기를 기대합니다.

투명성을 위해 팀에 감사드립니다.

다양한 문제를 해결하는 데 도움이 되는 업무용 소프트웨어의 중요성을 언급하고 싶습니다.

나는 Lightswitch 도구로 한동안 일했고 건설 시간에서 상당한 이득을 얻었습니다. 신속한 애플리케이션 개발은 LOB 애플리케이션에 매우 유망합니다. 그러나 미국에서 특허 전쟁이 매우 심각하게 받아들여지면서 제품이 종료되었습니다.

다음 배달을 위해 INotifyDataErrorInfo가 있다는 것을 알고 있습니다. 그러나 WinUI에 3.x 이상과 같은 향후 제공을 위한 RAD 리소스가 있다면 훌륭할 것입니다.

감사합니다 팀, 웹 어셈블리에서 연필을 쓰는 날을 기다릴 수 없습니다. 그것은 나의 하루, 1년, 10년을 만들어 줄 것이며 MS를 기술 스택의 맨 위에 올려놓을 것입니다. WinUI + Xamarin + WASM + .NET => 순수함!!

@jebis 이 업데이트에 감사드립니다. 좋은 작업 팀 :+1:. 아직 초기 단계라는 것을 이해하고 있습니다. 언제 WinUI 3.0 이정표가 생성되고 이에 대해 태그가 지정된 문제가 나타날 것이라고 생각하십니까?

언제 WinUI 3.0 이정표가 생성되고 이에 대해 태그가 지정된 문제가 표시될 것이라고 생각하십니까?

@shaggygi 좋은 질문입니다! 방금 만들었습니다.

WinUI 3.0 이정표

멋지다 얘들아!

빠른 질문: Windows.UI.Composition을 Microsoft.UI.Composition으로 이동하면 2.2 또는 3.0에 더 가깝습니까?
그리고 이를 예상할 수 있는 기간에 3.0을 사용할 수 있게 되면 2-3개월 또는 그 이상이 될 것입니까?

앞으로 연도에 대해 이야기할 때("연말까지"에서와 같이) 달력 연도와 [Microsoft] 회계 연도에 대해 명확하게 말씀해 주십시오.
이것이 명시적으로 언급되지 않은 경우 혼동을 일으키기 쉽고 저는 이것이 사람들이 의도한 것보다 6개월 더 빨리 올 것이라고 믿게 한 경우를 알고 있습니다.

Windows.UI.Composition을 Microsoft.UI.Composition으로 이동하면 2.2 또는 3.0에 더 가깝습니까?

@jtorjo 이것은 3.0(최소)입니다. 3.0의 첫 번째 미리 보기에 초기 빌드를 포함하기를 희망하지만 아직 100% 보장되지는 않습니다.

앞으로 연도에 대해 이야기할 때("연말까지"에서와 같이) 달력 연도와 [Microsoft] 회계 연도에 대해 명확하게 말씀해 주십시오.

@mrlacey 감사합니다, 명심하겠습니다! 우리가 사용하는 모든 날짜는 일반적으로 달력 시간입니다.

@jesbis 좀 안타깝 네요. 그래서 3.0에 Microsoft.UI.Composition이 없을 가능성이 있다는 말씀이신가요?

@jtorjo

3.0 의

종종 많은 미리 보기 릴리스가 있습니다. 예를 들어 .NET Core 3은 Preview 6에 있습니다.

우리의 계획은 3.0에 구성 API를 포함하는 것입니다.

Xaml 프레임워크 부분은 구성 부분보다 먼저 오픈 소스가 될 것입니다.

@jebis 감사합니다, 좋은 소리입니다!

환상적인 로드맵, 수고하셨습니다!

여기 있는 모든 사람들과 마찬가지로 저는 투명도를 좋아하고 WinUI 3.0을 정말 기대합니다. 나에게 WinUI 3.0은 WPF가 2006년에 도입된 이후 가장 흥미로운 것입니다.

또한 여전히 Windows 7을 실행하는 고객이 있지만 Windows 10 지원이 가장 중요하다고 생각하며 Win7 지원을 위해 시간과 리소스를 소비하지 않을 것입니다. 제가 근무하는 대부분의 회사는 10으로 전환하고 있습니다. 그리고 2020년 말에는 여전히 Windows 7을 사용하는 유일한 회사가 제 치과 의사가 될 것이라고 생각합니다. 그리고 그가 나에게 Windows 앱을 작성해 달라고 요청한다면 나는 그의 PC를 Windows 10으로 마이그레이션할 것입니다. :-)

향후 WASM 지원은 놀랍습니다.

어제 회의에서:

@jesbis 와 우리 팀이 여기에 글을 쓰고 참여한다는 것을 보여주는 작은 이야기는 흥분된 빙산의 일각에 불과합니다. :-)

어제 독일에서 열린 개발자 회의에서 일부 .NET 개발자와 채팅을 하고 WinUI 3.0에 대해 이야기했지만 그들은 그것에 대해 몰랐습니다. 나는 그들에게 로드맵에 대해 이야기했고 그들은 말했다.

"와, 놀랍네요."

그룹의 한 소녀가 나에게 물었다.

"그런데 이 모든 것을 우리에게 말해도 됩니까?"

나는 그녀와 다른 사람들을 보았고, 그리고 나서 다시 말을 할 기회를 잡았습니다.

await Task.Delay(3000);

내가 말하기 전에

"네! GitHub에서 이 모든 것을 읽을 수 있습니다."

@jebis 와 관련된 모든 분들께 감사드립니다. Windows 개발자가 되기에 좋은 시간 ❤️

Word와 같은 자사 응용 프로그램이 WinUI의 계층을 사용할 수 있기를 희망하고 개발자가 "이봐, WinUI는 장난감이 아니라 비즈니스를 실행할 수 있는 실제 제품입니다"라는 것을 보고 기뻐할 것입니다.
그들이 이미 그것을 사용하고 있다면 큰 소리로 말하십시오.

WPF, Win32 및 WinUI 데스크탑용 아크릴.

아 그리고 아마도 활성 Windows 정책 에서만 아크릴을 재고하십시오.

예, 모니터가 2개 이상인 경우 하나의 창에서 렌더링됩니다. 적어도 여러 모니터에서 제대로 작동해야합니다....

UWP 앱에서 사용할 수 있는 두 가지 UI 컨트롤 집합이 있는 개발 경험의 의미에 대해 생각하고 있었습니다. WinUI 컨트롤과 레거시 UI 컨트롤에 모두 액세스할 수 있을 때 C# 코드 숨김에서 IntelliSense는 항상 올바르게 요구하므로 Alt + Enter 대신 using 하고 계속 진행하는 대신 컨트롤을 가져와야 하는 네임스페이스를 선택합니다. 어떻게 든 이것을 피할 수 있습니까?

WinUI3가 개발자용으로 나오면 Windows 10 SDK는 지원되는 SDK가 설치된 상태에서 열리는 프로젝트의 네임스페이스 변경 제안 을 고려해야

WPF, Win32 및 WinUI 데스크탑용 아크릴.

내가 먼저 보고 싶은 것은 Xaml Islands를 충분히 성숙시키는 MS로, 예를 들어 제목 표시줄의 아크릴을 WinUI 기반의 UWP가 아닌 프로젝트에 사용할 수 있습니다( 이 게시물의 마지막 단락 참조). @marb2000 은 아마도 이것에 대해 질문할 사람일 것입니다.

@MartinZikmund 우리는 이 시나리오를 피하고 싶습니다. WinUI 3을 사용할 때는 패키지의 컨트롤에만 액세스할 수 있어야 합니다. 최신의 가장 큰 변화로 필요한 모든 것을 갖추고 있다는 생각입니다.

@MartinZikmund
@LucasHaines

한 가지 수정 사항은 빌드에서 Windows.UI.Xaml.* WinMD 참조를 제외할 수 있다는 것입니다. 이제 빌드 대상은 통합 WinMD(일명)만 참조합니다. Windows.winmd , 개별 WinMD도 참조하도록 대상에 옵션을 추가합니다. 그렇게 하면 빌드 중인 앱을 기반으로 참조를 포함하거나 제외할 수 있습니다.

이것이 .NET dll 처럼 동작하기 때문에 네임스페이스를 변경할 필요가 없습니다. 시스템 제공 버전이 아닌 패키지 내부의 어셈블리 리디렉션 을 사용할 수 있습니다.

이 방법이 .NET Framework용이라는 것을 알고 있지만 UAP의 경우 이러한 종류의 시나리오에 대한 솔루션이 있어야 합니다. msix/appx 매니페스트에 FrameworkDependency가 있다는 것을 알고 있습니다. 할 수 있습니다 우리는 함께 새로운 WinUI을 공급하기 위해 그것을 사용할 수있는 Windows.* 보다는 네임 스페이스 Microsoft.* 것들.

개발자 측에서는 코드가 아닌 참조 만 변경하므로 앱을 업그레이드하는 데 어려움이 덜할 것입니다!

네임스페이스를 전혀 변경하지 않는 것이 좋습니다!

혜택:

1. 코드를 앞뒤로 변경할 필요가 없습니다.

2. 로컬 WinUI 코드가 안정화되면 Windows 플랫폼으로 다시 병합하여 모든 새 Windows 릴리스에서 시스템 앱과 LOB 앱이 새로운 개선 사항을 활용할 수 있습니다.

3. 한편으로는 .NET Framework와 같이 호환성이 높은 매우 안정적인 시스템 프레임워크입니다. 그리고 다른 쪽은 .NET Core와 같으며 더 빠른 속도로 변경되며 두 가지의 모든 이점이 있고 문제가 없습니다.

교차 플랫폼 네이티브 앱으로 래핑된 Blazor + (비 HTML) UI에 대한 Steve Sanderson의 멋진 프레젠테이션을 방금 보았습니다. 약 52분 분량의 영상입니다. UWP, WinUI 및 C# 팬의 필수 보기입니다. 블레이저 진심 감동!!!

https://youtu.be/uW-Kk7Qpv5U

이 토론에서 내가 중요하다고 생각하는 한 가지 잊어버린 말은...
WinUI 3.0 자체에 성능 향상이 있습니까? XAML 렌더링 엔진이 방금 분리되었거나 변경 사항이 있습니까? XAML 컨트롤은 주로 컴포지션을 사용하므로 DirectUI와 같은 오프스레드 및 dwm 구동을 사용합니까?

일부 컨트롤 성능 및 RAM 사용량은 ListView/GridView = ItemsControl과 같이 훨씬 더 좋을 수 있습니다.

이것은 Windows 자체에서 볼 수 있습니다. Windows 8 시작 메뉴(DirectUI)는 Windows 10 XAML 시작 메뉴보다 훨씬 유연합니다.
Groove Albums 페이지와 같이 충분한 정보가 있는 GridView를 로드하려고 하면 일이 제대로 진행되지 않습니다. 이것은 iOS와 Android가 훨씬 더 잘 작동하는 것이므로 winforms, QT도 마찬가지입니다.
(WPF는 내 생각에 UWP XAML보다 훨씬 나쁩니다).

WinUI 3.0 자체에 성능 향상이 있습니까? XAML 렌더링 엔진이 방금 분리되었거나 변경 사항이 있습니까? XAML 컨트롤은 주로 컴포지션을 사용하므로 DirectUI와 같은 오프스레드 및 dwm 구동을 사용합니까?

성능은 확실히 우리가 계속 투자하고 싶은 부분이지만 3.0에 대한 개선은 기대하지 않습니다. 초기 3.0 노력은 대부분 Xaml을 분리하여 NuGet 패키지 및 오픈 소싱으로 제공하는 데 중점을 둡니다.

현재 UWP Xaml과 같은 WinUI 3.0은 컴포지션 계층을 기반으로 하며 DWM을 통해 많은 렌더링 및 애니메이션을 스레드에서 실행합니다.

이것은 iOS와 Android가 훨씬 더 잘 작동하는 것이므로 winforms, QT도 마찬가지입니다.
(WPF는 내 생각에 UWP XAML보다 훨씬 나쁩니다).

이러한 시나리오를 고려할 때 종종 성능 대 유연성/풍부함의 절충점이 있습니다. Xaml 기반 플랫폼(UWP 및 WPF 포함)은 모든 컨트롤에 대해 더 크고 풍부한 UI 개체 트리를 갖는 경향이 있습니다. 이는 모든 컨트롤의 스타일과 UX를 변경할 수 있는 많은 유연성을 제공하는 반면 일부 다른 플랫폼은 훨씬 더 평평한 개체 트리를 갖는 경향이 있습니다. 유연하지는 않지만 때로는 더 빨리 로드될 수 있습니다.

그 절충안은 분명히 우리가 생각하고 잠재적인 미래 변화에 대해 염두에 둘 것입니다. 복잡한 Xaml 컨트롤 템플릿의 추가적인 유연성은 많은 시간이 필요하지 않으므로 추가적인 유연성이 필요하지 않은 경우 더 빠르게 로드하도록 컨트롤을 잠재적으로 단순화할 수 있습니다.

Microsoft에서 WinUI 3.0을 기반으로 하는 새로운 comctl32.dll 및 comdlg32.dll을 제공할 수 있기를 바랍니다.

대부분의 Win32 앱에는 최신 UI 환경이 있고 개발자가 최신 UI에 앱을 적용하는 데 도움이 되기 때문입니다.

많은 Win32 개발자는 여러 Windows 버전을 조정해야 합니다. 그래서 그들은 오늘날 WinUI를 직접 사용할 수 없습니다. Microsoft가 앱 UI 현대화 작업 부하를 줄이는 데 도움이 되는 방법을 제공할 수 있다면 정말 좋습니다.

또한 Microsoft에서 WinUI를 사용하는 C++ Win32 앱용 XAML 디자이너를 제공할 수 있기를 바랍니다.

모리 켄지

@MouriNaruto 오늘(Win32부터) FileOpenPicker 를 사용할 수 있습니다.

@MouriNaruto 오늘(Win32부터) FileOpenPicker를 사용할 수 있습니다.

알고 있지만 모든 최신 일반 컨트롤과 대화 상자가 Win32에 제공되기를 바랍니다.

@MouriNaruto

기술적으로 가능합니다. 그러나 Windows 개발자는 COMCTL 및 COMDLG 구현의 정확한 동작뿐만 아니라 코드베이스에 존재하는 알려진 버그와 알려지지 않은 버그를 다시 만들어야 합니다.

호환성은 우리의 친구입니다 !

그렇게 한다 해도 완료할 때쯤이면 해당 라이브러리를 사용하는 모든 소프트웨어는 WinUI로 마이그레이션하기에 충분한 시간을 갖게 될 것입니다! 아이러니!! 🤨🤣

@MarkIngramUK

참고 : FileOpenPicker 는 기본 WinRT 대화 상자/컨트롤이 아닙니다. 본질적으로 DirectUI (ATG 팀에서 개발하고 DirectX ) 및 COM 작성된 ExplorerFrame 의 래퍼입니다!

기술적으로 가능합니다. 그러나 Windows 개발자는 COMCTL 및 COMDLG 구현의 정확한 동작뿐만 아니라 코드베이스에 존재하는 알려진 버그와 알려지지 않은 버그도 다시 만들어야 합니다.
호환성은 우리의 친구입니다!
그렇게 한다 해도 완료할 때쯤이면 해당 라이브러리를 사용하는 모든 소프트웨어는 WinUI로 마이그레이션하기에 충분한 시간을 갖게 될 것입니다! 아이러니!! 🤨🤣

많은 프로젝트가 현실 때문에 그것 없이는 WinUI로 마이그레이션하기가 쉽지 않다고 생각합니다.

당신은 "호환성은 우리의 친구입니다!"라고 말했습니다. 네, 제 제안의 이유 중 하나이기도 합니다. 아이러니!! 🤨🤣

WPF 및 WinForms가 새 버전을 사용하기 위해 옵트인해야 하는 경우에도 XAML WinUI 버전의 일반 대화 상자에 만족할 것입니다.

WinUI 3 대상은 매우 흥미롭게 들리며 기대하고 있습니다. WinUI 3을 사용하는 클래식 Win32 응용 프로그램의 맥락에서 배포/배포에 관한 몇 가지 질문이 있습니다.

1. 모든 앱은 WinUI 라이브러리를 가져와야 합니까, 아니면 Windows 메커니즘을 통해 자동으로 앱 간에 공유가 가능합니까?
2. WinUI를 정적으로 연결할 수 있습니까?
3. 재배포해야 한다고 가정해 보겠습니다. WinUI는 대략 MB 단위로 얼마나 클까요?

모든 앱은 WinUI 라이브러리를 가져와야 합니까, 아니면 Windows 메커니즘을 통해 자동으로 앱 간에 공유가 가능합니까?

우리는 주로 패키지를 자동으로 캐시하고 공유하는 메커니즘이 있는 NuGet을 통해 WinUI 3을 배포할 계획입니다. 여기에 더 많은 정보가 있습니다.

https://docs.microsoft.com/nuget/what-is-nuget#what -else-does-nuget-do

https://docs.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders

WinUI를 정적으로 연결할 수 있습니까?

이것은 우리가 현재 계획한 것이 아닙니다. 이것이 이점이 될 시나리오를 염두에 두고 있습니까?

재배포해야 한다고 가정해 보겠습니다. WinUI는 대략 MB 단위로 얼마나 클까요?

최종 종속성 그래프가 어떻게 보일지 아직 작업 중이지만 UI 부분의 경우 관련 기존 system32 dll 크기(10MB)와 유사할 것입니다.

패키지를 자동으로 캐시하고 공유하는 메커니즘이 있는 NuGet을 통해 주로 WinUI 3을 배포할 계획입니다.

너겟은 개발용이라고 생각했습니까? 아니면 뭔가를 놓치고 있습니까? 내가 아는 한 nuget 기반 패키지는 모든 앱에서 개별적으로 배포해야 하며 공유할 수 없습니다. 이것이 공유 dotnet 코어 런타임을 위한 전용 설치 프로그램이 있는 이유입니다. 그렇지 않으면 dotnet 코어 패키지가 이미 nuget에 있다는 점을 고려할 때 필요하지 않습니다...

UI 프레임워크 패키지를 공유하기 위해 개발 도구나 SDK를 설치할 필요가 없습니다. .NET Core용 WPF 및 WinForms는 동일한 문제가 있었고 공유 번들을 구축하는 데 투자 했기 때문에 사람들 은 최종 사용자 컴퓨터에 SDK를 설치할 필요가 없습니다. WindowsDesktop 번들에 포함됨)

특히 VS에는 프레임워크 종속 배포를 위한 빌드 옵션이 이미 있으며 WinUI는 패키지 공유를 보장하기 위해 이를 활용해야 합니다. 물론 공유 가능한 패키지를 먼저 제공해야 합니다.

Microsoft Store에서 제공하는 앱의 경우 배포 시 릴리스 패키지 콘텐츠도 자동으로 공유되어야 합니다.

다른 수단을 통해 배포된 win32 앱의 경우 언급한 것과 같은 옵션을 조사하기 위해 할 일 목록에 있습니다 😊

WinUI를 정적으로 연결할 수 있습니까?

이것은 우리가 현재 계획한 것이 아닙니다. 이것이 이점이 될 시나리오를 염두에 두고 있습니까?

명확히 해야 할 필요가 있다고 생각합니다. 정적으로 연결된 EXE(VC 런타임을 정적으로 연결하는)에서 WinUI를 사용할 수 있습니까? 나는 그것이 C++/WinRT 때문에 문제가 되지 않아야 한다고 가정하지만 나는 단지 확실히 하고 싶었습니다 ...

재배포해야 한다고 가정해 보겠습니다. WinUI는 대략 MB 단위로 얼마나 클까요?

최종 종속성 그래프가 어떻게 보일지 아직 작업 중이지만 UI 부분의 경우 관련 기존 system32 dll 크기(10MB)와 유사할 것입니다.

정보 주셔서 감사합니다.

그런 거대한 사업에 대한 굉장한 투명성 btw, 나는 그것을 아주 좋아합니다.

명확히 해야 할 필요가 있다고 생각합니다. 정적으로 연결된 EXE(VC 런타임을 정적으로 연결하는)에서 WinUI를 사용할 수 있습니까? 나는 그것이 C++/WinRT 때문에 문제가 되지 않아야 한다고 가정하지만 나는 단지 확실히 하고 싶었습니다.

이것은 (이론적으로) 가능해야 하지만 @jesbis가 말했듯이 패키징되지 않은 앱이 공유 프레임워크에 도달하는 방법에 대한 이야기를 계속 진행 중입니다. .NET Core가 수행하는 방식과 같이 redist 설치 프로그램이 있어야 할 수도 있습니다.

Windows 7에 대한 논의는 상당한 노력(비용은 말할 것도 없고)이 WinUI 3.0에 상당한 지연을 야기할 것이기 때문에 약간 산만합니다. Windows 7은 1월에 단종되며 모든 고객에게 Windows 10으로 업그레이드할 것을 권장합니다. 제 고객은 여기에서 다른 고객과 일치하지 않을 수 있지만 Windows 8.1도 우리에게 관심 있는 플랫폼이 아닙니다.

당신이 맞습니다. 그러나 우리는 내 고객을 제어 할 수 없으며 중국에는 60 % 이상의 시스템이 win7입니다. 그리고 우리는 이 시장을 포기할 수 없으므로 win7을 지원하지 않는 기술은 사용할 수 없습니다.

데이터는 바이두에서 가져온 것입니다. https://tongji.baidu.com/data/os를 참조

그러나 우리는 내 고객을 제어 할 수 없으며 60 % 이상의 시스템이 중국에서 win7입니다.

TBH Win7에서 멈춘 경우 .NET Framework 4.8 + WPF를 사용하겠습니다.

그러나 우리는 내 고객을 제어 할 수 없으며 60 % 이상의 시스템이 중국에서 win7입니다.

TBH Win7에서 멈춘 경우 .NET Framework 4.8 + WPF를 사용하겠습니다.

그러나 Win7 Sp1은 .NET Framework 4.8을 설치할 수 있으며 sp1이 없는 win7은 설치할 수 없습니다.

.NET Framework 시스템 요구 사항 |

SP1이 없는 경우 이미 수명이 다한 지 6년이 된 것입니다.

서비스 팩이 없는 Windows 7 RTM에 대한 지원은 2013년 4월 9일에 종료되었습니다.

https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet

Windows 7 지원을 원하면 이미 Windows 7을 지원하는 기술을 사용해야 하며 Microsoft가 이 문제를 해결해 줄 것이라고 기대해서는 안 됩니다.

@MarkIngramUK Microsoft에서 이 문제를 해결한 것은 아니지만 sp1 없이 win7을 사용하는 고객을 지원할 수 없습니다. 고객이 시스템을 사용하도록 제어할 수는 없지만 sp1 없이 win7을 사용하는 고객은 우리 응용 프로그램을 포기할 것이며 이는 우리가 이 시장을 잃었음을 의미합니다. 하지만 새로운 기술을 사용하지 않는 경쟁자들은 sp1 없이 win7을 지원할 수 있고 나의 경쟁자들은 이 시장에서 승리할 것입니다.

슬프지만 사실, 너무 많은 고객들이 우리가 어떤 기술을 사용하는지 신경 쓰지 않지만 애플리케이션이 모든 장치에서 잘 실행될 수 있다는 점에 관심을 갖습니다.

이것은 내 산업의 현상이며 위의 결론은 다른 산업에 적합하지 않을 수 있습니다.

@linindexi가 말했듯 이 이미 수명이 다한 지 6년이 지난 OS에 새로운 기술이 이식될 것이라고 기대할 수는 없습니다. 오래된 OS를 대상으로 하려면 오래된 기술이 필요합니다.

@linindexi 내 생각에 고객이 지원되는 기술을 사용하기를 원하지 않고 오래된 것을 선호한다면 현대적인 UI를 가질 것이라고 합리적으로 기대할 수 없습니다. 이 두 가지 요구 사항은 순전히 상호 배타적입니다 ...

@MarkIngramUK 슬프다. 오늘날의 신기술을 사용할 수 있게 되면 이 신기술은 오래된 기술이 되었다고 생각합니다.

@linindexi 말 그대로 무슨 일이 일어나고 있는지 반대입니다. 고대 OS로 이식되지 않는다는 이유만으로 신기술을 "구 기술"이라고 부를 수는 없습니다. Win7(SP1 없음) 지원을 원하면 WinForms 또는 MFC 등을 사용하십시오.

@MartinZikmund 맞습니다. 사실, 컴퓨터 기술을 이해하는 사용자는 거의 없으며 win7 및 win10도 알 수 없습니다. 그들은 우리가 어떤 기술을 사용하는지 상관하지 않습니다.

@jesbis C++를 사용하는 새로운 WinUI로 손을 더럽히고 싶습니다. 과거에 UWP 및 C++/Cx를 사용하여 최선을 다했지만 PhotoEditor 앱과 일부 샘플 외에도 항상 머리를 긁적이며 XAML을 Platform::Collections와 바인딩하는 것과 같은 좋은 문서를 찾으려고 했습니다. 저것. 이것이 내가 Windows에서 UWP용 C# 및 C++ 개발용 Qt로 다시 전환한 이유 중 하나입니다. C++에 더 많은 사랑을 주세요.

고객의 경우 Windows 10 Media와 함께 USB 스틱(PenDrive)을 사용하고 Windows 7에서 최신 Windows 10으로 무료로 업그레이드했습니다. 안티바이러스, Windows 업데이트, Edge WebBrowser가 포함된 최신 OS의 이점을 얻었으며 WinForms, WPF와 같은 구형부터 UWP 이상(WinUI)을 포함한 최신 기술에 이르기까지 GUI 기술을 지원합니다. 또한 Shutdown 대신 Windows를 최대 절전 모드로 설정하고 사용자에게 전원 버튼을 눌러 PC 작업을 시작하고 PC 사용이 끝나면 전원 버튼을 누르라고 가르쳤습니다.
또한 시스템을 쉽게 설치/업그레이드하기 위해 네트워크에 ISO를 설정했습니다.

또한 컴퓨터에 Candy Crush가 사전 설치되어 있다는 이점도 있습니다!

의견

WPF의 컨트롤 구현은 이전 버전의 Windows 지원을 위해 WinUI에서 병합될 수 있다고 생각했습니다. (예를 들어, Windows 7.) 그러나 Microsoft가 사무실 정책 때문에 그것을 실현하기는 너무 어렵습니다. lol.

답글

@linindexi
오늘날 중국에는 오래된 Windows 버전 사용자가 많다는 것을 알고 있습니다. 그러나 나는 오늘날 Windows NT 5.x 사용자를 포기할 필요가 있다고 생각하며 그것이 어렵다는 것을 알고 있습니다.

@MartinZikmund

고객이 지원되는 기술을 사용하기를 원하지 않고 오래된 것을 선호한다면 현대적인 UI를 가질 것이라고 합리적으로 기대할 수 없다고 생각합니다. 이 두 가지 요구 사항은 순전히 상호 배타적입니다 ...

당신의 작업이 소수를 위해 제공되는 것을 원하지 않는다면 중국에서 현대적인 UI와 오래된 플랫폼 지원이 모두 필요합니다. 그래서 제 친구인 중국 개발자 중 한 명이 Blink와 V8을 업데이트를 설치하지 않고 Windows XP로 이식했는데 많은 개발자들이 최신 앱 경험을 구현하기 위해 Blink를 사용합니다. 중국에서 최소 운영 체제 버전 요구 사항은 업데이트가 설치되지 않은 버전과 같습니다. 예를 들어 중국 앱의 운영 체제 버전 요구 사항이 Windows 7인 경우 "Windows 7 RTM" 또는 "6.1.7600.16385(win7_rtm.090713-1255)"에서 앱을 사용할 수 있다고 알려줍니다. Android 세계에서도 많은 앱이 오늘날에도 여전히 Android 4.4를 지원합니다.

이것이 중국이 아닌 개발자가 만든 대부분의 앱이 중국에서 다수의 선택이 될 수 없는 이유입니다.

추신 최신 Visual Studio 2019를 사용 업데이트를 설치하지 않고도 최신 Windows 10 SDK 및 최신 C++17 표준을 사용하거나 지금 C++20을 사용해 볼 수 있는 Windows XP RTM용 앱을 빌드할 수 있습니다. VC-LTL(https://github.com/Chuyu-Team/VC-LTL) 및 YY-Thunks(https://github.com/Chuyu-Team/YY-Thunks) 때문입니다.

나 자신에 대한 메모

대부분의 시간에 안정적인 최신 Windows 빌드를 사용합니다. (나는. 나는 19H1 및 19H2을 사용하고 있습니다. 10.0.18362 오늘 사용)하지만 업데이트하지 않고 Windows 10, 버전 1703 용으로 설계된 설치 업데이트하지 않고 윈도우 비스타 RTM을 위해 설계 내에서 Win32 프로젝트, 내 UWP 프로젝트 설치하거나 나중에 조건 때문에 XAML 지원은 RS2에 도입되었습니다. (저는 조건부 XAML을 좋아합니다. Windows 10 Build 14393에는 왜 존재하지 않습니까?)

모리 켄지

제발, 모든 WinUI 3.0 컨트롤 클래스의 봉인을 해제하는 것을 고려하십시오!

내 이해에 따라 Microsoft는 모든 UWP 제어 클래스를 봉인하기로 결정했습니다. 왜냐하면 JavaScript(상속을 알지 못함)가 상속된 클래스와 함께 사용될 때 문제가 발생했기 때문입니다. 이제 JS/HTML이 더 이상 사용되지 않으므로 새 UI 프레임워크가 여전히 모든 클래스를 봉인할 필요가 더 이상 없습니다. 잠금 해제를 사용하면 WPF에서 항상 가능했던 것처럼 UWP 컨트롤을 훨씬 쉽게 사용자 지정할 수 있습니다. 또한 사용자 정의 가상화 목록 컨트롤 또는 패널을 작성할 때 상속할 봉인되지 않은 가상화 기본 클래스를 갖는 것이 많은 도움이 될 것입니다. C#, C++/CX 또는 C++/WinRT 모두 상속 문제가 없습니다. 우리에게 이것을 강요한 것은 JS/HTML이라는 실패뿐이었습니다.

따라서 WinUI 3.0을 생성할 때 이 불필요한 제한을 제거하십시오.

@gisfromscratch 피드백 주셔서 감사합니다! 우리는 확실히 C++ 개발(특히 C++/WinRT 사용)을 지원하고 싶습니다.

C++를 더 쉽게 사용할 수 있는 방법은 무엇입니까? CX 대신 C++/WinRT를 사용해 보셨습니까?

더 많은 샘플 앱이 도움이 될까요?

바인딩에 대한 문서를 찾기가 어렵다고 말씀하셨습니다. 더 나은 문서가 필요한 다른 특정 기능이 있습니까?

제발, 모든 WinUI 3.0 컨트롤 클래스의 봉인을 해제하는 것을 고려하십시오!

@lukasf 이것은 우리가 할 것 같은 일입니다 🙂 #780에서 관련 토론이 진행 중입니다.

@jesbis C++/WinRT를 사용하여 훨씬 더 손을 더럽혀야 합니다. 방금 Photo Editor C++/WinRT 샘플 응용 프로그램을 따랐습니다. 그러나 심층 데이터 바인딩 과 같은 제공된 링크를 읽으면 많은 C# 스니펫과 "C++/WinRT의 경우 기본 클래스에서 파생된 애플리케이션에서 선언하는 모든 런타임 클래스는 구성 가능한 클래스로 알려져 있습니다. 그리고 구성 가능한 클래스 주변에는 제약 조건이 있습니다...". 이 페이지는 95% C#과 5% C++만을 대상으로 합니다.

@gisfromscratch 감사합니다! WinUI 3용 문서를 업데이트할 때 이를 염두에 두겠습니다.

도움이 된다면 언급한 데이터 바인딩 페이지는 특히 C++/WinRT를 사용한 데이터 바인딩에 대한 별도의 페이지로 연결됩니다. 예:

XAML 컨트롤;

XAML 항목 컨트롤;

해당 섹션에는 기타 여러 C++/WinRT 관련 항목도 있습니다.

당신의 훌륭한 작업에 감사드립니다! Xaml Island 가 WinUi 3.0에서 제거된 것을 보니 매우 기쁩니다.
Btw: WinUi 3.0에서 언어 프로젝션 의 저수준 구현이 WinRT 구성 요소와 다른지 궁금합니다. WinRT 구성 요소 의 언어 프로젝션 구현은 컴파일 시간과 런타임 모두에서 .NET UWP 프로젝트의 성능에 큰 영향을

@zenjia XAML 아일랜드는 WinUI 3에서 제거되지 않았습니다. WinUI 3에는 WPF/WinForms/MFC 앱이 WinUI 3 컨트롤을 호스트하도록 허용하는 API가 포함됩니다.

나는 WinUI의 진행 상황을 따라가려고 노력했습니다. 과거에 C#으로 UWP 앱을 작성하려고 시도했지만 힘든 싸움이라는 것을 알았습니다. 하지만 winui 3.0 이후에 다시 시도하고 싶습니다.

winui 로드맵에 대해 질문이 있습니다. 여기 4가지가 있습니다. 다른 곳에서 다루었다면 죄송합니다. 나는 많은 검색에도 불구하고 답을 찾지 못했습니다 ... 이러한 유형의 질문을 할 수있는 더 나은 포럼이 있으면 알려주십시오.

• 네이티브 컨트롤의 .net 래퍼도 오픈 소스로 제공됩니까? 내가 찾은 유일한 C# 코드가 자동화된 테스트를 위한 것임을 고려할 때 이것이 winui의 .Net 측을 담당하는 github 재현인지는 분명하지 않습니다. Microsoft.UI.Xaml.UIElement와 같은 것을 찾고 있지만 어디에서나 해당 코드를 찾을 수 없습니다.

• winui 3.0이 출시되면 UWP appmodel과 win32 appmodel이 동일한 .Net Core 런타임을 실행합니까? UWP 응용 프로그램에서 어떤 버전의 .Net 코어를 사용하는지 전혀 알지 못했습니다. Windows 자체에 내장되어 있고 Windows 10 SDK를 통해 VS 2019가 UWP에서 사용할 수 있는 .Net 코어의 올바른 버전을 대상으로 지정할 수 있다고 생각합니다.

• Xaml 섬에 대한 질문입니다. WPF와 UWP가 동일한 영공을 공유할 가능성이 있습니까? 나는 winforms와 WPF 사이에서 했던 것처럼 영공 문제를 처리해야 하는 것을 기대하지 않습니다. WPF와 UWP가 모두 direct-X를 기반으로 한다는 점을 감안할 때 서로 픽셀을 공유할 수 있다면 정말 좋을 것입니다. 예를 들어 리본(WPF)에 UWP xaml 섬을 오버레이해야 하는 백스테이지 메뉴가 있는 경우 원활하게 수행될 수 있다면 정말 좋을 것입니다. 내가 그런 것을 위해 수많은 골대를 뛰어 넘어야 할 필요는 없을 것 같습니다. ... WPF 초기에 "WebBrowser" winforms 컨트롤을 사용하려는 클라이언트 응용 프로그램의 영공 문제를 해결하려고 했던 것을 기억합니다. 그들은 "WebBrowser.CompositionMode"라는 웹 브라우저의 기능을 시험적으로 수행했으며 WebBrowser가 WPF와 잘 작동하도록 허용해야 했습니다. ... 하지만 그 전략은 결국 포기한 것 같아요. 아마도 UWP와 WPF 간의 상호 운용성은 매우 원활하여 서로 픽셀을 공유할 수도 있습니다(winform 및 WPF와 달리). 이것의 잠재적인 이점 중 하나는 WPF에서 UWP 컨트롤의 기능을 향상시킬 수 있다는 것입니다. 예를 들어 WPF는 표시기 레이어와 유사한 방식으로 xaml 섬에 추가 시각적 개체를 오버레이할 수 있습니다. 이것은 약간의 도움이 될 수 있습니다.

• xaml 아일랜드(예: 50% WPF 및 50% WINUI)가 있는 WPF 앱이 언젠가 기본적으로 ARM64로 컴파일될 가능성이 있습니까? ARM을 대상으로 하는 것은 100% UWP인 응용 프로그램에서 가능하며 WPF 종속성이 기본 ARM64 대상 지정을 포기하도록 강요하지 않는다면 좋을 것입니다. (대안은 x86 에뮬레이션에서 앱을 실행하는 것입니다. 그러나 이는 더 느리고 사용할 수 있는 메모리를 제한합니다.)

이 질문들이 모두 winui의 로드맵과 관련이 있기를 바랍니다. 모든 조언을 주시면 감사하겠습니다.

네이티브 컨트롤의 .net 래퍼도 오픈 소스로 제공됩니까? 내가 찾은 유일한 C# 코드가 자동화된 테스트를 위한 것임을 고려할 때 이것이 winui의 .Net 측을 담당하는 github 재현인지는 분명하지 않습니다. Microsoft.UI.Xaml.UIElement와 같은 것을 찾고 있지만 어디에서나 해당 코드를 찾을 수 없습니다.

UIElement는 WinUI 2에 없으므로 현재 저장소에 없습니다. 아직 출시되지 않았거나 오픈 소스로 제공되지 않은 WinUI 3에 있을 것입니다. 하지만 우리는 작업 중입니다!

WinRT 프로젝션을 통해 .NET에 노출된 다른 기본 컨트롤의 리포지토리에서 예제를 볼 수 있습니다(예: 여기에 문서화된 WinUI 2.2 컨트롤). 그들은 대부분 이미 존재하는 언어별 래퍼 파일을 필요로 하지 않기 때문에 리포지토리에서 .cs 파일을 찾을 수 없습니다.

@marb2000 은 섬/데스크톱 질문에 대해 가장 잘 설명할 수 있습니다.

Q: _WinUI 3 UWP와 데스크톱은 동일한 .NET 런타임을 사용합니까?_
A: 네, 이것이 계획입니다. UWP 및 데스크톱은 .NET Core 3을 사용합니다. 관리되는 WinRT 라이브러리는 .NET 네이티브 대신 .NET Core 3을 사용합니다.

Q: _WPF와 UWP는 동일한 영공을 공유합니까?_
A: WPF와 WinUI(및 XAML UWP)는 비슷해 보이지만 그렇지 않습니다. WPF는 DirectX9를 사용하고 WinUI/XAML UWP는 XAML의 구성, 렌더링 및 애니메이션 요구 사항에 대해 Windows.UI.Composition을 사용합니다(DirectX11의 최신 버전 제외). 슬프게도 이로 인해 interop이 매우 복잡해집니다. WPF 표시기에 대한 귀하의 제안은 흥미롭습니다. 이론적으로 채택자는 WPF 콘텐츠 위에 WinUI/XAML 콘텐츠를 배치하는 팝업을 만들 수 있습니다. 또는 재레이아웃이 필요하지만 모든 것이 HWnd를 기반으로 한다는 것을 WPF 시각적 트리에 알릴 수 있습니다.
@dbeavon 이것은 좋은 제안입니다. 이에 대한 기능 요청을 생성할 수 있습니까?

Q: _Xaml Islands가 포함된 WPF 앱이 ARM64로 컴파일되나요?_
A: Windows용 .NET Core 3이 ARM64를 확실히 지원한다면. 현재 Windows에서 ARM32를 지원합니다. 그러나 Linux에서는 ARM64를 지원합니다. Windows에서도 ARM64를 지원하기 위한 .NET Core 로드맵에 있다고 생각합니다. AFAIN이지만 아직 날짜가 없습니다. @richlander , 소식이 있습니까?

@marb2000

Q: WPF와 UWP는 동일한 영공을 공유합니까?

UWP에서 Windows.UI.Composition을 사용하여 DirectX 비트맵에서 렌더링을 가져올 수 있는 계층을 만들 수 있나요? 그런 다음 WPF는 win2d와 같이 이 레이어에 창을 렌더링합니다. 같은 영공을 공유할 수도 있습니다. 그러나 WPF가 레이어에 렌더링되도록 하는 것은 어렵습니다.

@linindexi 천국이

UWP에서 Windows.UI.Composition을 사용하여 DirectX 비트맵에서 렌더링을 가져올 수 있는 계층을 만들 수 있나요?

UWP Xaml에는 SurfaceImageSource , VirtualSurfaceImageSource 및 SwapChainPanel 포함하여 동일한 영공을 공유하도록 Xaml에서 DirectX 비트맵을 렌더링하거나 체인을 교환하고 이를 Windows.UI.Composition으로 합성하는 여러 가지 방법이 있습니다.

https://docs.microsoft.com/windows/uwp/gaming/directx-and-xaml-interop

Windows.UI.Composition 시각적 개체를 UWP Xaml UI 트리에 삽입하고 여기에 DirectX 콘텐츠를 그릴 수도 있습니다(예: ICompositorInterop , ICompositionDrawingSurfaceInterop 및 ICompositionGraphicsDeviceInterop 사용).

https://docs.microsoft.com/windows/uwp/composition/composition-native-interop

이러한 접근 방식은 WinUI와 유사하게 작동해야 합니다.

UWP 데스크톱 앱은 WPF/WinForm DLL을 참조하고 WPF/WinFrom 창을 열 수 있습니까? 이렇게 하면 점진적으로 마이그레이션할 수 있습니다.

@marb2000 -- Windows ARM64용 .NET Core가 로드맵에 있습니다. 나는 지금 그것에 대한 계획을 세우고 있다.

WinUI 3.0을 사용하면 그 위에 win2d를 컴파일할 수 있습니까?
(따라서 UWP에서 분리)
그렇다면 그것은 미친 듯이 굉장할 것입니다!

우리는 여전히 DirectX 통합에 대한 세부 사항을 연구하고 있지만 UWP Xaml 기본 클래스 대신 WinUI 기본 클래스를 사용하도록 Win2D를 업데이트할 수 있기를 바랍니다.

손가락이 교차되었습니다 :D

주제가 아닌 경우 죄송합니다. UWP에 대한 버그 보고서 - https://github.com/microsoft/microsoft-ui-xaml/ 또는 다른 곳에서 문제를 추가합니까?

주제가 아닌 경우 죄송합니다. UWP에 대한 버그 보고서 - https://github.com/microsoft/microsoft-ui-xaml/ 또는 다른 곳에서 문제를 추가합니까?

@jtorjo 좋은 질문입니다! 이 리포지토리는 다음과 관련된 문제를 제출하기에 가장 좋은 곳입니다.

• UWP UI 프레임워크 API(예: Windows.UI.Xaml)
• 유창한 디자인
• WinUI

일반적으로 docs.microsoft.com 의 대부분의 문서 페이지 하단에 "이 제품에 대한 피드백 보내기" 링크가 있어야 특정 기능이나 API에 대한 피드백을 제공하는 가장 좋은 방법을 알려줍니다.

위의 항목을 제외하고 UWP의 대부분의 측면에서 이는 여러 관련 하위 범주가 있는 피드백 허브 의 개발자 플랫폼 범주에 버그를 신고하는 것입니다.

WinUI 3에 UWP SemanticZoom 컨트롤이 포함됩니까? 나는 그것이 그들 모두의 가장 멋진 컨트롤이라고 생각합니다.

@jebis 감사합니다! 방금 System.IO에 대한 토론을 게시했습니다.

Microsoft도 Office에 대한 Windows 7 지원을 중단하지 않는데 WinUI 3가 지원하는 이유는 무엇입니까? 내 말은, 거의 모든 심각한 소프트웨어는 Windows 7을 지원합니다(Photoshop, Office, Visual Studio 2019, VSCode 등). WinUI가 Windows 7을 지원하지 않는다면...

Microsoft도 Office에 대한 Windows 7 지원을 중단하지 않는데 WinUI 3가 지원하는 이유는 무엇입니까? 내 말은, 거의 모든 심각한 소프트웨어는 Windows 7을 지원합니다(Photoshop, Office, Visual Studio 2019, VSCode 등). WinUI가 Windows 7을 지원하지 않는다면...

Microsoft의 Windows 7 지원이 곧 종료되므로 Office는 곧 지원을 중단할 것입니다. 그러나 이미 Windows 7을 지원하는 코드 기반을 기반으로 합니다.

WinUI는 Windows 10을 기반으로 구축되었으므로 Windows 7로 다시 이식해야 합니다. OS가 수명 종료에 접어들면서 그렇게 하려는 노력은 의미가 없으므로 사람들은 Windows 10으로 업그레이드해야 합니다.

Q: WinUI 3 UWP와 데스크톱은 동일한 .NET 런타임을 사용합니까?
A: 네, 이것이 계획입니다. UWP 및 데스크톱은 .NET Core 3을 사용합니다. 관리되는 WinRT 라이브러리는 .NET 네이티브 대신 .NET Core 3을 사용합니다.
Q: WPF와 UWP는 동일한 영공을 공유합니까?
A: WPF와 WinUI(및 XAML UWP)는 비슷해 보이지만 그렇지 않습니다. WPF는 DirectX9를 사용하고 WinUI/XAML UWP는 XAML의 구성, 렌더링 및 애니메이션 요구 사항에 대해 Windows.UI.Composition을 사용합니다(DirectX11의 최신 버전 제외). 슬프게도 이로 인해 interop이 매우 복잡해집니다. WPF 표시기에 대한 귀하의 제안은 흥미롭습니다. 이론적으로 채택자는 WPF 콘텐츠 위에 WinUI/XAML 콘텐츠를 배치하는 팝업을 만들 수 있습니다. 또는 재레이아웃이 필요하지만 모든 것이 HWnd를 기반으로 한다는 것을 WPF 시각적 트리에 알릴 수 있습니다.
@dbeavon 이것은 좋은 제안입니다. 이에 대한 기능 요청을 생성할 수 있습니까?
Q: Xaml Islands가 포함된 WPF 앱은 ARM64로 컴파일됩니까?
A: Windows용 .NET Core 3이 ARM64를 확실히 지원한다면. 현재 Windows에서 ARM32를 지원합니다. 그러나 Linux에서는 ARM64를 지원합니다. Windows에서도 ARM64를 지원하기 위한 .NET Core 로드맵에 있다고 생각합니다. AFAIN이지만 아직 날짜가 없습니다. @richlander , 소식이 있습니까?

그럼 UWP 샌드박스를 제거할까요? 현재 형태의 UWP도 사라지고 우리가 알고 있는 App Store의 보호된 샌드박스와 함께 다음 중 무엇을 의미합니까?

그럼 UWP 샌드박스를 제거할까요? 현재 형태의 UWP도 사라지고 우리가 알고 있는 App Store의 보호된 샌드박스와 함께 다음 중 무엇을 의미합니까?

UWP 샌드박스를 제거하는 것은 정말 대단할 것입니다!

그렇다고 해서 UWP가 사라지는 것은 아닙니다. 유니버설 Windows 플랫폼은 Windows 장치(PC, Xbox, HoloLens 등)의 전체 스펙트럼을 기본적으로 구축할 수 있는 유일한 방법이며 Windows가 기본 플랫폼 투자에 집중하고 있는 곳입니다. RE: 특히 샌드박싱: 앱 컨테이너 격리는 앱과 UWP 및 데스크톱 앱 사용자 모두에게 계속해서 많은 중요한 이점을 제공합니다.

주요 변경 사항은 다음과 같습니다.

• 데스크톱(win32) 앱 모델에서도 사용할 수 있도록 UX 플랫폼(예: WinUI)의 범위를 확대하고 있습니다.
• 우리는 WinUI를 Windows에서 분리하여 더 자주 업데이트하고, 새로운 기능을 이전 버전과 호환 가능하게 만들고, 더 쉽게 소스를 공개할 수 있습니다.

즉, 새 앱의 경우 앱에 적합한 항목에 따라 UWP와 데스크톱 앱 모델 중에서 선택할 수 있으며 기존 데스크톱 앱(예: WPF, WinForms, MFC)이 있는 경우 최신 앱으로 점진적으로 업데이트할 수 있습니다. Xaml Islands를 사용하는 WinUI 기능.

그럼 UWP 샌드박스를 제거할까요? 현재 형태의 UWP도 사라지고 우리가 알고 있는 App Store의 보호된 샌드박스와 함께 다음 중 무엇을 의미합니까?

UWP는 WinUI 3.0 앱을 빌드하기 위한 옵션 중 하나입니다. UWP를 사용하면 Xbox, Hololens 등에서 앱을 실행할 수 있습니다.

그러나 WinUI 3.0을 사용하여 Win32 앱을 빌드하고 UWP API에 액세스할 수도 있지만 앱을 실행할 수 있는 위치는 더 제한적입니다.

@mdtauk @jesbis 저는 전적으로 UWP를 지지하지만 현재로서는:

1. 컴파일 시간이 엄청나게 느립니다! (WPF보다 6배 느림 - 타겟 버전 빌드 1809 - 빌드 17783을 사용하고 있습니다.)
2. StorageFolder 파일 열거 API가 UWP의 일부가 아니라는 것을 알고 있지만 엄청나게 느립니다. UWP 샌드박스(적어도 Windows 데스크톱에서는)는 도움이 되는 것보다 더 큰 문제입니다.
3. 물론 비동기 프로그래밍은 재미있지만 UWP에서는 예외가 발생하면 어떻게든 UWP 코드에 먹혀들고 나중에 디버거에서 중단되고 모든 스택 컨텍스트가 손실됩니다. 가끔은 예외가 발생한 자체 내부에 스택 컨텍스트가 있지만 항상 그런 것은 아닙니다.
4. UWP 코드를 프로파일링하는 것은 불가능에 가깝습니다. 이벤트 dotTrace는 시도할 때 즉시 중단됩니다.

(WPF에서 UWP로 코드를 이식하는 데 한 달 이상이 걸렸습니다. win2d가 엄청나게 필요하기 때문에 UWP를 피할 방법이 없기 때문입니다.)

@mdtauk @jesbis 저는 전적으로 UWP를 지지하지만 현재로서는:

1. 컴파일 시간이 엄청나게 느립니다! (WPF보다 6배 느림 - 타겟 버전 빌드 1809 - 빌드 17783을 사용하고 있습니다.)
2. StorageFolder 파일 열거 API가 UWP의 일부가 아니라는 것을 알고 있지만 엄청나게 느립니다. UWP 샌드박스(적어도 Windows 데스크톱에서는)는 도움이 되는 것보다 더 큰 문제입니다.
3. 물론 비동기 프로그래밍은 재미있지만 UWP에서는 예외가 발생하면 어떻게든 UWP 코드에 먹혀들고 나중에 디버거에서 중단되고 모든 스택 컨텍스트가 손실됩니다. 가끔은 예외가 발생한 자체 내부에 스택 컨텍스트가 있지만 항상 그런 것은 아닙니다.
4. UWP 코드를 프로파일링하는 것은 불가능에 가깝습니다. 이벤트 dotTrace는 시도할 때 즉시 중단됩니다.

(WPF에서 UWP로 코드를 이식하는 데 한 달 이상이 걸렸습니다. win2d가 엄청나게 필요하기 때문에 UWP를 피할 방법이 없기 때문입니다.)

이 스레드 #1517에 게시하는 것이 유용할 것이며 SDK 팀의 누군가의 이름을 포함할 수 있기를 바랍니다.

@jtorjo

컴파일 시간이 엄청나게 느립니다! (WPF보다 6배 더 느림

C++/WinRT를 사용하고 있습니까? 그렇다면 미리 컴파일된 헤더를 사용하고 있습니까?

@mdtauk 방금 거기에 게시했습니다

@MarkIngramUK C# 코드입니다.

마무리 - 로드맵 및 알파 피드백을 #1531로 보내주십시오.

현재로서는 이것이 가능한지 알 수 없습니다. WinUI 비트가 OS에서 제거되면 다른 플랫폼에서 일종의 호환성 구성 요소를 제공할 수 있는 방식으로 오픈 소스 프로젝트에 삽입되기를 바랍니다. 사용자 지정 렌더러가 있는 Xamarin, Uno 또는 .Net Core를 생각해 보세요.

이것은 실제로 로드맵에 있는 것입니까 아니면 가정에 불과한 것입니까?

@mdtauk , @zezba9000 그것은 모두 이론적으로 가능하며 팀에 많은 플랫폼 추상화 전문 지식이 있습니다. 모든 것이 그렇듯이 비용, 일정 및 예상되는 이점으로 귀결됩니다 😊

제3자가 Android 또는 iOS에서 작동하도록 하는 방식으로 추상화하는 것은 엄청난 일일 것입니다. 나는 커뮤니티가 이것을 할 수 있다고 확신합니다. 나는 확실히 그것에 기여할 것입니다.

@andreinitescu 호언장담과 불만에 대해 유감이지만 내가 이해한 바에 따르면 WinUI 3을 사용하여 Windows/Win32 전용 WPF를 대체하는 동안... Windows의 WinUI는 Windows 전용 렌더링 API를 사용하고 불가지론자가 아닌 하나, WinUI는 타사에 의존하여 다른 플랫폼에서 WinUI를 재구현/조각화(ugg)하는 것 같습니다(UNO proj와 같이 멋지지만 .NET에 대한 Mono와 같은 것은 불필요하고 단편화에 시간을 낭비하는 것뿐입니다. 시작하기에 적합하도록 설계됨). Skia와 같은 휴대용 제품을 사용하거나 MS 제품을 만드는 대신. 또한 C#을 WinUI와 함께 사용하지 않을 1%의 사람들을 지원해야 하는 필요성을 이해하지 못합니다. C#을 어떤 의미에서는 두 번째 클래스 대상으로 만들고 더 중요하게는 개발 시간을 훨씬 더 오래 걸리게 만드는 것입니다. Android가 많은 핵심 앱에 대해 Java + post-AOT를 사용하는 것처럼 Windows는 C# + pre-AOT를 사용해야 합니다. 시간이 절약되기 때문입니다. C++를 사용하는 버그의 70%는 결국 할당 해제된 ptr을 사용하고 있습니다.

회사 내 그룹 간의 의사 소통 부족으로 인해 모바일 플랫폼(사용할 예정)용 Android OS 버전을 출시하고 더 많은 사람들이 이를 대상으로 하려는 경우 문제가 점점 더 커지는 장기적인 사용 사례 MS 도구로 ... 어떻게 보면 상황과 같은 또 다른 WinPhone7이 될 것입니다. 용어로서의 Windows는 더 이상 WinNT 커널에 얽매여서는 안 됩니다. 에코 시스템은 단일 플랫폼 또는 하나의 회사가 기반으로 하는 프레임워크 이상입니다.

MS는 거의 20년 전 OS9에서 OSX로 이동하면서 Apple이 한 일을 할 수 없습니다. UNIX/LINUX 커널로 이동하여 반창고를 없앤다는 점에서 향후 5-10년 동안 레거시 소프트웨어용 OS에 에뮬레이터/시뮬레이터가 내장되어 있는 반면 사람들은 기본적으로 실행하기 위해 소프트웨어와 개발 도구를 마이그레이션합니다. (당신이 이것에 대해 무엇을 원할지 생각하지만 나는 꿈을 꿀 수 있습니다)