microsoft-ui-xaml 🚀 - WinUI 3.0 개발자 경험 및 도구 - 입력 필요

아마도 먼 이야기일 수 있지만 Blend는 정밀 검사가 필요하고 디자인 중심의 워크플로가 필요합니다.

XAML 디자이너는 강력하고 강력해야 합니다.

페이지/창의 계층 구조를 시각화하는 몇 가지 방법, 특히 상승된 컨트롤에서 중요합니다.

개별 컨트롤/템플릿과 같은 페이지 외부의 UI 요소를 시각화하는 방법입니다.

CoreOS, "Surface Phone", Surface Hub, Xbox, HoloLens용으로 만들어진 디스플레이 컨트롤 사용자 지정은 모두 디자이너 내에서 이루어집니다.

WinForms, WPF, MFC 및 WinUI Desktop이 작동할 기타 모든 프레임워크와 혼합된 XAML용 결합 디자이너.

XAML을 가져오고 내보내는 좋은 방법을 통해 디자이너는 기본 앱과 격리된 Blend에서 작업한 다음 이를 개발 팀에 전달하여 앱으로 가져올 수 있습니다.

시스템 리소스의 더 나은 시각화 및 목록은 물론 기본값을 재정의하기 위해 가벼운 스타일로 지정할 수 있는 전역 리소스를 끌어내는 훌륭한 방법과 디자인 화면은 이러한 변경 사항을 실시간으로 반영합니다.

WinForms, MFC 등과 관련된 앱으로 다양한 DPI 확장을 테스트하는 더 나은 방법

새로운 컨트롤용 템플릿, 맞춤형 테마 리소스 사전, Fluent 테마 편집기 통합, 지원되는 앱 조합용 템플릿(Xaml UI가 있는 Win32 MFC 등) .

파일 선택기, 작업 트레이 플라이아웃과 같은 셸 통합 지점용 템플릿.

몇 가지 생각일 뿐입니다...

mdtauk 에 2019년 07월 12일

👍16

제 생각은 다음과 같습니다.

MSIX는 모두 훌륭하지만 MSIX가 지원하지 않는 기능을 필요로 하는 더 복잡한 응용 프로그램을 설치하는 데 여전히 좋은 MSI를 사용합니다. 또한 필요한 Authenticode 인증서가 얼마나 비싸기 때문에 MSIX를 사용하기가 꺼려집니다. (나는 회사에서 구입한 인증서만큼 안전하다고 생각하는 자체 서명된 인증서로 내 코드에 쉽게 서명할 수 있지만 Windows는 이를 로드하지 않습니다. 그러나 Windows는 자체 서명된 MSI 파일을 기꺼이 수락합니다. .) MSI 기반 응용 프로그램에서 WinUI 3을 사용할 수 있는 한 만족합니다.
더 나은 XAML 디자이너가 있으면 대단히 감사하겠습니다. 하지만 WinUI XAML과 WinForms/WPF 디자이너를 하나로 통합하는 복잡성이 추가로 필요하지는 않습니다. 나는 VS의 다른 탭 사이에서 플립 플롭으로 완벽하게 괜찮습니다.
앞서 언급했듯이 C# 및 Visual Basic 프로젝트 시스템에서 XBF 컴파일러를 분리하는 것은 매우 유용할 것입니다. (XBF 컴파일러 소스나 그것을 재현하기에 충분한 문서가 공개된다면 더욱 좋겠지만, 그렇게 될 가능성이 얼마나 될지는 모르겠습니다.)
C++ 프로젝트 시스템에서 C++/WinRT 및 MIDL 3에 대한 지원이 향상되었습니다. 현재 C++/WinRT 사용에 대한 프로젝트 지원은 불안정하고 투박합니다. (예를 들어, 템플릿이 자동으로 밑줄로 변환할 때 네임스페이스에서 사용하려는 프로젝트 이름에 점이 있는 경우에 필요한 IDL 파일의 네임스페이스를 변경하면 프로젝트가 컴파일되지 않습니다. , 내 경험상 문제를 수정하려면 *.h 및 *.cpp 파일을 따로 이동하고 처음부터 다시 생성하고 코드를 복사한 다음 vcxproj 파일을 언로드 및 편집하여 중첩을 수정해야 합니다.) vcxproj보다 더 현대적이고 유연한 것을 사용하고 싶지만 XBF 컴파일러가 가지고 있는 강한 의존성 때문에 그렇게 할 수 없습니다.

또 다른 일이 생기면 이곳에 글을 올리도록 하겠습니다. 감사 해요!

wjk 에 2019년 07월 13일

👍15

여기서 궁금한 것은... 글쎄, < winui:Listview 또는 < controls:listview 또는 개발자가 결정한 것과 같은 네임스페이스 접두사를 사용해야 합니까? 가능하면 지금과 같은 경험을 하는 것이 훨씬 더 좋을 것 같습니다. 접두사는 몇 가지 컨트롤에 대해 괜찮고 훌륭합니다. 그러나 모든 곳에서 사용하기 시작하면 XAML이 악몽을 읽고 매우 어려워집니다.
Windows.UI.Xaml.Controls를 사용할 수 없고 WinUI가 기본 선택이므로 네임스페이스 접두사를 사용하는 것은 의미가 없습니다.
지금은 XAML 디자이너도 사용하지 않습니다. 나는 말 그대로 설정에서 비활성화합니다. XAML Designer는 느리고 더 나은 지원이 필요합니다. WPF에는 좋았지만 UWP에는 좋지 않았습니다. 특히 반응형 디자인, 페이지 처리, 데이터 표시 등을 하려는 경우에 그렇습니다.
이것은 아마도 먼 미래에 대한 피드백일 수 있지만, 살펴보기에 좋은 피드백이라고 생각합니다. WPF 디자이너가 훨씬 빠릅니다.
이것은 샌드박스 때문입니까 아니면 무엇 때문입니까?
마이그레이션을 수행하는 데 흥미로운 도구가 될 것입니다. 특히 ScrollViewer와 같은 업데이트된 WinUI 3.0 컨트롤과 관련된 몇 가지 호환성 문제가 있을 수 있습니다. 따라서 도구가 있는 경우 이러한 업데이트/재작성된 컨트롤에 대해 최소한 가능한 경고를 표시해야 합니다.

vitorgrs 에 2019년 07월 13일

👍10

디자이너와 분리된 IntelliSense가 포함된 강력한 xaml 코드 편집기가 필요합니다.
대부분의 경우 C#과 같은 xaml 코드를 작성하고 있습니다. 현재 코드 편집기는 느리고 취약합니다. 이전 의견 에서 설명했습니다. IntelliSense 경험도 매우 간단합니다. 빠른 문서 정보가 없고 멤버 이름이 바뀌지 않습니다.
x:Bind 대한 디자인 데이터 지원은 함수 바인딩에서 복잡한 도우미를 작성 중이므로 상당히 어려울 수 있습니다. 그러나 xaml 내장 함수가 일부 도우미를 대체할 수 있다면 상황이 더 나아질 수 있습니다.
내 애플리케이션에 대한 패키징 모델의 훨씬 더 많은 무료 조합을 원합니다. 주제에서 벗어날 수 있지만 앱 모델 팀에 피드백을 줄 곳을 찾을 수 없습니다.

TL;DR 앱 모델 지원 임의 인스턴스 공존을 원합니다. 동일한 버전이라도 Visual Studio 하이브와 같은 다른 데이터/옵션 세트로 실행할 수 있습니다. 현재 유일한 솔루션은 xcopy인 것 같습니다.

아무도 이것을 접는 방법을 말해 줄 수 있습니까?

첫째, 매일 개발하는 앱도 사용하고 있습니다(대부분의 경우 >>debug 사용). 그래서 안정적인 빌드와 공존하는 개발 빌드가 많은 도움이 될 것입니다. 현재 버전 번호를 늘리고, 디버그 msix를 패키지하고, 설치된 패키지 버전을 디버그하도록 업데이트해야 합니다.
다른 디버그 단계에서 다른 기능을 원할 것입니다. 복잡한 실제 데이터의 경우 디버그 인스턴스가 안정적인 데이터와 데이터를 공유하기를 원합니다. 임의의 가짜 데이터의 경우 격리를 원합니다. 이것은 이론적으로 폴더 선택기를 사용하여 데이터에 액세스하여 해결되지만 UWP의 SQLite가 이를 지원하지 않고 내가 아는 다른 임베디드 ACID 엔진이 없는 것이 너무 유감입니다.

huoyaoyuan 에 2019년 07월 13일

👍4

아, 그리고 또 한 가지. vcxproj가 NuGet 패키지 참조에 packages.config를 사용하도록 요구하는 방법에 대해 조치를 취할 수 있다면 정말 _정말_ 감사합니다. WinUI는 C++/WinRT 및 기타 주요 구성 요소와 마찬가지로 NuGet 패키지로 배포됩니다. 나는 packages.config를 사용하는 것을 정말로 좋아하지 않습니다. PackageReference가 훨씬 더 효율적입니다(vcxproj를 다른 디렉터리로 이동해도 빌드가 손상되지 않음). 복원 대상이 적절한 시간에 실행되는 한 vcxproj에서 사용할 때 실제로 작동합니다. (vcxproj 대상이 비 SDK C# 프로젝트에 대한 PackageReference 복원 기계를 간접적으로 가져오기 때문입니다.) 저는 PackageReference 항목 집합이 변경될 때 복원 대상을 자동으로 실행하는 대상 집합을 작성했습니다. VS는 이 작업을 수행하지 않기 때문입니다. 그 자체(아직). 불행히도 NuGet 시스템은 이에 대해 아무것도 알지 못하므로 C++/WinRT 파일 템플릿을 추가할 때 packages.config 파일을 추가하려고 시도합니다. 이로 인해 모든 종류의 혼란이 발생하여 예외가 발생하고 프로젝트 파일이 손상됩니다. 이 문제를 해결하는 최선의 방법은 확실하지 않지만 적어도 WinUI 3가 출시되기 전에 살펴볼 수 있다면 정말 감사하겠습니다. 감사 해요!

wjk 에 2019년 07월 14일

👍1

WinUI가 새 프로젝트 SDK( Microsoft.NET.Sdk 또는 MSBuild.Sdk.Extras)를 지원한다면 좋을 것입니다.
이전 스타일의 csproj 파일은 유지 관리하기 어렵습니다. 그리고 WinUI로 마이그레이션하는 데 유용할 수 있는 여러 TargetFrameworks를 함께 사용할 수 없습니다.

maxkatz6 에 2019년 07월 14일

👍20 ❤6 🚀1

F#이 지원되지 않는 이유는 무엇입니까?

TonyHenrique 에 2019년 07월 17일

👍4

여기에서 Azure DevOps 및 Visual Studio App Center 기능을 논의해야 합니까?

kmgallahan 에 2019년 07월 17일

👍1

@vitorgrs 와 마찬가지로 네임스페이스 접두사가 없는 기본 컨트롤을 선호하며 코드에 "노이즈"를 추가합니다. 그리고 어떤 것이 기본 컨트롤이고 어떤 것이 타사인지 확인하는 데 도움이 됩니다.

물론 마이그레이션 도구가 좋을 것입니다. 큰 타사 공급자(Telerik, DevExpress,...)와 함께 작동하는 경우 이미 큰 일이 될 것입니다.

Guruumeditation 에 2019년 07월 17일

👍2

템플릿

이전 버전의 UWP XAML 템플릿에 대한 관심/필요가 VS 새 프로젝트 흐름에 남아 있습니까?

내 쪽에서는 템플릿을 유지할 필요가 없습니다. 그러나 UWP에 WinUI에 없는 컨트롤이 있을 수 있습니까? 이러한 일이 발생할 수 있다면 기존 UWP 앱을 빌드하고 필요한 컨트롤이 있을 때 WinUI로 마이그레이션해야 하는 유효한 이유가 될 수 있습니다. 그런 다음 템플릿이 필요할 수 있습니다.

앱을 빌드하고 최신 Visual Studio 버전으로 더 이상 앱을 만들 수 없는 경우 개발자에게 혼란을 줄 수도 있습니다.

하지만 개인적으로 템플릿을 유지하는 데 관심이 없습니다.

Visual Studio의 템플릿 및 구성 요소와 관련하여 보다 효율적이고 성공적으로 도와드릴 수 있는 방법은 무엇입니까?

나에게 이것은 UWP에 적합해 보입니다. 이제 Win32에서도 동일한 것을 보고 싶습니다. :)

이 연습이 도움이 되었으며 시나리오가 구체화되면 더 많은 정보를 보고 싶습니까?

예, 확실히. 이 연습은 미래의 모습과 모습을 이해하는 데 매우 도움이 됩니다. 나는 이것을 더 보고 싶다.

이주

1-3단계를 자동화하는 마이그레이션 도구를 제공하면 도움이 될까요?

분명히. 이 마이그레이션에는 약간의 Visual Studio 확장이 훌륭한 옵션이 될 수 있습니다. 마이그레이션할 수 있는 것과 마이그레이션할 수 없는 것을 출력하는 "WinUI Compatibility Analyzer"와 같은 것도 생각할 수 있습니다. .NET 이식성 분석기와 유사한 것.

기본 Windows 10 컨트롤 세트 외부에서 어떤 라이브러리를 사용하고 있습니까?

일반적으로 Telerik DataGrid 및 Community Toolkit

현재 생각하고 있지 않은 마이그레이션을 어떤 방법으로 지원할 수 있습니까?

설치한 Win SDK보다 낮은 버전의 UWP 앱을 Visual Studio에서 열면 Visual Studio에서 자동으로 마이그레이션합니다. WinUI 마이그레이션에 대해서도 이와 같은 것을 생각해야 할 수도 있습니다. 확실하지 않지만 명심해야 할 사항입니다. 특히 Visual Studio에 더 이상 일반 UWP 템플릿이 없으면 템플릿으로 만들 수 없는 응용 프로그램이 개발자에게 혼란을 줄 수 있습니다.

기타

다른 댓글에서 이미 언급했듯이 SDK 스타일의 .csproj 파일로 전환해야 할 때라고 생각합니다.

thomasclaudiushuber 에 2019년 07월 17일

Windows 템플릿 스튜디오에 winui 3.0 템플릿을 추가합니다.

touseefbsb 에 2019년 07월 17일

👍2

데스크탑 앱의 WinUI

데스크톱의 WinUI를 통해 개발자는 데스크톱 애플리케이션 모델에서 Windows UI 라이브러리를 사용할 수 있습니다. @marb2000 은 앞으로 몇 주 동안 더 자세한 토론 게시물을 작성하기 위해 노력하고 있습니다. 제안을 위해 그때까지 이 스레드를 자유롭게 사용하십시오.

.net 개발자로서 가장 관심이 가는 부분입니다.

템플릿

이전 버전의 UWP XAML 템플릿에 대한 관심/필요가 VS 새 프로젝트 흐름에 남아 있습니까?

템플릿 수에 따라 다릅니다. 숫자가 낮으면(예: "빈 앱(유니버설 윈도우)"만 언어당, 그래서 C#의 경우 1개) 노이즈가 적고 지원이 가능합니다. 그러나 템플릿이 몇 개 이상 포함된 경우 기본적으로 포함하지 않고 선택적 VS 설치 구성 요소를 추가하여 추가합니다.

Visual Studio의 템플릿 및 구성 요소와 관련하여 보다 효율적이고 성공적으로 도와드릴 수 있는 방법은 무엇입니까?

스캐폴딩이 없는 실제 빈 템플릿을 유지합니다(튜토리얼에 더 적합). asp.net 코어가 무엇을 하는지 살펴보십시오. 새로운 프로젝트 경험에서 많은 변경 사항이 있습니다. 기본적으로 일반 템플릿 "앱(UWP WinUI)"을 선택한 다음 앱 모델과 관련된 두 번째 화면에서 다양한 템플릿을 선택할 수 있습니다. 이 단계를 사용하여 최소 및 대상 플랫폼 버전도 선택합니다(추가 단계 없음). 예를 들어 앱 패키징 프로젝트를 직접 생성하는 옵션을 추가할 수 있습니다.

또한 프로젝트 간에 도구 상자의 구성 요소에 대한 좋은 지원을 제공합니다. 새 컨트롤은 프로젝트별로 그룹화된 도구 상자에 즉시 표시되어야 합니다. 아마도 그들을 구별하는 데 도움이 되는 디자이너 아이콘에 대한 지원일 것입니다.

이 연습이 도움이 되었으며 시나리오가 구체화되면 더 많은 정보를 보고 싶습니까?

예

언어 지원

1-3단계를 자동화하는 마이그레이션 도구를 제공하면 도움이 될까요?

좋은 문서(명확한 단계가 있는 한 페이지)로 충분해야 합니다. csproj를 직접 편집하지 않고 VS 내에서 모든 작업을 수행할 수 있다면 단계를 설명하는 문서 페이지만 추가하는 것이 좋습니다.

새 csproj 형식으로 전환하기로 결정했다면(그리고 그렇게 하기를 희망합니다) 마이그레이션하려면 csproj 파일을 편집해야 하므로 마이그레이션 도구가 확실히 필요합니다.

포장

MSIX는 모든 앱에 대한 최신 패키징 방법입니다. Win32의 WinUI의 경우 ClickOnce를 지원해야 합니까? 어떤 다른 패키징 방법에 대한 지원을 포함해야 합니까? 특히 Win32의 WinUI의 경우

clickonce와 msix 배포의 차이점을 비교하십시오.

앱 설치 프로그램 기능 은 이전 Windows 버전에서 동일한 경험을 제공하지 않습니다.
MSIX에는 유효한 서명된 패키지(내부 또는 공개)가 필요합니다. Clickonce는 자체 서명 패키지를 지원합니다.
패키지 모델 에는 몇 가지 제한 사항이 있으며 대부분 격리된 환경(로컬 앱 데이터 액세스 없음, 상승된 작업 없음)으로 인해 발생합니다.

저에게 가장 성가신 문제는 2입니다. 일반적으로 도메인에 등록되지 않은 컴퓨터에 내부적으로 배포되는 clickonce 앱이 있습니다. 따라서 이러한 종류의 앱의 경우 유효한 공개 서명 인증서로 패키지에 서명해야 합니다.

Appx 패키징 형식은 종종 Store를 대상으로 하는 앱에 대해서만 광고되고 제한 사항이 표시될 때 웹 배포 형식에도 적용되는지 여부를 항상 알 수 없기 때문에 이 두 프레임워크 간의 모든 차이점을 예상하기 어렵습니다.

디자이너 경험

공연, 공연, 공연, 프로젝트가 많은 대규모 솔루션 지원.

tbolon 에 2019년 07월 17일

👍1

Windows 10 SDK의 WinUI 버전과 WinUI Xaml 디자이너가 오픈 소스로 만들어질 예정입니까?

디자인 타임 워크플로 및 경험에 대한 요청을 게시할 수 있습니까?

SDK는 WinUI의 nuget 릴리스와 유사한 릴리스 주기를 따를 것입니까?

mdtauk 에 2019년 07월 17일

👍2

추가 통증:
관리형 비관리형 믹싱 디버그 환경을 개선합니다.
현재 비관리 코드에서 예외가 발생하면 관리 디버그 사이트에 COMException 가 표시됩니다. 호출 스택이 관리/비관리 경계를 1회 이상 교차하면 상황이 더 나빠질 수 있습니다.
WPF와 비교하여 관리되는 호출 스택은 항상 사용 가능하며 throw된 예외는 디버그에 유용한 문자열을 전달합니다.
관리되지 않는 세계와 COM 모델이 관리되는 것만큼 편리하지 않다는 것을 알고 있습니다. 그러나 적어도 프레임워크에서 예외(잘못된 HResult)가 발생하면 오픈 소스 저장소에서 코드 행을 찾는 데 필요한 정보가 필요합니다 . 방법은 수동일 수 있지만 결정적이어야 합니다.

huoyaoyuan 에 2019년 07월 17일

우리는 ClickOnce에 크게 의존하므로 단기적으로 지원하는 것이 좋습니다. 우리는 MSIX로 마이그레이션할 의향이 있지만 유사한 기능이 제공되면.

템플릿의 경우 NavigationView 및 탐색을 위한 상용구 UI와 코드를 제공하는 템플릿이 있으면 좋을 것입니다.

고마워

shaggygi 에 2019년 07월 17일

👍2

우리는 ClickOnce에 크게 의존하므로 단기적으로 지원하는 것이 좋습니다. 우리는 MSIX로 마이그레이션할 의향이 있지만 유사한 기능이 제공되면.
템플릿의 경우 NavigationView 및 탐색을 위한 상용구 UI와 코드를 제공하는 템플릿이 있으면 좋을 것입니다.
고마워

가장 일반적인 앱 "쉘" 구조 및 패턴 - 개발자가 빠르게 시작하고 실행할 수 있도록 템플릿으로 사용할 수 있어야 합니다. Microsoft의 자사 앱은 이러한 레이아웃의 모범이 되어야 하며 Fluent Design 및 WinUI에 대한 동작, 일관성 및 UI 디자인 규범 준수 측면에서 모범 사례로 작동해야 합니다.

mdtauk 에 2019년 07월 17일

👍3

@shaggygi @mdtauk
"가장 일반적인 앱 "쉘" 구조 및 패턴" 및 "템플릿의 경우 NavigationView 및 탐색을 위한 상용구 UI 및 코드를 제공하는 것이 있으면 좋을 것입니다." Microsoft와 커뮤니티에서 유지 관리하고 개발하는 Windows 템플릿 스튜디오 가 있습니다. 소개를 인용하자면:

WTS(Windows 템플릿 스튜디오)는 마법사 기반 환경을 사용하여 새로운 UWP(유니버설 Windows 플랫폼) 앱 생성을 가속화하는 Visual Studio 2017 및 2019 확장입니다. 결과 UWP 프로젝트는 최신 Windows 10 기능을 통합하는 동시에 입증된 패턴과 모범 사례를 구현하는 잘 구성된 읽기 가능한 코드입니다.

Felix-Dev 에 2019년 07월 17일

👍2

@Felix-Dev는 결국 UWP 외에도 WPF 템플릿이 있습니까?

shaggygi 에 2019년 07월 17일

@shaggygi 반가운 소식이 있을 것 이 스레드를 참조하십시오.

Felix-Dev 에 2019년 07월 17일

👍2

우리는 C++/WinRT를 사용하고 있습니다. 현재 xaml 디자이너 또는 바인딩을 사용하지 않습니다. 그러나 런타임에 컨트롤을 만들고 UWP xaml을 통해 스타일을 지정할 것입니다. 도킹/플로팅 창 등을 포함하여 xaml 섬이 있는 대화 상자와 모덜리스 자식 Windows도 필요합니다.

ghost 에 2019년 07월 17일

내 C++ 앱용 XAML을 작성하려고 시도했지만 소년은 고통스러운 경험을 했습니다.

모든 것을 올바르게 생성하고 올바르게 패키징하기 위해 문서화되지 않은 많은 프로젝트 속성과 기타 해킹을 추가해야 했습니다.

예를 들어:

XAML 페이지를 저장할 프로젝트를 만들 때 <_NoWinAPIFamilyApp>true</_NoWinAPIFamilyApp> 및 <_VC_Target_Library_Platform>Desktop</_VC_Target_Library_Platform> 두 가지 프로젝트 속성을 추가해야 했습니다. 이 속성은 완전히 문서화되지 않고 새 터미널의 소스 코드를 검사해야만 알아낼 수 있습니다.
나는 앱 클래스를 만들고 사용할 때까지 "메인 창이 아직 생성되지 않았기 때문에 새 보기를 생성할 수 없습니다"라는 수수께끼가 있었습니다. 이 클래스는 일반 페이지를 만들고 속성으로 이동하는 것 외에는 VS에서 방법이 없습니다. VS에서 XAML 파일을 만들고 응용 프로그램 정의로 변경한 다음 MIDL, 소스 코드 및 XAML 파일을 조정합니다.
Microsoft.Toolkit.Win32.UI.XamlApplication NuGet 패키지를 추가하여 응용 프로그램 클래스를 만들었고 Microsoft.VCRTForwarders 도 추가할 때까지 로드할 수 없었습니다. 다시 터미널 소스를 검사할 때 이것을 찾았습니다. 두 패키지에 대한 표시가 어디에도 없습니다.
PRI는 .wapproj 파일에 무언가를 추가할 때까지 하나로 병합되지 않았으므로 내 XAML 리소스를 찾을 수 없습니다.
내가 <DisableEmbeddedXbf>false</DisableEmbeddedXbf> 를 추가할 때까지 XBF는 작동하지 않았습니다. 이
내 앱 매니페스트의 maxVersionTested 는 카멜 케이스 버전을 사용하라는 지침에도 불구하고 모두 소문자로 변경할 때까지 완전히 무시되었습니다. https://github.com/MicrosoftDocs/windows-uwp/issues/1781 # 이슈

또한 C++/WinRT도 골치 아픈 문제였습니다.

증분 빌드를 실행할 때마다 사용자 지정 클래스에 대해 [msg]redefinition [context]: MyClass 가 있었는데 이는 C++/WinRT 헤더로 인해 오래 걸리는 클린 빌드를 실행할 때까지 빌드를 방해하고 사라지지 않았습니다. 그 문제는 어떻게 든 마법처럼 중간에 사라졌습니다.
이제 클린 빌드를 실행할 때 헤더 누락에 대한 오류가 발생합니다. 빌드 버튼을 두 번 누르면 다시 작동합니다.
C++/WinRT의 잘못된 codegen 때문에 내 자신의 AppT<> 클래스를 작성해야 했습니다. 터미널 앱과 XAML 섬 샘플은 마치 사용자가 근본 문제를 해결하는 대신 수행해야 하는 작업인 것처럼 동일한 작업을 수행합니다.
MIDL 파일에서 무엇이든 변경하면 클린 빌드를 수행할 때까지 빌드 오류가 발생합니다.

그럼에도 불구하고 내 앱 매니페스트에 activatableClass 추가해도 패키징되지 않은 상태로 작동하지 않습니다(PRI를 병합하지 않았을 때와 같이 XAML 리소스를 찾을 수 없다는 문제). 이는 중요합니다. 내 앱이 지원할 수 있습니다.

sylveon 에 2019년 07월 18일

👍6 👀1

이주

1-3단계의 자동화는 특히 수백 개의 파일에서 네임스페이스 이름을 바꾸는 데 시간이 많이 걸리고 오류가 발생하기 쉽기 때문에 확실히 도움이 됩니다. 그 위에 compat 분석기는 현재 코드베이스가 얼마나 호환되는지에 대한 보고서를 생성하고 필요한 모든 변경 사항을 기록하는 .net 프레임워크 > .net 코어와 같이 좋을 것입니다.

압형

다른 사람들이 이미 말했듯이 기능이 더 풍부한 편집기가 좋을 것입니다. 여기 직장에서 대부분의 시간 XAML은 수작업으로 이루어지며 대부분 앱이 어떻게 생겼는지에 대한 대략적인 골격에 대한 가이드로 디자이너를 사용합니다. Intellisense 및 스마트 리팩토링은 특히 사용자 정의 UserControls 가 많은 경향이 있는 경우와 같은 항목(예: 종속성 속성 또는 태그)의 이름을 바꾸는 데 CTRL + R + R 와 같은 QoL이 정말 도움이 될 것입니다. GoTo 구현 및 참조. Roslyn 분석기 지원도 정말 좋습니다.

네임스페이스 개선 사항을 확장합니다. 기본 네임스페이스에 새로운 XmlnsDefinition 를 추가하지 않고 접두사가 아닌 사용자 정의 컨트롤을 더 쉽게 수행할 수 있고 마크업 imo를 정리하고 다음과 같이 모호한 컨트롤이 있는 경우에만 접두사가 필요하면 좋을 것입니다. 클래스가 작동하는 방식은 GoTo 구현과도 잘 연결됩니다. 일반적으로 컨트롤의 이름과 전체 네임스페이스를 표시하기 위해 컨트롤 위에 마우스를 가져가면 컨트롤의 출처를 알 수 있을 것입니다. 일반적으로 필요한 경우가 아니면 C# 코드에서 네임스페이스 별칭을 사용하지 않을 것입니다.

대부분 도구에서 리팩토링을 덜 취약하게 하거나 번거로움을 줄이고 마크업을 더 쉽게 탐색할 수 있도록 C# 편집기처럼 작동하면 좋을 것입니다. 그 외에도 XAML 언어 자체에 관해서는 장황함을 줄이는 것이 #62 및 #279에서 논의된 스타일링이 되는 좋은 예가 될 것입니다.

RyoukoKonpaku 에 2019년 07월 19일

👍3

네임스페이스 개선 사항을 확장합니다. 기본 네임스페이스에 새로운 XmlnsDefinition 를 추가하지 않고 접두사가 아닌 사용자 정의 컨트롤을 더 쉽게 수행할 수 있고 마크업 imo를 정리하고 다음과 같이 모호한 컨트롤이 있는 경우에만 접두사가 필요하면 좋을 것입니다. 클래스가 작동하는 방식은 GoTo 구현과도 잘 연결됩니다. 일반적으로 컨트롤의 이름과 전체 네임스페이스를 표시하기 위해 컨트롤 위에 마우스를 가져가면 컨트롤의 출처를 알 수 있을 것입니다. 일반적으로 필요한 경우가 아니면 C# 코드에서 네임스페이스 별칭을 사용하지 않을 것입니다.
페이지 컨트롤의 WinUI 3.0 버전은 이러한 컨트롤에 접두사를 사용할 필요가 없다고 생각합니다. 나는 이것이 SDK 수준의 것이 될 것이라고 생각합니다.

mdtauk 에 2019년 07월 19일

👍2 ❤1

WinUI를 사용할 때 네임스페이스를 변경하지 않을 수 있습니까?

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

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

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

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

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

혜택:

코드를 앞뒤로 변경할 필요가 없습니다.
로컬 WinUI 코드가 안정화되면 Windows 플랫폼으로 다시 병합하여 모든 새 Windows 릴리스에서 시스템 앱과 LOB 앱이 새로운 개선 사항을 활용할 수 있습니다.
한편으로는 .NET Framework와 같이 호환성이 높은 매우 안정적인 시스템 프레임워크입니다. 그리고 다른 쪽은 .NET Core와 같으며 더 빠른 속도로 변경되며 두 가지의 모든 이점이 있고 문제가 없습니다.

Nirmal4G 에 2019년 07월 19일

👍2

포팅 도구를 제공할 필요가 없다고 생각합니다. Find&Replace를 사용하면 합리적으로 쉽게 변경할 수 있으며 인스턴스 수는 상당히 적을 것입니다.

MarkIngramUK 에 2019년 07월 19일

👎1

또한 더 많은 문제가 발생했습니다.

App 클래스에 리소스를 추가한 후 XAML은 이것을 추가할 때까지 이를 찾을 수 없었습니다. 다시 터미널 앱에서 찾았고 실제로 수행하는 작업에 대해 잘 알지 못했습니다.
xml <Target Name="PlaceAppXbfAtRootOfResourceTree" DependsOnTargets="GetPackagingOutputs"> <ItemGroup> <_RelocatedAppXamlData Include="@(PackagingOutputs)" Condition="'%(Filename)' == 'App' and ('%(Extension)' == '.xaml' or '%(Extension)' == '.xbf')" /> <PackagingOutputs Remove="@(_RelocatedAppXamlData)" /> <PackagingOutputs Include="@(_RelocatedAppXamlData)"> <TargetPath>%(Filename)%(Extension)</TargetPath> </PackagingOutputs> </ItemGroup> </Target>
빌드는 cannot find type Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication 와 유사한 오류와 함께 무작위로 완전히 중단되며 프로젝트를 다시 빌드하는 유일한 방법은 클린 빌드를 수행하는 것입니다.
기본 exe에 대한 vcxproj를 시작 프로젝트로 직접 설정하여 앱을 실행할 수 없습니다. 수동으로 bin\x64\Debug\AppX 에서 패키징되지 않은 appx 출력을 시작한 다음 VS 내에서 디버거를 주입하거나 앱 패키지를 설정해야 합니다. 시작 프로세스로.

sylveon 에 2019년 07월 21일

Windows 데스크톱의 관련 항목 2019년 7월 25일 .

shaggygi 에 2019년 07월 25일

👍1

오랜 시간 WinForms, UWP 경험이 있는 WPF 개발자입니다. 여기 내 2센트가 있습니다.

이주

기존 UWP 앱을 WinUI로 마이그레이션하는 도구는 필수입니다.
기존 앱에서 WinForms 또는 WPF 컨트롤을 WinUI 컨트롤로 변환하는 도구는 굉장할 것입니다. 컨트롤을 변환한다는 것은 컨테이너의 참조를 개별 컨트롤로 변경하는 것을 의미합니다.
모바일 앱을 Windows로 백포팅할 수 있도록 Xamarin Forms를 WinUI로 마이그레이션하는 도구입니다.

압형

현재 XAML 편집기는 끔찍합니다! 일반 텍스트 편집기 캔버스를 사용하고 더 나은 인텔리센스 및 리팩토링을 위해 XAML 개체 모델에 적용할 Roslyn 기능을 제공해야 합니다.
Visual Studio가 64비트가 될 때까지 XAML 편집기는 백그라운드에서 독립 실행형 64비트 앱이어야 합니다. 많은 XAML로 작업할 때 메모리 부족 오류를 중지하려면 계속해서 VS 2017 및 VS 2019를 다시 시작해야 합니다.

템플릿

이러한 프로젝트 템플릿이 필요합니다.
- NavigationView WinUI
- NavigationView WPF
- 리본 WinUI
- 리본 WPF
- 리본 WinForms
이 페이지/창 템플릿이 필요합니다.
- 미디어 컨트롤러 페이지
- 브라우저 페이지
- 대화창
- 테두리 없는 창
- 플로팅 윈도우
제어 템플릿이 필요합니다.
- 캡슐화된 데이터 그리드 보기
- 캡슐화된 하위 데이터 보기

이 마지막 두 개는 함께 작동하여 쉬운 Master-Detail 창을 만듭니다.

sharpninja 에 2019년 07월 29일

👍2

이러한 모든 템플릿과 페이지 등은 이미 Windows Template Studio 프로젝트에서 수행되고 있습니다. 모두 다시 만드는 대신 동일한 경로를 따르지 않겠습니까?

touseefbsb 에 2019년 07월 29일

👍3

SDK 스타일 프로젝트 파일
다른 많은 사람들이 언급했듯이 제가 보고 싶은 가장 중요한 부분 중 하나는 UWP 및 "Desktop XAML" 앱 모두에 대한 새로운 SDK 스타일 프로젝트 파일 형식에 대한 지원입니다.

UWP와 Desktop XAML 앱 모델 간의 마이그레이션
"Desktop XAML" 앱을 빌드하기 시작하면 UWP 앱에서 얼마나 멀리 떨어져 있습니까? UWP 샌드박스의 제약 조건 내에 머물렀다는 것을 알게 되면 나중에 이를 UWP 앱으로 바꾸는 것이 간단할까요? 또는 UWP 앱을 빌드하기 시작하고 더 많은 것이 필요하다는 것을 깨닫는 경우 "Desktop XAML" 앱으로 쉽게 전환할 수 있습니까?

petroemil 에 2019년 07월 29일

👍8

저는 Template Studio를 지원하고 있습니다.

Nirmal4G 에 2019년 07월 29일

저는 Template Studio를 지원하고 있습니다.

Template Studio는 XAML C++ 프로젝트를 지원합니까?

Template Studio가 수행하는 작업은 WinUI SDK IMO의 일부여야 합니다.

mdtauk 에 2019년 07월 30일

👍2

Template Studio가 수행하는 작업은 WinUI SDK IMO의 일부여야 합니다.

Visual Studio IDE IMO의 일부여야 합니다! 😎

Nirmal4G 에 2019년 07월 30일

요점은 Windows 템플릿 스튜디오가 UWP 프로젝트 생성을 위해 올인원 작업을 수행하고 있으므로 xaml C++ 지원과 같은 것이 누락된 경우 이를 염두에 두고 Windows 템플릿 스튜디오에 추가하는 것을 고려해야 한다는 것입니다. 더 빠르고 더 많을 것이라고 생각합니다. uwp 프로젝트의 모든 새로운 혁신이 하나의 프로젝트에 남아 있으면 효율적입니다.

touseefbsb 에 2019년 07월 30일

XAML이나 MVVM 없이 직접 WinUI 3 스택의 하위 계층을 사용하는 몇 가지 방법이 있습니다. 이것은 이미 코드베이스에 일종의 MV 아키텍처가 있는 기존의 대규모 C++ 소프트웨어에 특히 유용합니다. 그들은 HWND + GDI보다 더 나은 것을 원합니다.

그리고 사람들이 WinUI 3가 장난감이 아니라 진지한 소프트웨어를 실제로 지원할 수 있다고 생각하게 하십시오.

be5invis 에 2019년 08월 03일

👍3 ❤1

@be5invis 전적으로 동의합니다. 현재 유일한 솔루션은 XamlDirect이지만 미들웨어 개발자를 대상으로 합니다.

MarkIngramUK 에 2019년 08월 03일

이미 Xaml Islands를 사용하여 콘텐츠를 수동으로 빌드할 수 있습니다. DesktopWindowXamlSource가 작동하고 창에 연결되도록 한 다음 코드에서 컨트롤을 만들고 정렬/레이아웃하기만 하면 됩니다.

https://gist.github.com/sylveon/5bc68b2801333b24f7b3165c3f098cc9#file -picker-cpp-L46

sylveon 에 2019년 08월 03일

👍2

@MarkIngramUK CreateWindow 를 WinUI 기능으로 바꾸는 것과 같이 더 "완벽한" 것이 필요할 수 있습니다.

be5invis 에 2019년 08월 04일

디자인을 위해 미래의 WinUI WPF 템플릿이 현재 UWP 앱과 같은 제목 표시줄로 페이지 콘텐츠를 확장하는 기능을 지원하고 싶습니다. 지금은 기존 XAML 아일랜드 솔루션을 사용하여 최신 보기가 아니라 WPF/WinForms 창 내부에서 컨트롤을 호스팅하고 있습니다.

duke7553 에 2019년 08월 20일

👍1

@LucasHaines WinUI 3.0에서 지원할 계획인 언어 목록: C#, C++/WinRT, Visual Basic. 우리는 F#의 지원을 모색하고 있습니다.

이것은 F#뿐만 아니라 모든 .Net 언어에 대해 잘못하고 있음을 보여줍니다. 템플릿과 .xaml 파일에 대해 생각하는 것부터 시작합니다. 이는 구조를 완성하지 않고 집을 짓고 카펫과 커튼을 제자리에 놓는 것과 같습니다.

WinUI를 Nuget 패키지로 .Net Standard 2.0/.Net Core 3.0/.Net 5 프로젝트에 설치할 수 있어야 합니다. 그런 다음 내부에 정의된 모든 클래스에 액세스할 수 있습니다. 그런 다음 WinUI 프로젝트(C# 전용일 수 있음)에서 이러한 프로젝트를 참조할 수 있습니다. 이를 통해 WinUI 보기를 모든 .Net 언어로 만들 수 있습니다. Xamarin.Forms가 수행하는 방법을 확인하세요 .

charlesroddie 에 2019년 08월 22일

클래스는 이미 F#에서 사용할 수 있습니다(모든 .NET 언어에서 사용할 수 있는 Windows 런타임 구성 요소이기 때문에).

레이아웃을 수동으로 생성할 수 있습니다. 모든 WinUI 관리에 대해 Py/WinRT를 사용하여 Python을 통해 수행할 수도 있습니다.

sylveon 에 2019년 08월 23일

@sylveon 구체적으로 어떤 수업이 있습니까? 관심이 있을텐데...

duke7553 에 2019년 08월 23일

그들 모두. WinUI의 공개 API는 Windows 런타임 구성 요소일 뿐입니다.

sylveon 에 2019년 08월 23일

@LucasHaines WinUI 3.0에서 지원할 계획인 언어 목록: C#, C++/WinRT, Visual Basic. 우리는 F#의 지원을 모색하고 있습니다.
이것은 F#뿐만 아니라 모든 .Net 언어에 대해 잘못하고 있음을 보여줍니다. 템플릿과 .xaml 파일에 대해 생각하는 것부터 시작합니다. 이는 구조를 완성하지 않고 집을 짓고 카펫과 커튼을 제자리에 놓는 것과 같습니다.
WinUI를 Nuget 패키지로 .Net Standard 2.0/.Net Core 3.0/.Net 5 프로젝트에 설치할 수 있어야 합니다. 그런 다음 내부에 정의된 모든 클래스에 액세스할 수 있습니다. 그런 다음 WinUI 프로젝트(C# 전용일 수 있음)에서 이러한 프로젝트를 참조할 수 있습니다. 이를 통해 WinUI 보기를 모든 .Net 언어로 만들 수 있습니다. Xamarin.Forms가 수행하는 방법을 확인하세요 .

이 주제/질문은 도구에 관한 것입니다. 예, 라이브러리는 라이브러리를 사용할 수 있는 모든 언어에서 직접 참조할 수 있지만 도구와 언어 지원 간에 정의가 모호합니다.
Xamarin.Forms를 예로 들어보겠습니다. 이는 C# 및 F#에 대한 도구만 제공합니다. VB.Net 및 Xamarin.Forms를 사용하여 앱을 빌드할 수 있지만 도구가 없고 문서가 제한적이기 때문에 _공식적으로 지원되지_ 않습니다.

WinUI 윈도우의 특정와 같이 또한, 다만 어떤 닷넷 표준 2.0 / 닷넷 코어 3.0 / 닷넷 5 프로젝트에서 참조 할 수 없습니다.
일부 시나리오에 대한 프로젝트/컴파일러/패키징 수준 지원도 필요합니다.

mrlacey 에 2019년 08월 23일

👍1

v2.2 릴리스 에 대한 훌륭한 작업 팀. v3.0 상태에 대한 간략한 업데이트를 받을 수 있습니까?

shaggygi 에 2019년 09월 04일

나는 이것이 여러 번 언급되는 것을 보았지만 어떤 방향으로든 명확한 방향이 없었습니다. WinUI 3.0에는 모든 컨트롤이 있으므로 이제 WinUI 라이브러리 컨트롤을 참조하기 위한 네임스페이스 요구 사항을 제거해야 합니다. 이것은 XAML을 많이 복잡하게 만들고 마이그레이션을 크게 방해하며 UNO 플랫폼 및 Avalonia와 같은 간단한 호환성을 깨뜨립니다.

XAML에서 xmlns:mux="using:Microsoft.UI.Xaml.Controls" 대한 필요성을 제거하십시오. 코드 비하인드가 여전히 변경되어야 한다는 것을 이해합니다. 프로젝트의 일부 위치에 이에 대한 구성이 있을 수도 있습니다.

robloo 에 2019년 09월 10일

👍3 🚀1

XAML에서 xmlns:mux="using:Microsoft.UI.Xaml.Controls" 대한 필요성을 제거하십시오.

XAML _markup_에서는 필요하지 않지만 코드 숨김에서 네임스페이스를 변경해야 합니다.

jevansaks 에 2019년 09월 10일

Windows 컨트롤을 사용하려는 경우(OS에서 제거되지 않은 경우) - XAML에서 네임스페이스를 선언해야 합니다.

mdtauk 에 2019년 09월 10일

Windows 컨트롤을 사용하려는 경우(OS에서 제거되지 않은 경우) - XAML에서 네임스페이스를 선언해야 합니다.

시나리오가 아닌 WinUI 3.0을 사용하면 OS 컨트롤을 WinUI 3.0 컨트롤과 혼합 및 일치시킬 수 없습니다. 이러한 컨트롤은 OS에 대한 추가 기능이기 때문에 지금은 WinUI 2.x에서만 작동합니다(또한 NavigationView 및 TreeView와 같은 두 위치에서 유형을 제공하여 모호성을 유발하는 어색한 경우가 많습니다).

jevansaks 에 2019년 09월 10일

Windows 컨트롤을 사용하려는 경우(OS에서 제거되지 않은 경우) - XAML에서 네임스페이스를 선언해야 합니다.
시나리오가 아닌 WinUI 3.0을 사용하면 OS 컨트롤을 WinUI 3.0 컨트롤과 혼합 및 일치시킬 수 없습니다. 이러한 컨트롤은 OS에 대한 추가 기능이기 때문에 지금은 WinUI 2.x에서만 작동합니다(또한 NavigationView 및 TreeView와 같은 두 위치에서 유형을 제공하여 모호성을 유발하는 어색한 경우가 많습니다).

좋은 소식입니다. OS에서 더 쉽게 사용하지 않도록 할 것입니다. 설정 앱, 셸 및 기타 OS 부분도 WinUI 3.0으로 이동하기를 바랍니다.

그리고 가능한 한 동일한 코드를 재사용하는 XAML로의 관리자 도구, 워드패드 등의 포트를 희망합니다!

mdtauk 에 2019년 09월 10일

@jevansaks 알겠습니다 . 피드백 주셔서 감사합니다!

@mdtauk XAML 에서 'OS' 레거시 컨트롤과 새로운 'WinUI 3.0' 플랫폼 컨트롤을 구분할 필요가 없습니다. 모든 것이 WinUI 3.0으로 이동하고 있으며 OS 컨트롤은 더 이상 기능 업데이트를 받지 않습니다. 개발자가 여전히 레거시 컨트롤을 대상으로 하려는 경우 WinUI 3.0 이후에는 이전 SDK 및 Visual Studio 버전으로 개발해야 합니다. XAML에서 두 개의 Microsoft/Windows UI 컨트롤 라이브러리를 참조하는 기능을 유지하는 것은 앞서 언급한 이유로 방해가 될 수 있습니다. 게다가, WinUI 개발의 분리로 마침내 이와 같은 변경을 '허용'하는 지속 가능한 경로로 전환할 수 있습니다.

편집: 회신하기 전에 새로고침하는 것을 잊었습니다. 이제 대부분이 중복됩니다.

robloo 에 2019년 09월 10일

@robloo 이전 버전의 UWP Xaml을 완전히 대체하게 되어 기쁩니다. 또한 OS가 Inbox Apps 및 Shell용으로 이전될 수 있기를 바랍니다.

또한 WinUI 3.0으로 전환하는 과정과 Win32 앱과 동일한 수명 주기로 WinUI 3.0으로 작업하는 방법을 자세히 설명하는 개발자 비디오가 많이 있기를 바랍니다. 더 이상 수분 공급이 필요 없으며 페이지 상태 및 탐색 등을 저장하는 더 나은 방법이 있습니다.

WinUI 3.0으로 이동할 계획인 앱에 따라 Wordpad를 사용하고 코드를 WinUI에 내장된 새 UI로 옮기는 것과 같은 예를 제공하는 것이 도움이 될 수 있습니다. WinUI 3.0으로

mdtauk 에 2019년 09월 10일

WinUI 3의 경우 디자인 언어에서 앱 기능의 배치와 관련하여 어느 정도 일관성이 있어야 합니다.

이와 관련하여 앱 설정.

앱 설정은 어디에서 찾을 수 있습니까? 오른쪽 상단에 있는 톱니바퀴를 클릭합니까? 왼쪽 하단 모서리? 오른쪽 상단에 있는 프로필 아바타를 클릭하고 설정을 누르나요? 왼쪽 상단을 클릭합니까? 왼쪽 아래? 편집 > 기본 설정으로 이동합니까?

shaheedmalik 에 2019년 09월 12일

👍2

NavigationView를 사용하는지 여부에 따라 다릅니다...

보낸 사람: shaheedmalik [email protected]
보낸 날짜: 2019년 9월 12일 목요일 오후 3:48:12
받는 사람: microsoft/microsoft-ui-xaml [email protected]
참조: 더 샤프 닌자 [email protected] ; 댓글 [email protected]
제목: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 개발자 경험 및 도구 - 입력 필요(#1045)

WinUI 3의 경우 디자인 언어에서 앱 기능의 배치와 관련하여 어느 정도 일관성이 있어야 합니다.

이와 관련하여 앱 설정.

앱 설정은 어디에서 찾을 수 있습니까? 오른쪽 상단에 있는 톱니바퀴를 클릭합니까? 왼쪽 하단 모서리? 오른쪽 상단에 있는 프로필 아바타를 클릭하고 설정을 누르나요? 왼쪽 상단을 클릭합니까? 왼쪽 아래? 편집 > 기본 설정으로 이동합니까?

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
직접이 이메일에 회신는 GitHub의에서 볼 https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLB5VXXUOYIA2NIEZATQJKTIZA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TGV4I#issuecomment-531000049 , 또는 스레드 음소거 https : //로 github에 있습니다. com/notifications/unsubscribe-auth/AD3GCLCQQ6L7H3LEJAHUDMLQJKTIZANCNFSM4ICOLUJQ .

sharpninja 에 2019년 09월 12일

Visual Studio의 템플릿 및 구성 요소와 관련하여 보다 효율적이고 성공적으로 도와드릴 수 있는 방법은 무엇입니까?

Visual Studio에서 WinUI/XAML 아일랜드가 C++/WinRT와 작동하도록 하려면 상당한 노력과 문서화되지 않은 프로젝트 구성 속성이 필요하지 않습니다.

sylveon 에 2019년 10월 03일

👍1

이것을 충분히 강조할 수는 없지만 나에게 가장 중요한 것은 WinUI가 Windows 이상으로 렌더링된다는 것입니다.

Surface Duo를 보자마자 Microsoft가 Android 기반 장치를 출시할 때 크로스 플랫폼 개발 스토리가 어떻게 될지 궁금했습니다. Xamarin.Forms는 여러 가지 명백한 이유로 이를 잘라내지 않습니다. Microsoft가 수년 동안 다양한 형태로 요청되어 온 (UNO 플랫폼과 유사하지만 완성되고 안정적인) 크로스 플랫폼 툴킷을 완전히 수용해야 할 때입니다. 마이크로소프트가 개발자들을 위해 아직 말하지 않은 몇 가지 계획을 갖고 있기를 바랍니다.

Satya는 "우리는 경험과 하나의 장치를 구축하는 것이 아니라 우리 삶의 모든 장치에 적용되는 것을 원했습니다."라고 말했습니다. Panos가 바라는 대로 개발자가 이 놀이기구에 참여하기를 원한다면 이것이 최선의 방법입니다. 그렇지 않으면 개발자에게 Surface Duo와 나머지 제품군 간의 '경험'을 확장하기 위해 두 개의 개별 UI를 작성하도록 요청하는 것입니다. 하나의 '패밀리' 장치에 속한 개발자에게 이는 공정한 요청이 아니라고 생각합니다.

robloo 에 2019년 10월 03일

🚀3 ❤2

~~각 플랫폼에서 "네이티브 룩앤필"로 다르게 렌더링됩니다.~~

~~나는 이것을 이해하지 못한다.~~ ~~제발 하지마, 내가 Fluent Design이 하기를 바라는 마지막 일은 더 많은 불일치를 야기하는 것이지 덜하지 않게 하는 것입니다.~~

편집: 원래 댓글이 제거됨

sylveon 에 2019년 10월 03일

Satya는 "우리는 경험과 하나의 장치를 구축하는 것이 아니라 우리 삶의 모든 장치에 적용되는 것을 원했습니다."라고 말했습니다. Panos가 바라는 대로 개발자가 이 놀이기구에 참여하기를 원한다면 이것이 최선의 방법입니다. 그렇지 않으면 개발자에게 Surface Duo와 나머지 제품군 간의 '경험'을 확장하기 위해 두 개의 개별 UI를 작성하도록 요청하는 것입니다. 하나의 '패밀리' 장치에 속한 개발자에게 이는 공정한 요청이 아니라고 생각합니다.

이것이 바로 내가 Duo가 Android라는 사실에 낙담한 이유입니다.

shaheedmalik 에 2019년 10월 06일

👍2

템플릿에서 발생하는 문제 영역을 제거하려면 템플릿을 오픈 소스여야 합니다.

shaheedmalik 에 2019년 10월 06일

👍1

WPF와 함께 WinUI를 사용할 때와 다음과 같은 코드로 새 컨트롤을 만들 때:
c# public class MyControl : UserControl { ... }
WinUI.UserControl 또는 WPF.UserControl을 사용합니까?
우리는 선택해야 하고 어떻게 대처해야 합니까?

maxkatz6 에 2019년 10월 15일

👍1

흥미롭게도 XAML 도구가 통합되면 일종의 공유 xaml 파일을 만들 수 있습니까?
다음과 같은 것:

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

특별한 루트 네임스페이스가 있는 일종의 공유 방언이어야 합니까? (예: Visual Studio의 공유 프로젝트). 조건부 xaml처럼 보일 수 있습니다.

maxkatz6 에 2019년 10월 15일

WinUI.UserControl 또는 WPF.UserControl을 사용합니까?
우리는 선택해야 하고 어떻게 대처해야 합니까?

이것은 사용자가 정의한 XAML에서 자동으로 발생해야 합니다.

<UserControl 
   x:Class="MyApp.MyControl" 
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

이는 컴파일러에게 UWP임을 알려줍니다.

public class MyControl : UserControl { ... }

이것은 실제로 잘못된 것입니다. 이렇게 선언해야 합니다.

public partial class MyControl { }

상속을 지정하는 .g.cs 파일과 사용 중인 프레임워크에 의해 처리되기 때문에 상속이 필요하지 않습니다.

sharpninja 에 2019년 10월 15일

템플릿에 관해서는 Hello World 템플릿 이상이 있으면 더 기쁠 것입니다. 내 말은 Microsoft가 클라이언트 앱과 함께 작동하는 데 필요한 주변기기 인식 프레임워크를 백업해야 한다는 것입니다.

@weitzhandler 나도

C# 및 Cpp/WinRT 프로젝트용 SDK 스타일 프로젝트도 반드시 있어야 합니다.

stevenbrix 에 2019년 10월 23일

모든 일반적인 Win32 및 Inbox 앱 패턴에 대한 템플릿이 있어야 한다고 생각합니다. 내 머리 꼭대기에서 짧은 목록 :

리본
메인 메뉴
탭 문서 인터페이스
탐색 보기
명령/도구 모음
상위 탐색 보기
허브/갤러리(약간 더 이상 사용되지 않는 것으로 알고 있음)
Treeview/MasterDetails(파일 탐색기, RegEdit, 관리 앱)

그러나 공통 대화 상자, 페이지, 설정 페이지 등에 대한 항목 템플릿도 있어야 합니다.

mdtauk 에 2019년 10월 23일

Visual Studio의 템플릿 및 구성 요소와 관련하여 보다 효율적이고 성공적으로 도와드릴 수 있는 방법은 무엇입니까?

VSCode/Visual Studio용 C++ 확장으로 작업합니다. VS Code를 Visual Studio와 유사한 경험을 제공하는 지원되는 편집기로 보고 싶습니다. WinUI는 OSS이고 VS Code도 마찬가지이므로 이것이 가능하다고 생각합니다.

WSLUser 에 2019년 10월 24일

Template10 및 Windows Template Studio와 같은 도구는 기본 기능이 부족하다는 신호입니다. WinUI3에는 이러한 도구가 수행하는 기능이 있어야 합니다. 나는 많은 개발자들이 이 기본 스캐폴딩을 계속해서 하고 있다고 확신합니다. 이것은 프레임워크의 일부여야 합니다. 추가 도구가 필요하지 않습니다. 어쩌면 당신이 원하지 않는 드문 경우를 위해 MVVM 스캐폴딩을 꺼야 할 수도 있습니다.

ASPNET Core로 일부 작업을 수행한 후 종속성 주입이 누락되었습니다. 이 기능은 기본적으로 ASPNET Core에 있습니다. 추가 작업 없이 작동합니다. 원하는 경우 서비스를 쉽게 추가하거나 수정할 수 있습니다. 그러나 오늘날 UWP의 경우 이를 직접 구축하거나 WTS와 같은 것을 사용하여 시작해야 하지만 나중에는 여전히 붙어 있는 것처럼 느껴집니다. 적절한 네이티브 종속성 주입이 포함된 WinUI3는 매우 유용할 것입니다.

xiler8 에 2019년 10월 25일

템플릿 시스템의 존재가 기본 기능의 부족을 나타낸다고 생각하지 않으며, 템플릿 시스템을 통합할 지원 커뮤니티의 품질을 강조한다고 생각합니다.

sharpninja 에 2019년 10월 25일

Template10 및 Windows Template Studio와 같은 도구는 기본 기능이 부족하다는 신호입니다.

나는 이것을 기본 기능의 확장이라고 봅니다. 물론 이와 같은 것을 집으로 가져올 수도 있지만 핵심 팀이 유지 관리하고 지원하는 것이 더 중요합니다. 핵심 팀이 더 많은 일을 할수록 더 얇게 퍼져 모든 것이 더 오래 걸린다는 것을 의미하는 경향이 있습니다. Msft가 이와 같은 것을 메인 팀으로 가져올 예산이 있다고 생각한다면 누군가와 이에 대해 이야기하고 싶습니다. ;)

mrlacey 에 2019년 10월 25일

기본 제공 스타일 및 컨트롤에 대한 사용자 지정 동작을 더 쉽게 추가할 수 있도록 하는 것과 같이 단순화된 스타일 및 컨트롤 템플릿에 대한 몇 가지 생각입니다. 완벽한 예는 Button 스타일 지정입니다. 호버 색상을 변경하거나 테두리 반경을 사용하기 위해 전체 컨트롤 템플릿을 재정의해야 할 때입니다. css 와 같이 일부를 직접 설정하면 킬로미터의 XAML 코드가 생성되지 않습니다.

AntiPasha 에 2019년 11월 03일

@AntiPasha 라이트 웨이트 스타일링 들어보셨나요? 이를 통해 전체 스타일을 다시 만들 필요 없이 호버 색상을 쉽게 변경할 수 있습니다.

버튼의 호버 색상을 변경하면 다음과 같습니다.

Felix-Dev 에 2019년 11월 03일

👍2

흥미롭게도 XAML 도구가 통합되면 일종의 공유 xaml 파일을 만들 수 있습니까?
다음과 같은 것:
<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>
특별한 루트 네임스페이스가 있는 일종의 공유 방언이어야 합니까? (예: Visual Studio의 공유 프로젝트). 조건부 xaml처럼 보일 수 있습니다.

@Tirraon 이것은 정말 흥미로운 예이지만 도구 통합에 대해 이야기할 때 플랫폼이 오늘날과 같이 존재할 것이라는 사고 방식에서 시작하는 것이 더 낫다고 생각합니다. 우리는 또 다른 Xaml 표준을 만들려고 하지 않습니다. 동등한.

기본 네임스페이스를 사용하여 xaml 파일이 속한 "최상위" 플랫폼을 구별할 수 있습니다. 예를 들어 각 XAML 플랫폼에 대해 다음과 같은 기본 네임스페이스를 가질 수 있습니다. 😄 ):

wpf: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
uwp: xmlns="http://github.com/microsoft/microsoft-ui-xaml"
아발로니아: xmlns="https://github.com/AvaloniaUI/AvaloniaUI"
우노: xmlns="https://github.com/unoplatform/uno"
xamarin.forms: xmlns="https://github.com/xamarin/Xamarin.Forms"

따라서 Xaml Islands를 사용하여 WinUI와 WPF를 혼합하려면 다음과 같은 마크업이 있어야 합니다.

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
                       xmlns:uwp="http://github.com/microsoft/microsoft-ui-xaml">
   <StackPanel>
     <uwp:Button Content="Hi, UWP!" x:Name="uwpButton">
     <Button Content="Hi, WPF!" Width="{x:Bind uwpButton.Width}" />
   </StackPanel>

</UserControl>

어떻게 생각하나요?

stevenbrix 에 2019년 11월 05일

@stevenbrix
UWP에 대한 예제에서는 두 버튼을 모두 렌더링합니다. 그렇지 않습니까?
내 말은, 예를 들어 xmlns=".../xaml/presentation"이 최상위 네임스페이스이고 UserControl wutg StackPanel이 uwp와 wpf에서 모두 사용 가능한 경우 두 플랫폼 모두에서 두 번째 Button을 사용할 수 있지 않을까요?

도구 통합에 대해 이야기할 때 플랫폼이 오늘날과 같이 존재할 것이라는 사고 방식에서 시작하는 것이 좋습니다.

네, 전적으로 동의합니다.

maxkatz6 에 2019년 11월 07일

UWP에 대한 예제에서는 두 버튼을 모두 렌더링합니다. 그렇지 않습니까?
내 말은, 예를 들어 xmlns=".../xaml/presentation"이 최상위 네임스페이스이고 UserControl wutg StackPanel이 uwp와 wpf에서 모두 사용 가능한 경우 두 플랫폼 모두에서 두 번째 Button을 사용할 수 있지 않을까요?

@Tirraon , 내가 제공한 예제는 순전히 Xaml Islands를 사용하여 응용 프로그램을 점진적으로 현대화하는 WPF 응용 프로그램에 대한 것입니다. WPF와 WinUI 응용 프로그램 간에 사용되는 "표준" 마크업을 위한 것이 아닙니다.

현재 Xaml Islands를 사용하려는 앱 작성자는 모든 섬에 대한 사용자 컨트롤을 만들어야 합니다. 그런 다음 WPF 태그에 WinUI 요소를 자연스럽게 포함하는 대신 WPF 태그의 문자열을 통해 형식을 참조합니다.

나는 지금 전화를 받고 있지만, 일단 내 PC 근처에 있으면 내가 제안하는 것의 전후를 더 구체적으로 알 수 있습니다.

stevenbrix 에 2019년 11월 07일

@stevenbrix
오, 이제 당신을 얻었습니다. 감사합니다.

maxkatz6 에 2019년 11월 07일

@stevenbrix
오, 이제 당신을 얻었습니다. 감사합니다.

@티라온 대단해! 우리가 같은 페이지에 있어서 기쁩니다 ☺️

제 아이디어가 의외의 것 같다면 죄송합니다. 우리는 Xaml Island 시나리오를 개선하기 위한 목표로 잠재적으로 도구를 통합할 수 있는 방법에 대해 초기에 논의했습니다. 그런 것에 가치가 있다고 생각합니까?

FWIW, 나는 당신이 제안한 것과 같은 것에 확실히 장점이 있다고 생각합니다. 그러나 저는 WinUI3/.NET5 기간 내에 완료할 수 있는 것에 집중하려고 합니다.

stevenbrix 에 2019년 11월 07일

출력을 기본 캔버스로 변환하고 기본 메시지 시스템에서 입력을 수신하는 일부 파이프라인에 WinUI Xaml을 렌더링하는 방법을 알아보세요. WinUi.Adapters.DirectX, WinUI.Adapters.WASM, WinUi.Adapters.X, WinUi.Adapters.Android와 같습니다.

시작 시 모든 어댑터를 구현할 필요는 없으며 Windows 10을 지원하는 데 필요한 어댑터만 구현하면 됩니다.

보낸 사람: Steven Kirbach [email protected]
보낸 날짜: 2019년 11월 7일 목요일 오전 9:13:46
받는 사람: microsoft/microsoft-ui-xaml [email protected]
참조: 더 샤프 닌자 [email protected] ; 댓글 [email protected]
제목: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 개발자 경험 및 도구 - 입력 필요(#1045)

@stevenbrix https://github.com/stevenbrix
오, 이제 당신을 얻었습니다. 감사합니다.

@Tirraon https://github.com/Tirraon 훌륭합니다! 우리가 같은 페이지에 있어서 기쁩니다 ☺️

제 아이디어가 의외의 것 같다면 죄송합니다. 우리는 Xaml Island 시나리오를 개선하기 위한 목표로 잠재적으로 도구를 통합할 수 있는 방법에 대해 초기에 논의했습니다. 그런 것에 가치가 있다고 생각합니까?

FWIW, 나는 당신이 제안한 것과 같은 것에 확실히 장점이 있다고 생각합니다. 그러나 저는 WinUI3/.NET5 기간 내에 완료할 수 있는 것에 집중하려고 합니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
GitHub의에 그것을 직접이 이메일에 회신 볼 https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLBHRGZTDFHFWQTAFK3QSQWCVA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMXFLY#issuecomment-551121583 , 또는 탈퇴 https://github.com/ 알림/구독 취소-인증/AD3GCLF2BUTXQFPSVNULZODQSQWCVANCNFSM4ICOLUJQ .

sharpninja 에 2019년 11월 07일

예, XAML Island 시나리오는 현재 끔찍합니다.

sylveon 에 2019년 11월 07일

👍1

@sharpninja
우노를 봐야한다
https://platform.uno/
또한 모든 플랫폼에 대해 WinUI 3.0을 지원할 예정입니다.
https://platform.uno/winui-on-windows7-via-unoplatform/

@stevenbrix
저는 Xaml Islands에 대한 경험이 거의 없으며 일반적으로 일반 UWP로 작업합니다. 그러나 나는 확실히 더 가까이에서 볼 필요가 있습니다.
내 제안은 Xaml Islands 자체와 관련이 없었지만 일반적으로 하나 이상의 플랫폼에서 작동하기 때문에 WinUI와 더 관련이 있습니다.

maxkatz6 에 2019년 11월 07일

내 제안은 Xaml Islands 자체와 관련이 없었지만 일반적으로 하나 이상의 플랫폼에서 작동하기 때문에 WinUI와 더 관련이 있습니다.

@Tirraon , 그래 완전히 이해하고 머리가 있는 곳이 절대적으로 좋아 🙌

나는 당신이 제안하는 것에 대해 @jeromelaban 및 회사와 간단히 이야기했으며 확실히 관심이 있습니다. 아직 논의의 초기 단계에 있기 때문에 구체적인 계획이나 약속은 아직 없습니다. 이러한 종류의 입력은 훌륭하며 고객에게 제공하는 가치를 더 잘 이해하는 데 도움이 됩니다. 😄

stevenbrix 에 2019년 11월 07일

👍1

XAML 아일랜드 시나리오는 C++ 시나리오를 의미합니다. 내가 직면한 문제 목록은 이 스레드의 이전 메시지를 참조하세요.

sylveon 에 2019년 11월 07일

예, XAML Island 시나리오는 현재 끔찍합니다.

XAML 아일랜드 시나리오는 C++ 시나리오를 의미합니다. 내가 직면한 문제 목록은 이 스레드의 이전 메시지를 참조하세요.

@sylveon 귀하의 의견(아래 링크)을 보고 있습니다. 예, 꽤 끔찍하게 들립니다. 불편을 끼쳐 드려 죄송합니다. 개선할 것이라고 확신합니다.
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -512945553
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -513505038

당신이 겪고 있는 많은 고통은 프로젝트 시스템과 관련이 있으며 많은 사람들의 관심을 받고 있다는 것을 압니다. 우리 팀 구성원 중 일부가 XAML 도구에 대해 수행한 이 비디오를 본 적이 있습니까? 해당 링크는 @michael-hawker 및 @marb2000 이 새로운 Xaml Island 환경으로

Xaml Island의 경험을 쉽고 자연스럽게 사용하기 위해 필요한 많은 것들이 있습니다. 내가 언급하는 측면은 현재 WPF에 UWP 콘텐츠 섬을 포함하는 방식이 다음과 같다는 것입니다(위 비디오에서).

  <Grid>
   <xi:WindowsXamlHost InitialTypeName="UWP_XamlApplication.SamplePage"/>
  </Grid>

나는 우리가 그보다 더 잘할 수 있고 다음과 같은 것을 제공할 수 있다고 생각합니다.

  <Grid>
   <uwp:SamplePage />
  </Grid>

stevenbrix 에 2019년 11월 07일

@stevenbrix

나는 당신이 제안하는 것에 대해 @jeromelaban 및 회사와 간단히 이야기했으며 확실히 관심이 있습니다. 아직 논의의 초기 단계에 있기 때문에 구체적인 계획이나 약속은 아직 없습니다. 이러한 종류의 입력은 훌륭하며 고객에게 제공하는 가치를 더 잘 이해하는 데 도움이 됩니다.

너무 많은 관심이 있습니다! (이 대화는 어디에서나 나타납니다.) WinUI 포스트 3.0이 플랫폼 간 구현으로 전환된다면 개발자 지원이 많이 필요할 것입니다. #1461에 대한 토론을 보십시오. 단기적으로는 Uno Platform 기술을 사용하여 XAML/C#을 HTML/WASM으로 변환하여 모든 플랫폼에서 UWP 앱을 실행하는 것은 놀라운 일이 될 것입니다. 장기적으로 저는 Electron 또는 브라우저에서 실행하는 것이 성능에 미치는 영향에 대해 우려하고 있으며 보다 효율적인 아키텍처를 위한 여지가 있습니다.

결론적으로, 나는 모두가 현재 WinUI 3.0으로 바쁘다는 것을 알고 있습니다. 하지만 작업이 끝나면 @jeromelaban , @marb2000 , @jevansaks 및 기타 사용자를 연결하여 UWP를 모든 곳에서 렌더링할 수 있는 가장 좋은 방법을 알아내는 것이 좋습니다. 그것은 또한 향후 호출에 대한 매우 흥미로운 커뮤니티 토론이 될 것입니다.

robloo 에 2019년 11월 07일

🚀1

WinUi는 네오와 듀오가 모두 살아남을 수 있는 유일한 제정신의 길입니다.

보낸 사람: roblo [email protected]
보낸 날짜: 2019년 11월 7일 목요일 오후 12:00:07
받는 사람: microsoft/microsoft-ui-xaml [email protected]
참조: 더 샤프 닌자 [email protected] ; 멘션 @noreply.github.com
제목: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 개발자 경험 및 도구 - 입력 필요(#1045)

@stevenbrix https://github.com/stevenbrix

나는 @jeromelaban https://github.com/jeromelaban 및 회사와 정확히 당신이 제안하는 것에 대해 간략하게 이야기했으며 확실히 관심이 있습니다. 아직 논의의 초기 단계에 있기 때문에 구체적인 계획이나 약속은 아직 없습니다. 이러한 종류의 입력은 훌륭하며 고객에게 제공하는 가치를 더 잘 이해하는 데 도움이 됩니다.

너무 많은 관심이 있습니다! (이 대화는 어디에서나 나타납니다.) WinUI 포스트 3.0이 플랫폼 간 구현으로 전환된다면 개발자 지원이 많이 필요할 것입니다. #1461 https://github.com/microsoft/microsoft-ui-xaml/issues/1461 에서 토론을 보십시오. 단기적으로는 Uno Platform 기술을 사용하여 XAML/C#을 HTML/WASM으로 변환하여 모든 플랫폼에서 UWP 앱을 실행하는 것은 놀라운 일이 될 것입니다. 장기적으로 저는 Electron 또는 브라우저에서 실행하는 것이 성능에 미치는 영향에 대해 우려하고 있으며 보다 효율적인 아키텍처를 위한 여지가 있습니다.

결론적으로, 나는 모두가 현재 WinUI 3.0으로 바쁘다는 것을 알고 있습니다. 그러나 그것이 끝나면 @jeromelaban https://github.com/jeromelaban , @marb2000 https://github.com/marb2000 , @jevansaks https://github.com/jevansaks 및 기타를 연결하면 좋을 것입니다. UWP가 모든 곳에서 렌더링되도록 하는 가장 좋은 방법을 알아보세요. 그것은 또한 향후 호출에 대한 매우 흥미로운 커뮤니티 토론이 될 것입니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
GitHub의에 그것을 직접이 이메일에 회신 볼 https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLCHIRMGIIB4EEMXQATQSRJSPA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDNI2QA#issuecomment-551193920 , 또는 탈퇴 https://github.com/ 알림/구독 취소-인증/AD3GCLCAZIOGVET6CJKLKLTQSRJSPANCNFSM4ICOLUJQ .

sharpninja 에 2019년 11월 07일

🚀2 ❤1 👍1

WinUi는 네오와 듀오가 모두 살아남을 수 있는 유일한 제정신의 길입니다.

동의하는 경향이 있지만 Android 및 Surface Duo에서 실행되는 Windows 앱에서 동일한 UI를 가져옵니다. 개발자의 최소한의 개입으로 - 그것이 성배입니다.

WinUI가 주요 개발 플랫폼이 될 가능성이 있고 Windows가 장기적으로 다른 플랫폼의 앱을 수용할 수 있는 기회를 제공한다면. (큰 확립된 앱의 경우 항상 나쁜 것은 아니지만 LoB 및 다음 큰 앱의 경우...)

mdtauk 에 2019년 11월 07일

내 자신의 응용 프로그램 지향 언어를 만들고 있으며 XAML과 함께 WinUI 사용을 지원하고 코드 숨김용 언어를 지원하려고 합니다. 도구가 XAML용 코드 생성을 제공하는 언어 기능을 제공한다면 좋을 것입니다. XAML 코드 생성기가 모든 언어를 사용하여 완료할 수 있는 부분 클래스로 IL을 빌드했다면 더 좋을 것입니다. 이는 코드 생성기가 컴파일 가능한 IL 어셈블리를 출력한다는 것을 의미합니다.

sharpninja 에 2019년 11월 15일

내 자신의 응용 프로그램 지향 언어를 만들고 있으며 XAML과 함께 WinUI 사용을 지원하고 코드 숨김용 언어를 지원하려고 합니다. 도구가 XAML용 코드 생성을 제공하는 언어 기능을 제공한다면 좋을 것입니다. XAML 코드 생성기가 모든 언어를 사용하여 완료할 수 있는 부분 클래스로 IL을 빌드했다면 더 좋을 것입니다. 이는 코드 생성기가 컴파일 가능한 IL 어셈블리를 출력한다는 것을 의미합니다.

XAML Direct가 있지만 현재 C# 및 C++에서 지원합니다.
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

mdtauk 에 2019년 11월 15일

내 말은 그게 아니야. 코드 생성 도구의 출력이 C# 또는 C++가 아닌 IL이라는 의미입니다. 그렇게 하면 내 컴파일러가 XAML을 IL로 변환한 다음 해당 클래스를 상속할 수 있습니다.

sharpninja 에 2019년 11월 15일

@sharpninja C++ 코드 대신 LLVM 바이트코드도 생성할 수 있다면 유익할 것입니다.

그렇게 하면 MIDL 및 XLang과 결합하여 모든 XLang 지원 시나리오에서 사용할 COM 라이브러리 및 WinMD 파일을 생성할 수 있습니다.

Nirmal4G 에 2019년 11월 16일

C++ 모자를 쓰고 C++용 WinUI 도구와 관련하여 보고 싶은 것은 Microsoft가 마침내 90년대 중반부터 C++ Builder가 해온 일을 따라잡는 것입니다.

C++ 기반 개발을 위한 실제 RAD 도구를 제공합니다.

양식에는 몇 가지 해결 방법이 있었지만 C++/CLI는 이에 미치지 못했습니다.

C++/CX는 그렇게 될 것 같았지만 여전히 C++ 빌더가 할 수 있는 것보다 더 많은 노력이 필요했습니다.

이제 C++/WinRT는 표준 C++17이 될 수 있지만 데스크톱 개발자의 전반적인 경험은 수동으로 작성해야 하는 상용구의 증가, COM 유형이 ABI 경계를 넘는 방법 및 디자이너 부족으로 인해 다운그레이드처럼 느껴집니다. 지원하다.

그래서 나는 MIDL 컴파일러와 COM ABI 지원에 필요한 모든 상용구를 다룰 생각이 없기 때문에 당분간 여전히 C++/CX를 사용하고 있습니다.

반면에 .NET 모자를 쓴 상태에서 DirectX와 같은 C++ 전용 라이브러리가 마침내 WinUI 구성 요소로 노출되는 것을 보고 싶습니다. 일부 Blend는 사랑하고 F#도 Microsoft의 .NET 언어라는 것을 기억하고 있습니다.

pjmlp 에 2020년 01월 27일

👍3 ❤2 🚀1

WinUI로 전환하는 데 상당한 어려움을 겪었습니다. 현재 WinUI를 사용하지 않는 자사 및 타사 라이브러리가 많이 있으며 이에 대한 종속성이 문제가 됩니다. 예를 들어 행동 SDK.

MikeKenyon 에 2020년 02월 17일

UWP Community Discord에서 StatusBar에 대해 이야기하다가 든 생각입니다..

Visual Studio에서 도구 상자에 UWP에서 누락된 WPF 컨트롤에 대한 항목이 포함되도록 하고 해당 항목이 선택되면 기존 컨트롤을 시뮬레이션하는 방법을 설명하는 팝업을 표시합니다.

이 아이디어는 WPF(또는 다른 프레임워크)에서 오는 사람들이 특정 컨트롤을 볼 것으로 예상하고 이러한 컨트롤을 찾지 못하는 것이 불편한 경험이 될 수 있는 사람들을 위해 전환을 용이하게 하려는 바람에서 비롯되었습니다. CommandBar가 StatusBar처럼 사용될 수 있다는 것을 어떻게 알 수 있습니까? 사람들이 WinUI로 이동할 수 있도록 최대한 간단하게 만들어야 한다고 생각합니다. 이것은 누락된 모든 컨트롤을 실제로 개발하지 않고도 일부 공백을 채우는 역할을 할 수 있습니다.

편집하다:
그리고 완성도를 위해 상태 표시줄에 대해 언급한 다른 내용이 있습니다. UWP(또는 WinUI)에 익숙하지 않은 사용자가 UWP(또는 WinUI)에 접근하는 방법을 보여줍니다.

Re: StatusBar - UWP를 시도하는 기존 프레임워크 사용자의 관점에서 생각하고 있었는데 StatusBar가 없는 것을 확인했습니다. 여전히 많은 앱에서 필수 요소입니다. 예, CommandBar가 더 나을 수 있습니다. 그러나 사람들은 CommandBar가 무엇인지 모르거나 다른 것으로 추측할 수 있습니다. 위의 누군가는 내가 그리드를 추가하고 맨 아래에 놓고 한 행 높이로 만들고 다양한 컨트롤을 추가하여 표시할 것을 제안했습니다. 그래서 기존 Xaml 디자이너들도 CommandBar에 대해 모르는 것 같습니다. 어쨌든 당신이 맞을 수도 있고 CommandBar가 더 나을 수도 있지만 Paul Thurrot은 UWP 메모장 앱에서 이를 사용하지 않고 그리드를 사용했습니다. 따라서 CommandBar가 StatusBar의 대체품으로 전달되지 않는 것 같습니다. 캐주얼(또는 신규) 개발자는 여전히 StatusBar를 찾고 있지만 찾지 못하고 있습니다. Paul Thurrot이 개발자가 아니라는 것을 알고 있지만 제 요점은 이해합니다.

Gavin-Williams 에 2020년 02월 19일

👍3

스니펫이 일반적인 사용 사례에서도 xaml에 주입된다면 좋을 것입니다.

보낸 사람: Gavin-Williams [email protected]
보낸 날짜: 2020년 2월 18일 화요일 오후 7:05:39
받는 사람: microsoft/microsoft-ui-xaml [email protected]
참조: 더 샤프 닌자 [email protected] ; 멘션 @noreply.github.com
제목: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 개발자 경험 및 도구 - 입력 필요(#1045)

UWP Community Discord에서 StatusBar에 대해 이야기하다가 든 생각입니다..

Visual Studio에서 도구 상자에 UWP에서 누락된 WPF 컨트롤에 대한 항목이 포함되도록 하고 해당 항목이 선택되면 기존 컨트롤을 시뮬레이션하는 방법을 설명하는 팝업을 표시합니다.

이 아이디어는 WPF(또는 다른 프레임워크)에서 오는 사람들이 특정 컨트롤을 볼 것으로 예상하고 이러한 컨트롤을 찾지 못하는 것이 불편한 경험이 될 수 있는 사람들을 위해 전환을 용이하게 하려는 바람에서 비롯되었습니다. CommandBar가 StatusBar처럼 사용될 수 있다는 것을 어떻게 알 수 있습니까? 사람들이 WinUI로 이동할 수 있도록 최대한 간단하게 만들어야 한다고 생각합니다. 이것은 누락된 모든 컨트롤을 실제로 개발하지 않고도 일부 공백을 채우는 역할을 할 수 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
GitHub의에 그것을 직접이 이메일에 회신 볼 https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLGYERSFO7LBXKWBBRDRDSAWHA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMF6O3Y#issuecomment-587982703 , 또는 탈퇴 https://github.com/ 알림/구독 취소-인증/AD3GCLFLGA773XOS5OSG5ULRDSAWHANCNFSM4ICOLUJQ .

sharpninja 에 2020년 02월 19일

개발자 스토리에는 일종의 비교 목록이 포함되어야 합니다.

Win32 앱에 고유한 개념이므로 상태 표시줄, 도구 모음, 메뉴, 그리퍼, 탭 등이 한 목록에 있고 WinUI는 다른 목록에 있습니다.

기존 앱의 UI를 WinUI로 이동할 수 있는 방법을 보여주기 위해 둘 다의 코드 샘플을 포함하는 페이지 자체.

mdtauk 에 2020년 02월 19일

👍6

열린 질문
1-3단계를 자동화하는 마이그레이션 도구를 제공하면 도움이 될까요?
예. 저는 1개의 "레거시" Windows Forms 앱(레거시란 다시 작성할 예산이 없음을 의미함)과 2개 또는 3개의 레거시 WPF 앱을 지원합니다. WinForms 앱은 문제가 될 수 있지만 WPF 앱을 WinUI 3으로 신속하게 이식하는 데 도움이 되는 도구는 훌륭할 것입니다!

MSIX는 모든 앱에 대한 최신 패키징 방법입니다. Win32의 WinUI의 경우 ClickOnce를 지원해야 합니까? 어떤 다른 패키징 방법에 대한 지원을 포함해야 합니까? 특히 Win32의 WinUI의 경우

현재 ClickOnce를 사용하여 사용자의 데스크톱에 앱을 게시합니다. 자동 업데이트의 일부 모델은 여전히 필요합니다.

JeffSchwandt 에 2020년 03월 17일

@JeffSchwandt

이러한 단계는 이전 버전(1-2)을 사용하는 WinUI 프로젝트를 버전 3으로 변환하는 것과 관련된 것입니다.

WPF 앱을 WinUI 앱으로 변환하는 것은 자동화된 방식으로 특히 실현 가능하지 않습니다(많은 노력 없이도 오류가 발생하기 쉽습니다).

kmgallahan 에 2020년 03월 17일

이 스레드가 이 요청을 게시하는 데 적합하기를 바랍니다.

Rust는 현재 적절한 UI 프레임워크가 절실히 필요합니다. WinUI가 향후 네이티브 SDK와 일부 도구로 Rust를 지원할 수 있다면 좋을 것입니다.

Alovchin91 에 2020년 03월 20일

👍1

이 스레드가 이 요청을 게시하는 데 적합하기를 바랍니다.
Rust는 현재 적절한 UI 프레임워크가 절실히 필요합니다. WinUI가 향후 네이티브 SDK와 일부 도구로 Rust를 지원할 수 있다면 좋을 것입니다.

좋은 소식입니다. Rust/WinRT는 Rust 앱에서 WinUI와 같은 WinRT API를 사용할 수 있도록 개발 중입니다! https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/을 살펴보십시오.

jevansaks 에 2020년 03월 20일

@jevansaks 헤이, 응답 주셔서 감사합니다! 예, Kenny가 Rust/WinRT에서 작동한다는 것을 알고 있지만 WinRT가 WinUI에서 지원하는 유일한 API 계층인지 궁금합니다. 데스크톱 앱의 WinRT API 사용이 Windows 10 1903에서만 사용할 수 있게 된 반면 WinUI는 이전 버전의 Windows 10을 지원하는 것을 목표로 한다는 사실과 이것이 어떻게 맞는지 잘 모르겠습니다.

Alovchin91 에 2020년 03월 20일

Rust/WinRT(C++/WinRT와 같은)는 Windows 7까지 작동해야 합니다. WinRT 자체는 항상 데스크톱/win32 앱에서 작동했습니다. store/uwp/packaging 요구 사항이 있는 특정 API만 있습니다(WinRT 전체가 아님). WinUI에 이러한 요구 사항이 없는 한 지원되는 모든 플랫폼에서 C++/WinRT 및 Rust/WinRT를 통해 데스크톱 앱에서 WinUI를 사용할 수 있습니다.

kennykerr 에 2020년 03월 20일

👍2

WinUI 데스크톱 앱은 라이브 타일 및 타일 업데이트를 지원해야 합니다. 여기에는 현재 UWP 앱보다 쉽게 타일을 생성할 수 있는 간단한 샘플과 SDK 도구가 포함되어 있습니다.

mdtauk 에 2020년 03월 20일

데스크톱 앱의 WinRT API 사용이 Windows 10 1903에서만 사용할 수 있게 되었다는 사실과 이것이 어떻게 맞는지 잘 모르겠습니다.

WinUI Desktop은 현재 WinUI 3.0용으로 설계 중이며 일반 Win32 앱에서 WinUI 하위 수준을 사용할 수 있어야 합니다(현재 계획은 1803까지임).

jevansaks 에 2020년 03월 20일

Windows UI는 최소한 주요 MVVM 프레임워크인 MVVM Light, Prism 및 Caliburn을 지원해야 합니다. 불행히도 INotifyPropertyChanged 및 INotifyCollectionChanged가 ObservableCollection을 깨는 변경 사항에 대한 문서화된 문제확실히 MVVM Light와 다른 두 프레임워크도 깨뜨립니다. 당신이 알아야 한다고 생각했습니다.

terrycox 에 2020년 03월 25일

👍4

불행히도, ObservableCollection을 깨는 INotifyPropertyChanged 및 INotifyCollectionChanged 변경에 대한 문서화된 문제는 확실히 MVVM Light와 다른 두 프레임워크도 손상시킵니다. 당신이 알아야 한다고 생각했습니다.

@terrycox 감사합니다! 우리는 이 문제가 WinUI 3.0 RTM에 의해 해결될 것임을 알고 있으며 그 이전에 미리보기 빌드에서 이상적으로는 ;)

stevenbrix 에 2020년 03월 25일

👍4

@terrycox Windows UI는 최소한 주요 MVVM 프레임워크인 MVVM Light, Prism 및 Caliburn을 지원해야 합니다. ... 문서화된 문제

예, 문서화된 문제를 수정해야 하지만 MVVM 프레임워크를 지원하기 위해 WinUI를 포함한 .Net UI 라이브러리가 필요하지 않습니다. UI 요소를 나타내는 개체만 지원하면 됩니다. .Net MVVM 또는 반응 프레임워크는 데이터를 나타내는 개체를 기반으로 UI를 나타내는 .Net 개체를 생성하고 변경하는 방법입니다. 어느 쪽도 상대방에 대해 알 필요가 없습니다. 모든 프레임워크는 모든 UI 라이브러리와 결합될 수 있습니다.

charlesroddie 에 2020년 03월 25일

그러나 MVVM 프레임워크를 지원하기 위해 WinUI를 포함한 .Net UI 라이브러리가 필요하지 않습니다.

그러나 UIElements가 인식하고 있는 이벤트 및 인터페이스와 같은 것들은 필요하며 그것이 고장난 것입니다.

보낸 사람: Charles Roddie [email protected]
보냄: 2020년 3월 25일 수요일 오후 2:28:46
받는 사람: microsoft/microsoft-ui-xaml [email protected]
참조: 더 샤프 닌자 [email protected] ; 멘션 @noreply.github.com
제목: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 개발자 경험 및 도구 - 입력 필요(#1045)

@terrycox https://github.com/terrycox Windows UI는 최소한 주요 MVVM 프레임워크인 MVVM Light, Prism 및 Caliburn을 지원해야 합니다. ... 문서화된 문제

예, 문서화된 문제를 수정해야 하지만 MVVM 프레임워크를 지원하기 위해 WinUI를 포함한 .Net UI 라이브러리가 필요하지 않습니다. UI 요소를 나타내는 개체만 지원하면 됩니다. .Net MVVM 또는 반응 프레임워크는 데이터를 나타내는 개체를 기반으로 UI를 나타내는 .Net 개체를 생성하고 변경하는 방법입니다. 어느 쪽도 상대방에 대해 알 필요가 없습니다. 모든 프레임워크는 모든 UI 라이브러리와 결합될 수 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 회신하거나 GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-604040104 에서 확인하거나 https://github.com/notifications/unsubscribe-auth/를 구독 취소합니다.

sharpninja 에 2020년 03월 25일

Dotnet cli 도구는 다음과 함께 사용해야 합니다. 넷코어 SDK
dotnet new 및 dotnet build와 같은 명령으로 충분해야 하며 Visual Studio 설치에 대한 하드 종속성이 없습니다. .Net Core 시대에 완전히 참여하십시오!

JensNordenbro 에 2020년 04월 21일

👍3 🎉1

xaml 디자이너가 빠르면 좋을 것입니다. 현재 XAML 디자이너는 느리고 항상 일부 예외가 발생하여 작동하지 않는다는 오류가 발생합니다. 이를 수정하고 강력한 디자이너를 제공하십시오.
현재 uwp에는 잠금 화면을 감지할 수 있는 API가 없습니다. 잠금 화면을 감지하고 부울 값을 반환 값으로 제공할 수 있는 API가 제공되면 좋을 것입니다. 잠그거나 잠금 해제한 후에도 일부 애니메이션과 배지를 표시할 수 있어야 합니다.
- 기존 잠금화면 API
내 문제 설명

rahulkps23 에 2020년 04월 27일

👍1

@JensNordenbro 의 의견에 따르면 이것이 Vs Code에서만 작동할 가능성이 있습니까?

Neurrone 에 2020년 05월 13일

👍1

.NET 5 저장소 호스트 응용 프로그램을 참조하는 WinUI 3.0 UI로 .NET 5 응용 프로그램을 만드는 응용 프로그램 템플릿을 보고 싶습니다. 이렇게 하면 .NET 5.0의 중복 설치를 줄일 수 있습니다.

lmcdougald 에 2020년 05월 18일

👍3 🚀1

WinUI 데스크톱 응용 프로그램에서 muxc.Window.ThisPtr에서 hWnd로, 기본 Win32 창으로 어떻게 이동합니까?

mqudsi 에 2020년 05월 29일

이 아이디어가 마음에 들어서 데스크톱용 WinUI 3 Preview 1용 새 2020년 5월 템플릿을 사용해 보았습니다.

하지만 한 가지 질문이 있습니다. Windows의 기본 UI 플랫폼이 되는 WinUI를 사용하여 실제로 Windows 10의 일부가 되도록 하는 통신 부족에 놀랐습니까?

내 결과 Hello World 앱의 크기는 약 120MB였습니다. 물론, 공간은 저렴하지만 여기에는 나 자신에 대한 의존성이 없었습니다. 이 중 WinUI는 포함된 .NET 5 자체만큼 많은 공간을 소비했습니다. x64 빌드에만 해당됩니다. 다중 플랫폼 패키지에 x86을 포함하고 그 크기를 두 배로 늘리십시오. 몇 가지 다른 종속성을 추가하면 배포용으로 패키징할 300MB 앱을 쉽게 찾을 수 있습니다.

WinUI 3가 .NET 5의 Windows 버전에 포함되지 않는 이유는 무엇입니까? .NET Core 모듈화 노력의 일부입니까? 그러나 그렇지 않다면 어디에 해당합니까? 정말 모든 앱의 폴더가 은밀한가요? 공식 Windows 10 사용자 인터페이스로...?

아니면 미래에 Windows 10의 일부가 될까요? WinUI가 시스템 라이브러리처럼 취급되고 .NET 5가 나중에 Windows와 함께 제공되기 시작한다면 우리는 대신 비교적 작은 앱을 보게 될 것입니다. 그러나 이것이 적어도 Windows 10X에 대한 이야기이고 나중에 Windows 10 non-X에 대한 이야기가 되기를 바랍니다. 이 두 라이브러리와 Windows 10 SDK C#/WinRT 브리지 DLL을 제외하면 앱 크기는 1-5MB로 급감합니다.

jonasnordlund 에 2020년 06월 04일

@ryandemopoulos 는 Discord에서 WinUI가 프레임워크 패키지로 제공될 것이며 배포를 위해 Store 또는 MSIX를 사용하는 앱은 모두 동일한 복사본을 공유하기 때문에 자체 버전의 WinUI를 보유할 필요가 없다고 말했습니다.

WinUI를 Windows 자체의 일부로 만드는 것은 WinUI가 OS에서 분리되는 지점을 무효화합니다.

sylveon 에 2020년 06월 04일

👍2

"앱의 크기가 아닌 안정적으로 사용 가능"이 관심사입니다. .NET 5가 비슷하게 배포되기를 바랍니다.

lmcdougald 에 2020년 06월 05일

@lmcdougald .NET Core Installer 에서 문제를 열고 서비스를 위해 .NET 5에서도 Framework Packaging을 사용하도록 요청합니다.

marb2000 에 2020년 06월 05일

@jonasnordlund WinRT 런타임 배포에 대해 이야기하는 또 다른 토론 #2500이 있습니다. 아마도 거기에서 답을 찾을 수 있을 것입니다. :)

marb2000 에 2020년 06월 05일

@marb2000 이슈를 열 스럽네요 . 이것이 Windows 10X를 제공하는 모든 앱에 필수적인 것으로 보이지 않습니까?

lmcdougald 에 2020년 06월 05일

다음은 몇 가지 기능을 컴파일한 것입니다. 그 중 일부는 직접 WinUI가 아니지만 이러한 기능이 없으면 UWP 클라이언트, 특히 LoB 앱 클라이언트가 포함된 모든 .NET 클라이언트 개발 환경에 직접적인 영향을 미칩니다.

저에게 최우선 순위는 당신이 Uno 플랫폼을 육성하는 것입니다. 나에게 UWP를 관련성 있게 만드는 것은 Uno가 없었다면 XF나 다른 기술에 타협했을 것입니다. (https://github.com/microsoft/microsoft-ui-xaml/issues/2024)
ViewModel에서 사용할 추상 클라이언트 측 ID 관리 API(https://github.com/microsoft/ProjectReunion/issues/31)
전체 데이터 주석 지원, 유효성 검사 및 UI 제목, 문자열 길이, 필수 속성, 읽기 전용 필드, 워터마크 등 등(https://bit.ly/3gcMJ3a)
기존 RIA 서비스에 대한 적절한 대안이 되도록 OData를 개선합니다. 예: 지원 속성 생성, 인터페이스 구현, 일반 유형, XML 문서(https://github.com/OData/odata.net/issues/1746)
WPF에서 누락된 모든 기능 가져오기
x:Bind 에는 범위 또는 중첩 바인딩과 같은 Binding 모든 기능도 있어야 합니다(https://github.com/microsoft/microsoft-ui-xaml/issues/2237).
핫 리스타트(https://github.com/microsoft/ProjectReunion/issues/44)
단순한 Hello World 템플릿 이상입니다. 사용자 로그인, MVVM, 라우팅, x-plat 프로젝트(예: Uno-Platform) 등을 수용합니다. 즉, WTS에 더 많은 권한을 부여하십시오.
도킹, 간격 등과 같은 WinForms와 같은 XAML WYSIWYG 편집기 레이아웃 기능 - 이것이 완료된 것 같습니다! ❤

weitzhandler 에 2020년 06월 05일

🚀3 😕2

편집 해 주셔서 감사합니다

WinUI 팀은 Uno 제품 팀(비 Microsoft), Xamarin Forms/MAUI 팀 및 React Native와 긴밀한 관계를 유지하고 있습니다. 우리는 그들과 적극적으로 협력하며 그들의 성공적인 미래를 기원합니다.

누락된 WPF 기능에 대해 상위 기능을 나열할 수 있습니까? WPF와 WinUI 간의 격차를 줄이는 것이 우리의 목표 중 하나입니다. 그러나 여러 릴리스가 필요합니다.

더 복잡한 템플릿에 적합합니다. Window Template Studio 는 이러한 사명을 가지고 있습니다.

marb2000 에 2020년 06월 05일

❤1

WPF #719 @weitzhandler @marb2000에 비해 WinUI가 부족한 부분을 모아보려고 문제를 만들었습니다.

mdtauk 에 2020년 06월 05일

❤5 🎉1

더 복잡한 템플릿에 적합합니다. Window Template Studio는 이러한 사명을 가지고 있습니다.

@marb2000 우리 VSIX에 Window Template Studio를 가져올 수 있습니까? 아니면 그 반대도 마찬가지일까요? 앞으로 모든 WinUI3(및 Project Reunion) 템플릿을 제공하기 위한 수단으로 Window Template Studio를 사용하시겠습니까?

stevenbrix 에 2020년 06월 05일

🚀3

더 복잡한 템플릿에 적합합니다. Window Template Studio는 이러한 사명을 가지고 있습니다.
@marb2000 우리 VSIX에 Window Template Studio를 가져올 수 있습니까? 아니면 그 반대도 마찬가지일까요? 앞으로 모든 WinUI3(및 Project Reunion) 템플릿을 제공하기 위한 수단으로 Window Template Studio를 사용하시겠습니까?

👀 @crutkas @sibille

mrlacey 에 2020년 06월 05일

❤3

C++ 및 최신 도구로 가능한 것이 무엇인지 배우기 위해 C++ Builder(VCL/FMX) 및 Qt Creator/Design studio와 함께 시간을 할애하는 것이 좋습니다.

이상적으로 WinUI는 C++로 작성된 크로스 플랫폼 GUI에 대해 오늘날 이미 이러한 제품과 유사한 도구를 제공합니다.

내가 관심을 갖는 것은 .NET 개발 경험과 C++를 사용해야 하는 유스 케이스에 대해 유사한 경험을 갖고 있다는 점입니다. 어떤 이유에서든 사용할 수 없습니다.

C++ Builder 및 QtCreator는 이러한 경험을 달성하며 .NET 개발자가 C++/WinRT 코드를 작성하는 데 며칠을 소비해야 하는 상황에 직면했을 때 집과 같은 편안함을 느낄 수 있다면 환영할 것입니다.

pjmlp 에 2020년 06월 06일

왜 .NET 개발자에 대해 이것을 만들까요? C++ XAML 경험은 좋지 않습니다. C++ 개발자든 .NET 개발자든 상관없습니다.

sylveon 에 2020년 06월 06일

데스크톱, 웹(Edge), 모바일 및 IoT에서 동일한 XAML을 실행할 수 있는 길을 열면 좋을 거라고 믿습니다.

TonyHenrique 에 2020년 06월 06일

C#, Xaml 또는 디자이너가 없는 C++ 프로젝트에서 언제 WinUI 3를 사용할 수 있습니까?
또한 WinUI 3의 C++ 코어 오픈 소싱 날짜에 대한 소식이 있습니까?

편집: 첫 번째 질문에 대한 답변을 얻은 것 같습니다. WinUI 3.0 Preview 1에 C++ WinUI 3 프로젝트 템플릿이 있는 것 같습니다.

.vsix 확장을 설치한 후 "WinUI"를 검색하고 사용 가능한 C# 또는 C++ 템플릿 중 하나를 선택하여 새 WinUI 3.0 프로젝트를 만들 수 있습니다.

wis 에 2020년 06월 07일

WinUI가 개선되었으면 하는 사용 사례는 종종 PowerShell로 작성되는 일선 IT 지원 직원을 위한 작은 GUI 기반 도구를 만드는 것입니다. Visual Studio Code에서 이러한 종류의 도구를 만들 수 있다면 좋을 것입니다. C# 기반 VSCode 개발 옵션도 훌륭한 단계가 될 것입니다. 완전한 Visual Studio는 이 경우에 다소 무겁고 복잡하게 느껴집니다.

현재 엔터프라이즈 환경에서는 다음과 같은 도구를 대신 사용하고 있습니다.

https://poshgui.com/ (웹 기반 XAML 마법사)
Sapien PowerShell Studio 2020 (독점)
관리 스크립트 편집기(ASE) (현재는 중단된 프로젝트)

일반적으로 사용되는 다른 "XAML용 Visual Studio 사용" 패턴은 다음과 같습니다.

carwyn 에 2020년 06월 14일

내 질문은 그가 5월에 질문한 @mqudsi 질문의 맥락에 있지만 아무도 응답하지 않았습니다.

In a WinUI desktop application, how does one go from muxc.Window.ThisPtr to an hWnd to the native Win32 window?

이것은 데스크톱 응용 프로그램이므로 ICoreWindowInterop을 사용할 수 없으며 new HandleRef(this, ThisPtr) 와 같은 무작위 장식을 시도했습니다. 여기서 'this'는 유형 Microsoft.UI.Xaml.Window이지만 잘못된 창 핸들에 대한 오류 번호가 계속 표시됩니다. 마침내 그 hwnd를 얻으면 더 많은 COM을 사용하여 창 스타일을 변경하고 다른 사람들과 공유하여 내가 지금 겪고 있는 고통을 느끼지 않도록 할 수 있습니다.

jtbrower 에 2020년 07월 03일

관심 있는 사람을 위해 기본 창에 대한 hWnd를 가져오는 데 사용한 빠른 접근 방식으로 경계선이 없도록 만들 수 있습니다. WindowStyle=None에 해당하는 WPF에 대한 완전한 솔루션이 여기 있습니다 .

using var process = Process.GetCurrentProcess();
var hWnd = process.MainWindowHandle;

현재로서는 WinUI가 데스크탑 프로세스에 있을 때 hWnd를 얻는 방법을 찾기/문서화하기가 쉽지 않은 것 같습니다. 그래서 제가 사용한 접근 방식으로 눈을 돌렸습니다. 충분히 잘 작동하는 것 같습니다.

jtbrower 에 2020년 07월 03일

UWP와 유니버설 Windows라는 용어는 없어져야 한다고 생각합니다. 이 용어에는 개발자가 부끄러워하게 만드는 불행한 수하물이 있습니다.

템플릿 WinUI(유니버설 Windows)를 WinUI(Win64)로 대체할 수 있을까요? 그런 다음 데스크탑 또는 스토어 옵션이 있습니까?

VagueGit 에 2020년 08월 21일

Win64는 혼란스럽습니다. 즉, Win32 API는 32비트만 지원하고 반대로 UWP는 64비트만 지원하며 둘 다 거짓입니다.

Win32 이름 자체는 이미 많은 초보자를 혼란스럽게 합니다. 문제를 악화시키는 데 Win64가 필요하지 않습니다.

sylveon 에 2020년 08월 21일

👍1

@VagueGit 내가 배운 것은 올바른 이름을 선택하고 이야기를 만드는 것이 더 복잡한 일 중 하나라는 것입니다. 이름을 바꾸는 것보다 우리(Microsoft)가 귀하의 성공을 돕기 위해 올바른 제품(및 스토리)을 제공해야 합니다. UWP는 Win32로 잘 알려진 용어이므로 계속 사용해야 합니다.

이것은 우리의 접근 방식입니다(매우 단순화됨).

WinUI는 서로 다른 장치를 대상으로 하는 두 가지 "유형"의 앱에서 사용할 수 있습니다.
앱은 입력과 폼 팩터가 많은 많은 기기를 대상으로 합니다. 그런 다음 UWP를 사용합니다. UWP는 이를 위해 만들어졌습니다. 따라서 패키징 모델, 저장소, 애플리케이션 모델, 보안 컨테이너 등과 같은 요구 사항을 충족해야 합니다.
앱은 데스크톱만 대상으로 하며 OS에 대한 전체 액세스 권한이 필요합니다. Win32 또는 Desktop(Visual Studio에서 WPF, WinForms, MFC, 앱을 호출하는 방식)을 사용합니다.

UWP 앱 의 WinUI 및

marb2000 에 2020년 08월 21일

@marb2000 네이밍이 어렵

WinUI로 마이그레이션하려는 UWP 앱이 있습니다. 우리는 Win32 API를 사용하지 않고 데스크탑만 대상으로 하며 스토어를 사용하고 싶지 않습니다. 어떻게 어울리나요?

VagueGit 에 2020년 08월 21일

@marb2000 네이밍이 어렵
WinUI로 마이그레이션하려는 UWP 앱이 있습니다. 우리는 Win32 API를 사용하지 않고 데스크탑만 대상으로 하며 스토어를 사용하고 싶지 않습니다. 어떻게 어울리나요?

정확히 누구를 위한 앱인가요?

일부러 UWP 앱을 사용하는 소비자로서 앱이 스토어에 없으면 앱을 보는 것은 고사하고 만지지도 않을 것입니다.

shaheedmalik 에 2020년 08월 21일

걱정하지 마세요 @shaheedmalik 우리는 당신에게 그것을 만지라고 요구하지 않을 것입니다 :-). 우리는 비즈니스 앱을 작성합니다. Win32 및 UWP. 몇 년 동안 스토어에 있었지만 스토어에는 보이지 않는 UWP 앱이 있습니다. 우리는 30년 전으로 거슬러 올라가는 확고한 비즈니스 고객 기반을 가지고 있습니다. 그들은 UWP 앱에 만족하지만 매장 경험에 만족하지 않아 우리는 이 앱을 매장 밖으로 옮깁니다.

따라서 우리는 Win64 비즈니스 앱에 대한 시장이 있다는 것을 알고 있으며 비즈니스 고객이 비용을 지불할 Win64 앱을 제공한 소수의 비즈니스 개발자 중 하나라고 믿습니다. 유니버설 Windows/다중 플랫폼 경로를 따라가는 이 스레드에 몇 명의 개발자가 있다는 것을 알고 있지만 매우 드뭅니다. 내 경험에 비추어 볼 때 대부분의 비즈니스 개발자는 특정 폼 팩터를 대상으로 합니다.

UWP에 막대한 투자를 하고 UWP의 비즈니스 성공을 달성한 개발 회사의 관점에서 말하자면 WinUI(데스크톱) 및 WinUI(스토어)용 템플릿이 아닐까요? UWP가 개발 플랫폼으로 얼마나 열악하게 여겨지는지에 대한 아이디어를 얻으려면 기술 미디어를 팔로우하기만 하면 됩니다.

VagueGit 에 2020년 08월 21일

@VagueGit
"WinUI로 마이그레이션하려는 UWP 앱이 있습니다. Win32 API를 사용하지 않고 데스크톱만 대상으로 하고 스토어를 사용하고 싶지 않습니다. 어떻게 적합합니까?"

UWP를 WinUI 3으로 마이그레이션하고 스토어 외부에 배포하시겠습니까? 순진한 질문: MSIX의 사이드로드 를 사용해 보셨습니까? 스토어 외에 UWP 사용을 중단하는 이유가 있습니까?

@VagueGit
"그래서 우리는 Win64 비즈니스 앱을 위한 시장이 있다는 것을 알고 있습니다."

한 가지 질문, Win64는 많은 것을 의미합니다. 예를 들어 앱은 x64용으로 컴파일됩니다. 당신에게 Win64는 어떤 의미인가요?

marb2000 에 2020년 08월 21일

@marb2000 UWP는 비즈니스 보고에 대한 지원이 좋지 않습니다. 브랜드 변경이 보고서 작성자와 같은 타사 도구 개발을 시작하는 데 도움이 될 수 있다고 생각합니다. 우리는 사이드 로딩을 가지고 놀았지만 사이드 로딩이 기본적으로 활성화되지 않았기 때문에 20H1까지는 실현 가능하지 않았습니다.

우리는 Win64가 Windows에서 앞으로 나아갈 길이라고 생각합니다. Micro$는 과거에 Win32를 레거시로 내세우려 시도했지만 성공하지 못했으며 현재는 그 자리를 되찾고 있습니다. 그러나 궁극적으로 Win32는 우리의 판단에 따라 사라져야 합니다(저는 Win32 개발 30년 후에 말합니다). 우리는 기업이 구매할 비즈니스 앱을 제공하기 위해 UWP의 한계를 대부분 극복했습니다. 우리는 UWP의 또 다른 반복이 브랜드 변경 없이 제한적인 관심을 받게 될 것을 우려합니다.

VagueGit 에 2020년 08월 21일

@marb2000 의 혼란에서 알 수 있듯이 Win64라는 용어는 이미 (잘못) 사용되었습니다. 저도 앞서 지적한 바 있습니다.

브랜드 변경이 필요할 수 있다는 데 동의하지만 Win64는 이를 수행하는 끔찍한 방법입니다. 공식적인 것이 있을 때까지는 UWP라는 용어를 모든 사람이 이해할 수 있도록 사용해야 합니다.

sylveon 에 2020년 08월 21일

@sylveon UWP는 모두가 실패로 이해합니다. 우리는 그것을 좋아하지만 다른 사람들은 그것을 좋아하지 않습니다. 그래서 리브랜딩이 중요합니다. 프로젝트 템플릿으로 WinUI(Deskop) 또는 WinUI(Store)에 대해 어떻게 생각하십니까?

VagueGit 에 2020년 08월 21일

👎1

WinUI(스토어)는 스토어에서 Win32 앱을 배송하거나 스토어 외부에서 UWP 앱을 배송할 수도 있기 때문에 좋지 않습니다. 그러나 WinUI(데스크톱)는 좋습니다.

sylveon 에 2020년 08월 21일

👍4

@sylveon WinUI(Store)는 상점을 대상으로 하는 다른 프로젝트를 배제하지 않습니다. 이는 상점을 통해 릴리스할 수 있는 기능 세트로 시작하기를 원한다는 의미입니다.

VagueGit 에 2020년 08월 21일

초보자를 혼란스럽게 할 정도로 나쁘다.

sylveon 에 2020년 08월 21일

이것은 이 스레드의 특정 사람을 대상으로 하는 것이 아니라 데스크탑 애플리케이션 개발자/회사 소유자로서 제 개인적인 의견입니다.

나는 무언가의 이름에 사로잡혀 본 적이 없습니다. 나는 그것이 어떤 기능을 가지고 있고 얼마나 잘 지원되는지에만 관심이 있습니다.

여기에서 MAUI와 같은 용어를 사용하면 흥분하지만 여전히 동일한 코드 기반이라는 것을 알게 되면 즉시 실망하는 많은 개발자(저 포함)가 있다고 주장합니다. 리브랜딩은 "이봐, 우리는 xyz에서 당신을 차단한 것과는 완전히 다른 코드 기반에서 시작하는 이 새로운 것을 만들고 있다"고 제안합니다. 내가 보기를 좋아하는 것은 나와 다른 사람이 겪었던 어려움을 상쇄하는 변경된 기능의 거대한 목록입니다.

플랫폼은 모든 제품이나 브랜드와 마찬가지로 시간이 지남에 따라 발전합니다. 자동으로 LTS를 암시하기 때문에 수십 년 동안 사용된 브랜드와 이름에서 편안함을 찾습니다. 이름 변경이 때때로 필요하다는 것을 알고 있지만 개발자에게 포기를 상기시키기도 합니다(Silverlight). 몇 년 동안 문제에 시달렸지만 결국 사랑받고 존경받는 브랜드가 된 자동차 모델이 많이 있습니다. 무엇을 기대해야 하는지 알고 있기 때문에 이전 경험이 마음에 들지 않더라도 친숙함과 관련하여 할 말이 많습니다. 문제가 해결되는 한 정말 중요합니다.

적어도 두 명의 청중을 고려해야 한다고 생각합니다. 개발자 및 최종 제품 사용자. 개발자/비즈니스 소유자로서, 응용 프로그램이 필요한 고객이 있고 고객이 기본 기술 이름으로 인해 피해를 입었다면 해당 이름으로 표시된 제품이 성숙해졌으며 해당 제품에서 고객이 우려하는 사항에 대해 확신을 심어주는 것이 제 일입니다. 과거가 업데이트되었습니다. 반면에 내가 "WinUI 또는 MAUI라는 새로운 멋진 기능이 있습니다."라고 말하고 그들은 이미 우리가 개발한 WPF 또는 UWP 또는 Xamarin 제품을 소유하고 있다고 말하면 예상할 수 있는 반응은 "오 좋아, 이제 우리 앱 2,3 또는 4개의 다른 기술로 작성되었습니다." 여기에서 내가 그들을 판매해야합니다. 고객님들이 다 다르기 때문에 이름을 그대로 두시든 바꾸시든 푸시백을 받겠습니다.

결국 (저에게) 중요한 것은 LTS가 있는 매력적이고 기능이 풍부한 응용 프로그램을 작성하는 데 필요한 도구가 있다는 것입니다. 제품이 마감 기한에 도달하는 것을 보고 흥분하고 제품이 출시되면 새로운 기능과 문제 해결 목록을 읽게 됩니다. 2016년부터 NetCore/Net5(이름 변경 LOL)에 대해 이 점이 마음에 들었습니다. (BTW, 고객에게 NetCore로 전환하도록 설득한 후 1년 동안 .Net5가 우리가 목표로 삼을 계획이라고 말하는 것도 쉽지 않습니다!)

지금은 XAML 언어를 사용하여 데스크톱 응용 프로그램을 작성하고 UWP/WinUI가 제공하는 것과 동일한 렌더링 성능(UWP 샌드박스 없이)을 얻을 수 있는 시점으로 빨리 가고 싶습니다. 그런 이유로 그리고 9월 미리 보기가 떨어졌기 때문에 나는 아발로니아를 시험 운전하기 시작하려고 합니다. SkiaSharp를 통한 렌더링 성능에 대해 들으면서 WPF 유사점을 좋아합니다.

UI 개발 옵션이 안정화되면 몇 년 안에 흥미진진해질 것입니다. 그들은 원하는 대로 프로젝트 템플릿의 이름을 지정할 수 있습니다. 기능 부족에 대한 제 생각은 바뀌지 않을 것입니다.

나는 당신 모두에게 감사합니다.

jtbrower 에 2020년 08월 21일

😄1 👍1

나는 jtbrower가 그의 이메일에서 말한 것을 얻습니다. 우리와 같은 그의 회사는 xaml 경로를 성공적으로 통과한 몇 안 되는 회사 중 하나입니다. 우리는 이점을 확신할 필요가 없습니다.

그러나 xaml은 Micro$에게 재앙이었습니다. 개발자들은 압도적으로 WinForms에 머물렀거나 완전히 웹 개발에 뛰어들었습니다. UWP 이후 개발자의 이탈이 악화되었습니다.

xaml 기술이 지속 가능하려면 Micro$가 온보딩에 실패한 수백만 명의 개발자를 확보해야 합니다. 이러한 개발자, 도구 공급업체 및 기술 미디어에게 UWP는 막다른 골목입니다. UWP의 또 다른 반복은 그들을 이길 수 없습니다.

VagueGit 에 2020년 08월 22일

👎1

@VagueGit 하지만 개발자들은 이름이 바뀐 제품을 동일하게 알고 싶어할 만큼 열심입니다. 그들은 MAUI를 이름이 변경된 Xamarin Forms로 알고 있습니다. 사실 그들은 MAUI가 도용된 이름이었다고까지 말하는 것 같습니다. 이름 변경으로 일반적인 개발자에게 동기를 줄 수는 없다고 생각합니다. 우리는 모두 기능을 원하지 않습니까? UWP가 여러 Windows를 허용하거나 완전한 신뢰를 허용하는 것을 보고 싶지 않습니까? 두 가지를 모두 수행했다면 모두 UWP를 대상으로 하고 스토어 앱용 샌드박스를 유지할 수 있습니다. 나는 정말로 나를 흥분하게 만드는 것이 무엇인지 큰 소리로 꿈꾸고 있습니다! 특징!!

jtbrower 에 2020년 08월 22일

jtbrower님의 말씀에 전적으로 동의합니다. 또한 저를 도와주셔서 감사하고 다른 사람들이 그들의 아이디어를 비판하기를 바랍니다. 그러나 스토어와 데스크톱이라는 두 가지 다른 UWP가 있음을 개발자 및 도구 공급업체에 표시하는 방법은 무엇입니까?

따라서 UWP 경로를 계속 따라가려는 사람들은 UWP Store 템플릿으로 시작할 수 있지만 샌드박스 및 완전한 신뢰가 아닌 64비트 데스크톱을 원하는 사람들은 ... 글쎄 UWP가 아닌가요?

UWP는 시장에서 장애가 있는 것으로 간주됩니다. Micro$ 자체가 UWP에서 자체 앱 빌드에서 물러났을 때 우리를 제외하고는 모두 UWP를 포기했습니다.

개발 시장은 UWP의 개발을 주시하지 않습니다. 샌드박스 및 완전한 신뢰가 아닌 64비트 데스크탑은 이름 변경 그 이상입니다. 그것은 다른 패러다임이다. 그러나 여전히 UWP라고 하면 UWP를 삭제한 사람들이 눈치채지 못할 것입니다.

VagueGit 에 2020년 08월 22일

👍2

@VagueGit UWP로 성공

UWP의 이름이 좋지 않다는 데 동의합니다. 검색 엔진에 "UWP is"라는 문구를 입력하면 Bing이나 Google이 제공하는 첫 번째 자동 제안은 "UWP is dead"입니다. 그러나 나는 @marb2000 이 맞다고 생각합니다.

라는 말과 함께...

오늘날 데스크톱 프로젝트의 여러 측면에서 "UWP"로 정의하는 데 사용된 다른 부분을 사용할 수 있습니다.

UI 스택(일명 WinUI3)
MSIX 패키징
MRT 리소스

CoreApplication이 해제되면 UWP와 데스크톱의 유일한 차이점은 애플리케이션에 대해 선택하는 샌드박스 모델과 대상으로 지정할 수 있는 장치뿐입니다.

우리는 프로젝트 템플릿을 수정하고 이를 보다 정확하게 설명하는 마법사와 같은 경험을 갖는 것에 대해 논의했습니다.

@JeanRoca 는 이 작업을 주도하는 PM이며 공유할 수 있는 추가 정보가 있을 수 있습니다.

stevenbrix 에 2020년 08월 27일

😄1 👍1

나는 WinUI 데스크탑 템플릿의 아이디어를 좋아합니다. Win32보다 적절하고 미래 지향적입니다. Win32가 32비트 제약 조건을 제안한 반면 시작하는 템플릿입니다. WinUI Desktop은 미디어와 개발자들 사이에서 주목을 받을 것입니다.

VagueGit 에 2020년 08월 27일

👍1

UWP 앱이 스토어 외부에서 출시되면 패키지는 .appinstaller입니다. 해당 앱을 Win UI Desktop으로 업그레이드하면 설치 프로그램 패키지가 appinstaller에서 msix로 변경됩니다.

앱 패키지 내의 세부 정보를 동일하게 유지하고 버전을 적절하게 범프한다고 가정하면 Windows는 이것이 동일한 앱의 새 버전임을 인식하고 로컬 데이터를 보존합니까, 아니면 다른 앱으로 설치할 것입니까?

VagueGit 에 2020년 08월 27일

👍1

내 이해에 따르면 WinUI 3.0은 .NET Framework <= 4.8에서 사용되지 않습니다. 따라서 WinUI에 대해 이야기하는 경우 .NET 네이티브 또는 .NET 3.1/5+(또는 다른 바인딩 집합)에 대해 이야기하고 있습니다.

.NET 5(또는 이 시점에서 6으로 추측됨)용 프레임워크 패키징에 대해 추가로 진행/요청하는 방법에 대한 제안 사항이 있습니까? 문제를 열었는데 응답이 없습니다. .NET 5 인앱 번들링은 시작이 아닙니다.

lmcdougald 에 2020년 08월 27일

👍1

@stevenbrix

CoreApplication이 해제되면 UWP와 데스크톱의 유일한 차이점은 애플리케이션에 대해 선택하는 샌드박스 모델과 대상으로 지정할 수 있는 장치뿐입니다.

불행히도 또 다른 큰 차이점은 .NET 개발자가 DirectX와 같은 API에 대해 C++로 전환해야 한다는 것입니다. 이 팀의 팀은 COM 기반임에도 불구하고 UWP와 호환되도록 하는 것을 분명히 거부합니다.

그리고 그 과정에서 경험과 같은 멋진 메모장으로 MIDL을 수동으로 작성하고 파일을 복사하는 생산성 시대로 되돌아가는 과정에서 분명히 Windows 팀은 C++ 워크플로에 NET과 같은 경험을 제공하는 대신 개발자 경험과 같은 ATL을 포기할 수 없습니다. C++/CX는 C++ Builder에 너무 근접해 있어서 ISO라는 이름으로 죽여야 했습니다. 운이 좋게도 C++23에서, 그리고 2025년에는 VS에서 얻을 수 있었습니다.

이러한 모든 잘못을 없애기 위한 적절한 개발 경험이 마련되지 않는 한 그때까지 UWP에 관심을 가질 사람이 있을지는 의문입니다.

또한 피드백을 제공할 팀에 관한 GitHub 문제를 던지는 것은 흥미를 잃는 매우 빠른 방법입니다. 나는 단지 너무 많은 관심을 보이는 것 같다.

pjmlp 에 2020년 08월 27일

❤1 👍1

DirectX API는 WinRT 호환성을 위해 수정할 수 없습니다. 이는 기존 소비자에게 중요한 API 중단이 될 수 있고 일어날 수 없기 때문입니다.

여러 관리와 같은 다이렉트 X에 해당하는 래퍼가있다 TerraFX 결합 또는 1 : 원시 1 VORTICE 더 C # 스타일의 API 래퍼입니다.

CX의 경우 사라져야 했습니다. 컴파일러 관련 언어 확장은 나쁘고 눈살을 찌푸리게 합니다. 코드 이식성을 크게 저해하고 C++ 표준 지원 측면에서 뒤처지는 경우가 많으며 기존 라이브러리와의 완전한 수직 통합이 필요합니다. 대안인 WRL은 사용하기가 매우 어렵고 지나치게 장황했습니다. 따라서 많은 사람들(DX 부서 포함)이 WinRT API를 작성하기를 원하지 않는다는 것은 놀라운 일이 아닙니다.

C++/WinRT는 훨씬 더 나은 솔루션입니다. IDL을 다시 가져와야 한다는 점은 유감입니다(현재는 필요악). C++ 팀은 이전보다 표준 지원에서 훨씬 더 나은 작업을 수행하고 있으므로 C++23이 완성되기 전에 실제로 메타클래스를 얻는다면 놀라운 일이 아닙니다. 이는 개발자 UX를 근본적으로 개선할 것입니다.

sylveon 에 2020년 08월 27일

❤1

@실베온

Windows 개발 커뮤니티가 생산성 저하를 정당화하면서 Redmond에서 나오는 모든 것을 무시한다는 사실에 놀라지 마십시오.

pjmlp 에 2020년 08월 27일

CX에서도 마찬가지였습니다... C++ 개발자가 독점 언어 확장을 좋아하지 않기 때문에 거의 사용되지 않았습니다.

sylveon 에 2020년 08월 27일

앱 패키지 내의 세부 정보를 동일하게 유지하고 버전을 적절하게 범프한다고 가정할 때 Windows는 이것이 동일한 앱의 새 버전임을 인식하고 로컬 데이터를 보존할까요, 아니면 다른 앱으로 설치할까요?

@VagueGit , 이것은 훌륭한 질문입니다. 결국 UWP와 데스크톱 앱을 설치하는 기술은 동일합니다. 대답이 예인 것 같습니까? 최신 SDK에서는 UWP 앱에도 .msix 확장자가 있다고 생각합니다(틀릴 수 있으므로 인용하지 마세요). 나는 당신이 이것을 현지에서 시도하고 알아낼 수 있다고 확신합니까? 참고로 @adambraden .

.NET 5(또는 이 시점에서 6으로 추측됨)용 프레임워크 패키징에 대해 추가로 진행/요청하는 방법에 대한 제안 사항이 있습니까? 문제를 열었는데 응답이 없습니다. .NET 5 인앱 번들링은 시작이 아닙니다.

@lmcdougald 어떤 문제를 말씀하시는지 알 것 같습니다(하지만 찾을 수 없습니다). 하나가 있지만 .net6 시간대에 있을 것이라고 생각합니다. 모두가 해야 할 일이라는 것을 알고 있습니다.

그리고 그 과정에서 경험과 같은 멋진 메모장으로 MIDL을 수동으로 작성하고 파일을 복사하는 생산성 시대로 되돌아가는 과정에서 분명히 Windows 팀은 C++ 워크플로에 NET과 같은 경험을 제공하는 대신 개발자 경험과 같은 ATL을 포기할 수 없습니다. C++/CX는 C++ Builder에 너무 근접해 있어서 ISO라는 이름으로 죽여야 했습니다. 운이 좋게도 C++23에서, 그리고 2025년에는 VS에서 얻을 수 있었습니다.

또한 피드백을 제공할 팀에 관한 GitHub 문제를 던지는 것은 흥미를 잃는 매우 빠른 방법입니다. 나는 단지 너무 많은 관심을 보이는 것 같다.

@pjmlp 나는 당신의 정직과 열정에 감사드립니다. 현재 C++ 경험이 수준 이하라는 데 더 동의할 수 없습니다. 우리는 C++ 경험을 .NET과 더 비슷하게 만들기 위해 많은 일을 했지만 @sylveon이 언급했듯이 비용이 듭니다. 결국 우리는 C++를 훌륭하게 만드는 데 엔지니어링 노력을 기울이고 싶다면 C++ 표준을 추진하는 데 쏟아 부어야 한다고 결정했습니다. 메타 클래스가 탈출구라는 것은 불행한 일이며, 우리가 그렇게 오래 기다릴 수 없다는 것에 동의하기 때문에 중간에 경험을 개선할 방법을 논의하고 있습니다.

stevenbrix 에 2020년 08월 27일

👍1

응답해 주셔서 감사합니다. "이것이 수행되어야 하는 작업이라는 것을 모두가 알고 있습니다."로 만족하며 1년 정도 부풀려진 바이너리와 함께 살 것입니다.

lmcdougald 에 2020년 08월 27일

@stevenbrix 및 @VagueGit - 여전히 msix 패키지에 대해 appinstaller 파일을 사용할 수 있어야 합니다. appinstaller 파일은 패키지에 URI를 제공하는 json 파일에 불과합니다. 엔터프라이즈 시나리오를 언급했으므로 내부 위치에 맞게 appinstaller uri를 사용자 정의하거나 외부 액세스에 대해서도 다르게 만들 수 있습니다. 모두 CDN에 따라 다릅니다. 버전 관리와 관련하여 - 패키지 ID가 동일한 경우 패키지 앱의 경우 예, 새 버전을 설치하면 기존 앱 데이터에 액세스할 수 있습니다.

AdamBraden 에 2020년 08월 27일

❤1

@stevenbrix @VagueGit 현재 마법사에 대한 경험과 같은 정보로 답장을 드리겠습니다. 나는 이 역할에서 아직 매우 신인이므로 내가 말하는 모든 것을 소금 한 알로 받아들이십시오. 즉, 우리 팀은 현재 Windows Template Studio 에서 노력을 주도하고 있습니다. 이 응용 프로그램을 사용하면 현재 마법사의 기존 템플릿에서 원하는 페이지 및 프레임워크로 새 WPF 또는 UWP 앱을 만들 수 있습니다.

앞으로 이 응용 프로그램의 목표와 현재 계획은 모든 사용자를 위한 개발 경험을 통합하고 개선하는 것입니다. 현재 WinUI 3을 사용하여 데스크톱 앱용 템플릿을 개발 중입니다. 여기 에서 추적 문제를 찾을 수 있습니다. 또한 사용자가 때가 되면 프로젝트를 쉽게 마이그레이션할 수 있도록 UWP에 대해 동일한 작업을 수행하는 것에 대해 논의하고 있습니다. 이것이 어떻게 작동할지 아직 정확히 알지 못하지만, 우리의 목표는 가능한 한 경험을 통합하고 단순화하는 것입니다. 도움이 되기를 바랍니다!

JeanRoca 에 2020년 08월 29일

👍2

CX에서도 마찬가지였습니다... C++ 개발자가 독점 언어 확장을 좋아하지 않기 때문에 거의 사용되지 않았습니다.

그들은 clang, GCC, Intel에서 그들을 사랑합니다. xlCC, PGI, CUDA, C++ Builder 및 임베디드 플랫폼의 과다.

분명히 CX는 Microsoft에서 제공하는 C++ RAD 환경을 수용할 수 없는 정책으로 인해 중단되었으며 대신 메모장과 같은 경험으로 MDIL/ATL을 수행하도록 했습니다.

pjmlp 에 2020년 08월 30일

나는 컴파일러에 관계없이 모든 비용을 피합니다. 특히 독점 확장이 그 자체로 완전히 다른 언어인 경우에는 더욱 그렇습니다.

sylveon 에 2020년 08월 30일

나는 컴파일러에 관계없이 모든 비용을 피합니다. 특히 독점 확장이 그 자체로 완전히 다른 언어인 경우에는 더욱 그렇습니다.

그렇다면 WinUI와 같은 독점 UI에 대해 코딩하는 이유는 대신 X Windows와 같은 공개 표준을 사용하는 것입니다.

pjmlp 에 2020년 08월 30일

... 마치 Windows에서 사용할 수 있는 것처럼. 표준 준수 검증을 위해 컴파일러(Clang 및 MSVC)를 다중 대상으로 지정하고 최신 C++ 표준을 사용하고 싶기 때문에 컴파일러 확장을 피합니다.

내 코드는 C++20을 사용합니다. 많은 언어 확장이 C++17 지원이 부족하거나 매우 늦게 받았습니다. 이 상황은 C++20에서 반복될 것입니다(또는 C++20이 17보다 훨씬 더 많은 새로운 것을 가지고 있기 때문에 악화됩니다). 예를 들어 C++20( /std:c++latest )과 CX( /ZW )를 혼합할 수 없으면 두 스위치가 호환되지 않는다는 컴파일러 오류가 발생합니다.

NVCC가 장치 측 C++17을 지원하는 데 올해까지 걸렸습니다. 좋지 않아.

내가 사용하는 언어 확장을 새로운 표준에서 사용할 수 없는 구석에 처하고 싶지는 않지만 새로운 표준 기능도 필요합니다.

위의 이유로 나는 그들을 피합니다. WinUI C++ 개발자 경험을 언어 확장으로 회귀하면 대체 GUI 프레임워크로 이동할 것입니다.

sylveon 에 2020년 08월 30일

@sylveon WinUI용으로 완벽하게 이식 가능한 C++20은 Windows 외부에서는 완전히 쓸모가 없습니다. 확장 기능이 없는 Qt도 재미있게 즐기세요.

C++ 데스크톱 사용자에게는 사용할 가치가 없기 때문입니다.

무의미한 정치가 CX를 죽였다는 것을 확인해주셔서 감사합니다.

pjmlp 에 2020년 08월 30일

서로 우호적인 제안. 나는 기술적인 C++ 주장에 대해 논평할 수 없으며 누가 옳은지 판단하지 않을 것입니다.
요점은 go have fun with X 와 같은 문구가 여기에서 우호적이고 협력적인 분위기를 설정하지 않는다는 것입니다. @stevenbrix 및 기타 필요한 경우

hansmbakker 에 2020년 08월 30일

👍2

@hansmbakker 감사

@pjmm 및 @sylveon 열정적이고 솔직한 대화에 감사드립니다.

두 가지 점 모두 매우 타당하며, 두 사람이 모두 옳다고 생각하기에 세상은 충분히 크다고 생각합니다.

@pjmlp 우리는 C++에 대한 현재 경험에 만족하지 않으며 C++ 메타클래스 전에 무언가를 해야 한다는 것을 인식하고 있습니다. 우리는 idl-free c++/winrt에 대해 몇 가지 토론을 했고 @kennykerr 와 @Scottj1s 는 그것에 대해 Build 토론을 했습니다. 컴파일러에 메타데이터가 필요하기 때문에 우리가 겪었던 대부분의 문제는 WinUI와의 통합과 관련되었습니다. 우리는 이 워크플로를 다시 방문하여 전반적인 개발자 경험을 개선할 응집력 있는 스토리를 가질 수 있는지 확인하고 싶습니다. C++/Cx를 다시 가져오는 대신 idl-free 버전의 C++/winrt에 관심이 있으십니까?

기대치를 설정하기 위해 여기에서 2020년에 많은 진전이 있을 것으로 기대하지는 않습니다.

stevenbrix 에 2020년 08월 30일

IDL 무료 C++/WinRT에 관심이 많습니다.

IDE 경험도 최고가 아닙니다. 예를 들어 C#에서와 같이 XAML 편집기에서 이벤트 콜백을 만들 수 없습니다(새 콜백 만들기 드롭다운은 아무 작업도 수행하지 않음). XAML 편집기에서 정의로 이동도 작동하지 않습니다.

다른 문제는 이 리포지토리에 채운 다양한 XAML 컴파일러 버그로, 다른 지원 언어에서는 필요하지 않은 해결 방법이 필요합니다.

sylveon 에 2020년 08월 30일

@stevenbrix , IDL이 없는 C++/WinRT에 제 목소리를 추가하고 싶습니다(물론 C++/CX로의 복귀는 원하지 않습니다). 우리는 플랫폼 간 소프트웨어를 작성하고 MSVC 및 LLVM(Windows 포함)으로 컴파일하므로 표준 준수 C++는 우리에게 매우 중요합니다.

MarkIngramUK 에 2020년 08월 30일

❤1

@stevenbrix ,

@pjmlp 우리는 C++에 대한 현재 경험에 만족하지 않으며 C++ 메타클래스 전에 무언가를 해야 한다는 것을 인식하고 있습니다. 우리는 idl-free c++/winrt에 대해 몇 가지 토론을 했고 @kennykerr 와 @Scottj1s 는 그것에 대해 Build 토론을 했습니다. 컴파일러에 메타데이터가 필요하기 때문에 우리가 겪었던 대부분의 문제는 WinUI와의 통합과 관련되었습니다. 우리는 이 워크플로를 다시 방문하여 전반적인 개발자 경험을 개선할 응집력 있는 스토리를 가질 수 있는지 확인하고 싶습니다. C++/Cx를 다시 가져오는 대신 idl-free 버전의 C++/winrt에 관심이 있으십니까?
기대치를 설정하기 위해 여기에서 2020년에 많은 진전이 있을 것으로 기대하지는 않습니다.

이것은 C++/WinRT를 사용한 이 전체 아이디어가 처음부터 생산성 저하에 대한 고려 없이 우리에게 얼마나 나쁜 영향을 미쳤는지 보여줍니다.

이러한 관점에서 볼 때 Windows 개발자 경험이 Windows 3.0으로 거슬러 올라가는 오랜 개발자이며 오늘날 C++는 단독으로 사용되는 것이 아니라 .NET 기반 응용 프로그램과 함께 사용하는 데 대부분 관련이 있습니다.

Borland 도구는 오랜 Windows 개발자에게 알려진 여러 가지 이유로 인해 Microsoft 컴파일러로 마이그레이션하는 것으로 끝날 때까지 저의 빵과 버터였습니다.

Visual C++는 Forms 및 AOT 컴파일과의 통합이 부족하기 때문에 C++/CLI에서도 C++ Builder로 _Visual_되지 않았습니다.

C++/CX는 Microsoft가 마침내 그것을 얻은 것처럼 보였습니다. 25년 후에는 Delphi/C++ Builder를 함께 사용하는 것과 동일한 생산성 워크플로가 제공될 것입니다.

대신 우리의 생산성 저하에 대한 고려 없이 C++/CX를 죽이려는 정치적 움직임으로 얻은 것은 누락된 기능에 대한 책임을 ISO C++ 및 WG 21에 넘겼습니다. 마치 Visual C++ 팀이 우리에게서 빼앗은 모든 것이 WG 21에서 승인했습니다.

그리고 필요한 기능이 결국 ISO C++에 채택되더라도 2023년, 2026년, ....? 그런 다음 이러한 기능이 실제로 Windows 개발자에게 제공되는 시점이 언제인지에 대한 전체 시점이 있습니다. 모듈 지원을 살펴보십시오. 우리는 2012년 Windows 8이 출시된 이후 C++/CX가 우리에게 제공한 것과 동등한 수준에 도달하는 데 약 끝없는 시간이 걸립니다.

따라서 2020년까지 개선이 나타나지 않을 것이라는 점을 감안할 때 우리는 이미 여기서 9년에 대해 이야기하고 있습니다. 따라서 이 모든 것이 관리된 방식에 대해 약간 화를 내는 경향이 있는 경우 실례합니다. UWP 실패, Reunion, .NET 에코 시스템 재부팅을 처리하기 위해 베어 본 MIDL 메모장 경험과 ATL과 같은 끝없는 템플릿 수프로 2000 년처럼 코딩하라는 요청을 받았습니다.

예, IDL 무료 C++/WinRT 버전이거나 최소한 완전한 Intellisense/Intelicode 지원이 있고 수동으로 파일을 복사할 필요가 없는 IDL 경험입니다. 그러나 C++ 코드 자체에서 ATL과 같은 경험을 없애지는 않습니다.

.NET/C++ 개발 관점에서 볼 때, 저는 Microsoft 프레임워크의 과거로 시간 여행을 하는 것에 관심이 없습니다. 오히려 C++ RAD 관점이 불행하게도 C++/ WinRT 스토리가 관리되었고 지금 UWP에서 백페달링으로 진행되는 다른 모든 것, 나는 "개발자, 개발자, 개발자"가 어디로 갔는지 궁금합니다.

여전히 약간 엉뚱한 느낌이 든다면 죄송합니다. 그러나 대부분의 C++ 컴파일러가 어쨌든 하지 않는 ISO 순도의 이름으로 .NET에서 C++로 한 단계 더 나아가야 할 때 생산성이 떨어지는 것에 대해 느끼는 것입니다.

pjmlp 에 2020년 08월 31일

👎2

C++는 여전히 매우 관련성이 높은 독립 실행형입니다. 많은 응용 프로그램이 관리 코드를 실행하지 않고 원시 C++로 작성됩니다. 실제로 전체 UWP 런타임 및 XAML/WinUI 프레임워크는 기본 C++입니다. C++로 작성된 UWP 앱에는 (다행히) 관리되는 언어가 없습니다.

.NET에서 C++로 전환해야 할 필요성을 느낀다면 그 이유를 스스로에게 물어보고 .NET 내에서 직접 이러한 문제를 해결해야 한다고 주장합니다. 성능? 스팬 유형, stackalloc 및 벡터 내장 기능을 사용하십시오. DirectX, 기본 API 또는 COM? TerraFX와 같은 바인딩을 사용합니다. C++ 전용 lib와 상호 작용합니까? .NET에서 필요한 것을 다시 구현하십시오.

.NET은 C++ 없이 더 좋고 C++는 .NET 없이 더 좋습니다.

나는 cppwinrt의 템플릿이 그렇게 나쁘다고 생각하지 않습니다. 나를 가장 짜증나게 하는 것은 코드 생성의 필요성과 그것이 생성하는 끔찍한 컴파일 시간입니다.

sylveon 에 2020년 08월 31일

👍4

@sylveon Easy, Windows 팀이 UWP로 제공하는 것을 거부하고 타사 바인딩이 포함되지 않기 때문에 모든 사람이 라이선스 및 향후 지원 문제를 고려하지 않고 모든 것을 허용하는 법무 부서의 축복을 받은 것은 아닙니다.

Borland(현재 Embarcadero)와 The Qt Company는 이를 수행하는 방법을 보여 주었지만 플랫폼을 유지하려는 관련성을 결정하는 것은 Microsoft에 달려 있습니다.

macOS, iOS, Android, ChromeOS GUI에서 ISO C++로 어디까지 갈 수 있는지 확인하십시오.

어쨌든 여기서 멈추는 것은 무의미합니다.

pjmlp 에 2020년 08월 31일

@pjmlp iOS/macOS/Windows에서 잘 작동하는 수백만 줄의 ISO C++가 포함된 교차 플랫폼 응용 프로그램이 있습니다. C++는 성능 및/또는 배터리 수명에 관심이 있을 때 사용할 수 있는 유일한 언어입니다. C++ 확장은 우리가 여러 컴파일러(서로의 확장을 구현하지 않는 것이 분명함)를 사용하기 때문에 좋지 않습니다.
우리는 이전에 C++/CLI를 사용해 왔으며 매우 고통스럽습니다. 원시 C++ 포인터만 허용하는 클래스 멤버와 같은 제한으로 인해 스마트 포인터를 저장하기가 어렵습니다. 컴파일 시간이 깁니다(단일 문자 변경 시 MD 병합 시간 5분 소요).
C++에는 pragma 관리/비관리 변경을 위한 래핑 필요가 포함됩니다.
컴파일러는 C++와 비교하여 C++/CLI의 다른 버전입니다(그리고 빌드 시 C++/CLI 컴파일러가 C++17 이상을 지원하지 않는다는 말을 들었습니다. 이는 C++를 사용하는 라이브러리의 헤더를 포함할 때 문제가 되는 문제입니다. 20가지 기능).
내가 말하려는 것은 여러 경쟁적인 노력을 하지 말라는 것입니다. 표준에 충실하고 그에 따라 작업하십시오. Microsoft는 C++ 위원회에 있으며 표준을 발전시키는 데 도움을 줍니다. 이것은 독점이 아니라 확장에 고정된 초점이 되어야 합니다.

MarkIngramUK 에 2020년 08월 31일

👍2

midl.exe, cl.exe 또는 link.exe와 유사한 xaml 파일을 컴파일하기 위해 xaml.exe와 같은 xaml 컴파일러를 사용할 수 있습니까? winui 애플리케이션을 위한 자동 파이프라인을 구축하는 것은 매우 유용할 것입니다.

때로는 Visual Studio를 사용하여 개발을 수행하고 싶지 않고 원하는 편집기를 사용할 수 있지만 빌드 파이프라인을 분리된 상태로 유지하는 경우가 있습니다. winui 응용 프로그램 xaml은 특별한 부분인 것 같고 아직 컴파일할 명령줄 도구가 없는 것 같습니다.

sammi 에 2020년 09월 11일

👀1 👍1

이것은 cmake와 같은 시나리오에 필요합니다: https://github.com/microsoft/ProjectReunion/issues/58

sylveon 에 2020년 09월 11일

midl.exe, cl.exe 또는 link.exe와 유사한 xaml 파일을 컴파일하기 위해 xaml.exe와 같은 xaml 컴파일러를 사용할 수 있습니까? winui 애플리케이션을 위한 자동 파이프라인을 구축하는 것은 매우 유용할 것입니다.

@sammi #1433은 당신이 찾고 있는 것에 대한 그럴듯한 솔루션을 요약합니까?

jtbrower 에 2020년 09월 12일

midl.exe, cl.exe 또는 link.exe와 유사한 xaml 파일을 컴파일하기 위해 xaml.exe와 같은 xaml 컴파일러를 사용할 수 있습니까? winui 애플리케이션을 위한 자동 파이프라인을 구축하는 것은 매우 유용할 것입니다.
@sammi #1433은 당신이 찾고 있는 것에 대한 그럴듯한 솔루션을 요약합니까?

@jtbrower , 제가 찾던 바로 그 기능입니다, 감사합니다!

sammi 에 2020년 09월 12일

확실히 그것은 미리보기이고 많은 것을 기대해서는 안된다는 것을 의미하지만 WinUI 3 미리보기 2는 나에게 실망했습니다.

가장 큰 요구 사항은 XAML 설계 영역입니다. 나는 XAML 디자이너가 전혀 작동하지 않는다는 사실에 상당히 놀랐고 지금까지 언제 작동할지에 대한 명확한 정보를 찾지 못했습니다.

예, Visual Studio의 현재 XAML 디자이너가 매우 느리고 실제로 중단되어서는 안 되는 사항을 실시간으로 변경할 때 중단된다는 데 동의합니다. 예를 들어, Height="*" 를 "Auto" 또는 100으로 변경합니다. (오류 창은 약 10개의 오류를 뱉어냅니다. 무수히 많은 물결선이 있고 프로젝트를 다시 빌드해야 함)

분명히 말해서, 저는 디자인을 위해 디자이너를 사용하지 않습니다. 제 레이아웃이 빌드 프로세스를 거치기 전에 구상했던 것처럼 보이는지 알고 싶습니다. 더 쉬우면 디자이너가 "보기 전용"이고 XAML을 조정하면서(충돌 없이) 업데이트된 경우 GUI를 사용하여 XAML을 변경하지 않거나 매우 드물게 사용하므로 괜찮을 것입니다. . 실제로 사용자가 소스를 변경하고 실시간으로 출력을 볼 수 있도록 하는 XAML 소스로 WindowsCommunityToolkit 이 수행하는 작업은 제 목적에 충분합니다.

그렇긴 해도 WinUI는 훌륭한 아이디어를 가지고 있습니다. 이 모든 "쉬운" 항목을 OS에서 분리하고 개발자의 작업이 훨씬 더 빠르게 발전할 수 있도록 하며, 10억 장치를 업그레이드할 필요가 없도록 종속성을 앱과 번들로 묶을 수 있습니다. 그래서 그들은 우리의 새로운 훌륭한 것들을 실행할 수 있습니다.

Project Reunion이 앱 컨테이너에서 GUI를 완전히 분리하기를 바랍니다. 샌드박스/경계가 없는 UWP와 같은 UX는 큰 진전이 될 것입니다.

하지만 언제 다시 작동하는 XAML 디자이너를 가질 수 있을까요... 제발요?

ericleigh007 에 2020년 11월 16일

핫 리로드는 대부분 XAML 디자이너의 "보기 전용" 목적을 더 이상 사용하지 않는다고 생각합니다.

sylveon 에 2020년 11월 16일

그러나 여기서는 WinUI 도구에 대해 이야기하고 있습니다. 핫 리로드 및 라이브 비주얼 트리는 WinUI에서도 작동하지 않습니다.

보기 전용 디자이너가 의미하는 바는 "다음 미리 보기에 넣을 수 있는 것이라면 만족할 수 있습니다."였습니다.

내가 틀릴 수도 있지만(그렇다면 알려주세요), 지금 당장은 WinUI에서 UI를 볼 수 있는 유일한 방법은 빌드하고 실행하는 것입니다.

ericleigh007 에 2020년 11월 16일

그러나 여기서는 WinUI 도구에 대해 이야기하고 있습니다. 핫 리로드 및 라이브 비주얼 트리는 WinUI에서도 작동하지 않습니다.
보기 전용 디자이너가 의미하는 바는 "다음 미리 보기에 넣을 수 있는 것이라면 만족할 수 있습니다."였습니다.
내가 틀릴 수도 있지만(그렇다면 알려주세요), 지금 당장은 WinUI에서 UI를 볼 수 있는 유일한 방법은 빌드하고 실행하는 것입니다.

안녕하세요 @ericleigh007 최신 릴리스인 WinUI 3 Preview 3를 확인할 기회가 있으셨나요? 최근 IntelliSense, Hot Reload, Live Visual Tree 및 Live Property Explorer와 같은 많은 도구 개선 사항을 추가했습니다. 여기 에서 릴리스 정보를 확인하고 있습니다 . 여러분의 생각에 관심이 많으니 부담 없이 연락주세요!

JeanRoca 에 2020년 11월 18일

👍1

@JeanRoca 불행히도 C++/CX 개발 경험을 따라잡는 것은 도구 개선 사항 중 하나가 아닙니다. 제안된 C++ 도구가 2000년으로 돌아가 메모장에 IDL 파일을 작성하고(편집기 지원 없이) 수동으로 파일을 복사하는 것처럼 느껴질 때 WinUI에 대한 개발자의 많은 사랑을 기대하지 마십시오.

가능한 한 많이 .NET에 머물게 하거나 C++/WinRT로 이동하라는 경고에도 불구하고 C++/CX를 계속 사용하게 만듭니다.

pjmlp 에 2020년 11월 18일

업데이트해주셔서 감사합니다. 오늘 그것을 시도하고 다시보고 할 것입니다. 🤞

메일에서 보낸 메일 https://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10

보낸 사람: JeanRoca [email protected]
보냄: 2020년 11월 18일 수요일 오전 4:41
받는 사람: microsoft/microsoft-ui-xaml [email protected]
참조: Eric [email protected] ; 멘션 @noreply.github.com
제목: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 개발자 경험 및 도구 - 입력 필요(#1045)

그러나 여기서는 WinUI 도구에 대해 이야기하고 있습니다. 핫 리로드 및 라이브 비주얼 트리는 WinUI에서도 작동하지 않습니다.

보기 전용 디자이너가 의미하는 바는 "다음 미리 보기에 넣을 수 있는 것이라면 만족할 수 있습니다."였습니다.

내가 틀릴 수도 있지만(그렇다면 알려주세요), 지금 당장은 WinUI에서 UI를 볼 수 있는 유일한 방법은 빌드하고 실행하는 것입니다.

안녕하세요 @ ericleigh007 https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fericleigh007&data=04%7C01%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637412713160082691%7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAILCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sBIZUiZU 의 최신 버전을 확인하시겠습니까? 최근 IntelliSense, Hot Reload, Live Visual Tree 및 Live Property Explorer와 같은 많은 도구 개선 사항을 추가했습니다. 여기에서 릴리스 정보를 확인할 수 있습니다. https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F3620&data=04%7C01% 7C % 7Cae66199f9c044a728fb108d88b7c470d % 7C84df9e7fe9f640afb435aaaaaaaaaaaa % 7C1 % 7C0 % 7C637412713160082691 % 7CUnknown % 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 % 3D % 7C1000 & SDATA = 2jVKkAs9Whd6U9kH1ZxJKy956wI6Itg7jq6lCuaqEgE % 3D & = 0을 예약 하고 여기에 최신의 미리보기를 얻을 https://eur05.safelinks.protection.outlook.com/?url=https% 3A % 2F % 2Fdocs.microsoft.com % 2Fen 미 % 2Fwindows % 2Fapps % 2Fwinui % 2Fwinui3 % 2F 및 데이터 = 04% 7C01 % 7C % 7Cae66199f9c044a728fb108d88b7c470d % 7C84df9e7fe9f640afb435aaaaaaaaaaaa % 7C1 % 7C0 % 7C637412713160092685 % 7CUnknown % 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 % 3D % 7C1000 및 SDATA = VF2s7jilqpksevP6Fx7mXW1QCNJN2 % 2BK5yWOndg3rKoc%3D&reserved=0 . 여러분의 생각에 관심이 많으니 부담 없이 연락주세요!

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F1045%23issuecomment에서 확인하십시오. = 04% 7C01 % 7C % 7Cae66199f9c044a728fb108d88b7c470d % 7C84df9e7fe9f640afb435aaaaaaaaaaaa % 7C1 % 7C0 % 7C637412713160092685 % 7CUnknown % 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 % 3D % 7C1000 및 SDATA = R1S2JpfBSzsNKJBAH5가 2Fgme8Bq % % % 2FjHbzB9FySk1KnZKbk 3D 및 예약 = 0 -729402012 및 데이터 또는 거부 //eur05.safelinks.protection.outlook : HTTPS .COM /? URL = HTTPS % 3A % 2F % 2Fgithub.com % 2Fnotifications % 2Funsubscribe-인증 % 2FABX3S2XLYXYXP7BZZC3OE73SQNGBFANCNFSM4ICOLUJQ 및 데이터 = 04퍼센트 7C01 % 7C % 7Cae66199f9c044a728fb108d88b7c470d % 7C84df9e7fe9f640afb435aaaaaaaaaaaa % 7C1 % 7C0 % 7C637412713160102680 % 7CUnknown % 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 % 3D % 7C1000 및 SDATA = 0H6IpND3YX1s6oyXy % 2FCXNAMN9n8fvSPdWks%2FfmXT0Bc%3D&reserved=0 .

ericleigh007 에 2020년 11월 18일

- 현재 winui3 C++(데스크톱)에서 작동하는 wysiwyg 편집기/메소드가 없잖아요?

niclar 에 2020년 11월 18일

Microsoft는 C++/CX 사용자도 소외시키려고 관리하고 있습니까? 이 모든 것이 잘 형성되지 않습니다. Microsoft가 몇 년 전에 UWP를 위해 추진했던 기술을 채택한 사람은 .net이든 C++이든 현재 Microsoft의 지원 없이는 곤경에 처해 있습니다.

WinUI 3은 WPF로 작성된 데스크톱 앱에만 적용되는 것으로 보이지만 UWP에는 WPF의 모든 기능이 없고 WinUI는 더 적은 기능이 있다는 것을 빨리 깨닫게 될 것입니다. WinUI 3를 시작하기에 좋지 않은 장소인 모두가 좌절할 것입니다.

robloo 에 2020년 11월 18일

👍1

@robloo UWP를 옹호하던 사람으로서 그들은 나를 잃었습니다. 그들은 혼란을 정리할 때까지 WPF와 Win32입니다.

C++/WinRT는 정치적인 움직임이었고 ISO C++가 결국 리플렉션 및 메타클래스 지원을 제공할 때까지 기다렸다가 Visual Studio 팀이 C++/CX 경험을 복제할 때까지 기다리라는 말을 들었습니다.

언급했듯이 IDL 파일을 편집하는 것조차도 원시 메모장을 사용하는 것과 다르지 않습니다.

.NET에서 우리는 모든 UWP 구성 요소를 사용할 수 없도록 하는 Microsoft를 참아야 했지만 C++/CLI와 같은 경험을 제공하는 C++/CX에서는 어떻게든 감당할 수 있었습니다. 이제 C++/WinRT를 사용하여 ATL로 돌아갑니다.

그런 다음 Reunion 문제 토론과 업데이트 로드맵을 읽으면 방향을 수정하는 데 몇 년이 걸릴 것이 분명합니다.

WPF 및 Win32는 오래되었을 수 있지만 다시 작성하거나 기능을 잃지 않고 여기에 있고 작동합니다.

pjmlp 에 2020년 11월 18일

👍1

- 현재 winui3 C++(데스크톱)에서 작동하는 wysiwyg 편집기/메소드가 없잖아요?

XAML 디자이너는 일종의 작동하지만 처음부터 wysiwyg 편집을 위해 설계된 것은 아닙니다. Hot reload(이제 미리보기 3에서 작동)가 더 잘 작동합니다.

sylveon 에 2020년 11월 18일

라이브 비주얼 트리와 라이브 소품 보기는 미리보기 3에서 훌륭하게 작동합니다. 디자이너는 언제 사용할 수 있습니까?

또한 데스크톱(WPF)(UWP 아님) 디자이너가 2.4(또는 기타)에서 작동하는 데 사용되었지만 이제 테스트에서 다시 작동하지 않는 것으로 나타났습니까? 디자이너의 현재 상태에서 내가 놓치고 있는 것이 있습니까?

ericleigh007 에 2020년 11월 18일

파티에 늦어서 죄송합니다. @wjk 는 그의 첫 번째 요점으로 그것을 못 박았습니다.

MSIX는 모두 훌륭하지만 MSIX가 지원하지 않는 기능을 필요로 하는 더 복잡한 응용 프로그램을 설치하는 데 여전히 좋은 MSI를 사용합니다. 또한 필요한 Authenticode 인증서가 얼마나 비싸기 때문에 MSIX를 사용하기가 꺼려집니다.

저는 MSIX의 매력에 정말 감사하지만 이 인증서 서명 의무는 저에게 있어 거래 차단기입니다. 클래식 데스크톱 설치 프로그램 환경을 만드는 데 사용할 수 있는 적절한 SCM 친화적인 설치 프로그램 마법사가 필요합니다. MSIX의 개선 사항을 사용하고 보다 현대적인 개발 환경을 위한 Microsoft Store 및 인증 요구 사항 없이 MSI 설치 프로그램의 새 버전을 만드는 것이 어떻습니까? 아마도 이것이 현재 로드맵에 나열된 "비 MSIX 배포 지원" 기능이 의미하는 바가 무엇입니까? 그렇다면 기적에 의해 이전 릴리스로 만들어지지 않는 한 3.x를 기다리는 데 갇힌 것 같습니다. VS Installer 프로젝트는 비극적으로 오래되었고 소스 제어에 전혀 친숙하지 않기 때문에 기대합니다. 😓

Chiramisu 에 2020년 11월 19일

@Chiramisu 저도 그 의견에 동의하지만 혼란스럽습니다. 사이드

lmcdougald 에 2020년 11월 19일

👍1

@Chiramisu WiX를 사용해 보셨습니까? 모든 MSI 기반 설치 프로그램에 사용하며 매우 잘 작동합니다. Visual Studio 확장 도 있으므로 다양한 컴파일 명령을 자동화하는 WiX 프로젝트를 가질 수 있습니다.

wjk 에 2020년 11월 19일

👍1

@robloo UWP를 옹호하던 사람으로서 그들은 나를 잃었습니다. 그들은 혼란을 정리할 때까지 WPF와 Win32입니다.
C++/WinRT는 정치적인 움직임이었고 ISO C++가 결국 리플렉션 및 메타클래스 지원을 제공할 때까지 기다렸다가 Visual Studio 팀이 C++/CX 경험을 복제할 때까지 기다리라는 말을 들었습니다.
언급했듯이 IDL 파일을 편집하는 것조차도 원시 메모장을 사용하는 것과 다르지 않습니다.
.NET에서 우리는 모든 UWP 구성 요소를 사용할 수 없도록 하는 Microsoft를 참아야 했지만 C++/CLI와 같은 경험을 제공하는 C++/CX에서는 어떻게든 감당할 수 있었습니다. 이제 C++/WinRT를 사용하여 ATL로 돌아갑니다.
그런 다음 Reunion 문제 토론과 업데이트 로드맵을 읽으면 방향을 수정하는 데 몇 년이 걸릴 것이 분명합니다.
WPF 및 Win32는 오래되었을 수 있지만 다시 작성하거나 기능을 잃지 않고 여기에 있고 작동합니다.

계속 따라갈 수 있도록 C++/WinRT를 사용한 IDL 편집이 무엇인지 알려주실 수 있습니까? co_await 및 기타 C++ 17 구문에 대해 내가 본 바에 따르면 C++/CX에서 복잡성이 크게 증가한 것 같습니다.

MS? 누군가 그 주위에 정말 좋은 래퍼를 만들지 않는 한 C++ 17 기능을 기반으로 하는 C++/WinRT가 너무 복잡하고 현재 디자인과 너무 다르다는 것이 가능하지 않습니까? C++/WinRT를 합리적으로 간단하게 사용하고 마이그레이션할 수 있도록 C++ 17용으로 일부 "우수한 래퍼"를 만들 수 있을 만큼 C++/CX를 유지할 수 없었습니까?

(이제 누군가가 이것이 어떻게 수행되는지 보여주는 기사에 링크할 것이고, 나는 어리석게 느낄 것입니다)

ericleigh007 에 2020년 11월 20일

@lmcdougald 아직 시도하지 않았습니다. 내 특정 프로젝트는 여전히 .NET Framework 3.5에 있습니다. 내가 알지. 아직 업데이트가 허용되지 않았으므로 설치 프로그램 기술이 이 고대 프레임워크와 함께 작동할 것인지에 대해 고민하고 있습니다. 😖

@wjk 나는 과거에 그것을 조사했지만 아니요, 아직 시도하지 않았습니다. 위의 내용을 감안하더라도 기존 프로젝트에서 그대로 작동할 수 있는 유일한 기술인 것 같습니다. 혹시 오래된 프레임워크를 기반으로 하는 WinForms 앱에 이것을 사용해 보셨습니까? 불행히도 저는 외로운 개발자이기 때문에 시간을 보내는 방식에 대해 극단적인 편견을 가져야 하고 새로운 기술을 실험할 자유가 없습니다.

친절한

Chiramisu 에 2020년 11월 20일

@Chiramisu 예, WiX는 이전 버전의 .NET Framework에서 작동하며 예, winforms 앱에서도 작동합니다. 원시 MSI 파일을 생성하기 때문에 WiX는 모든 프로그래밍 언어로 무엇이든 설치할 수 있습니다. 그것을 배우는 관점에서, 나는 기본 튜토리얼 부터 시작할 것입니다. 또한 .NET이 설치되어 있는지 감지 하는 방법과 WiX를 사용하여 파일에서 NGEN 을 방법 을 지적하고 싶습니다. 앱에서 이러한 기술을 사용하고 있기 때문입니다. Visual Studio 확장에는 추가할 올바른 뼈대 코드를 제공하는 여러 프로젝트 템플릿도 함께 제공됩니다. (참고: 부트스트래퍼 템플릿은 훨씬 더 고급 주제이므로 사용하지 마십시오.) 이것이 도움이 되기를 바랍니다!

wjk 에 2020년 11월 20일

@Chiramisu 나는 당신이 찾고있는 것이 너무 혼란 스럽습니다. WinUI 3.0 프로젝트가 아닌 현재 프로젝트를위한 패키징 도구를 찾고있는 것 같습니다.

.NET Framework 3.5를 MSIX로 패키징할 수 있다는 점은 주목할 가치가 있습니다. VS 2019에서 패키지 프로젝트를 사용하여 기존 앱에 대한 MSIX 패키지를 빌드한 다음 긴 전환을 다소 원활하게 진행할 수 있지만 많은 작업이 필요합니다.

WinUI 3.0은 공식적으로 .NET 3.5를 지원하지 않으며 아마도 어떤 버전에서도 .NET Framework를 지원하지 않을 것입니다. 기존 패키징 프로젝트를 변경하지 않고 .NET 4.6(또는 이상적으로는 4.8 이상)으로 업그레이드하는 것을 목표로 현대화를 시작하겠습니다. 순조롭게 진행된다면 업데이트된 .NET 4.6+ 앱에서 참조하는 .NET Standard 공유 라이브러리로 기능 전환을 시작하겠습니다.

.NET 4.6 앱이 안정적이고 테스트되면 MSIX 패키징 프로젝트에 대한 자동 업데이트로 교체할 수 있습니다. .NET Standard 단계 후에는 .NET Core 3.1(또는 5, 하지만 LTS 상태가 조직에 의미가 있는 것 같습니다)에서 거의 동일한 코드를 사용하는 프로젝트 헤드를 만들 수 있습니다. 다시 테스트한 다음 MSIX를 이 버전을 사용하도록 전환합니다.

이 시점에서 WinForms에서 WinUI로 전환하는 것은 WinUI를 배우고 인터페이스를 다시 구현하는 문제입니다. 다시 새 프로젝트 헤드를 만들고 .NET Standard 라이브러리를 구현 + 참조하고 테스트한 다음 이 버전을 사용하도록 패키지를 전환합니다.

이것이 내가 어떤 주어진 시점에서 매우 다양한 프로젝트를 생성하지 않고 현대화를 진행하는 방법입니다. MSIX 패키징 및 .NET 4.6 + .NET Standard 단계를 설정하는 데 우선순위를 둡니다. 이렇게 하면 훨씬 더 많은 도움말 도구와 최신 .NET 개발 주기에 대한 연결을 얻을 수 있기 때문입니다. .NET 3.5가 존재하는 한 수명 주기가 1/10이라는 점을 고려할 때, 서둘러 .NET 5로 전환하는 것은 단기적으로 조직에 좋지 않은 생각처럼 들립니다.

lmcdougald 에 2020년 11월 20일

계속 따라갈 수 있도록 C++/WinRT를 사용한 IDL 편집이 무엇인지 알려주실 수 있습니까? co_await 및 기타 C++ 17 구문에 대해 내가 본 바에 따르면 C++/CX에서 복잡성이 크게 증가한 것 같습니다.
MS? 누군가 그 주위에 정말 좋은 래퍼를 만들지 않는 한 C++ 17 기능을 기반으로 하는 C++/WinRT가 너무 복잡하고 현재 디자인과 너무 다르다는 것이 가능하지 않습니까? C++/WinRT를 합리적으로 간단하게 사용하고 마이그레이션할 수 있도록 C++ 17용으로 일부 "우수한 래퍼"를 만들 수 있을 만큼 C++/CX를 유지할 수 없었습니까?
(이제 누군가가 이것이 어떻게 수행되는지 보여주는 기사에 링크할 것이고, 나는 어리석게 느낄 것입니다)

일반 C++에는 .winmd 파일을 만드는 데 필요한 형식 메타데이터를 추출하는 기능이 없기 때문에 WinRT 클래스를 .hpp 및 .cpp 위에 .idl 파일에 작성해야 합니다.

co_await 는 .then([=](Foo^ thing) { }) 어디에나 쓰는 것보다 훨씬 덜 복잡하며 C#의 await 구문과 매우 유사합니다.

다음은 기본 런타임 구성 요소 프로젝트의 예(idl + hpp + cpp)입니다.

namespace RuntimeComponent6
{
    runtimeclass Class
    {
        Class();
        Int32 MyProperty;
    }
}

#pragma once

#include "Class.g.h"

namespace winrt::RuntimeComponent6::implementation
{
    struct Class : ClassT<Class>
    {
        Class() = default;

        int32_t MyProperty();
        void MyProperty(int32_t value);
    };
}

namespace winrt::RuntimeComponent6::factory_implementation
{
    struct Class : ClassT<Class, implementation::Class>
    {
    };
}

#include "pch.h"
#include "Class.h"
#include "Class.g.cpp"

namespace winrt::RuntimeComponent6::implementation
{
    int32_t Class::MyProperty()
    {
        throw hresult_not_implemented();
    }

    void Class::MyProperty(int32_t /* value */)
    {
        throw hresult_not_implemented();
    }
}

다음은 작은 co_await 예입니다.

void PrintFeed(SyndicationFeed const& syndicationFeed)
{
    for (SyndicationItem const& syndicationItem : syndicationFeed.Items())
    {
        std::wcout << syndicationItem.Title().Text().c_str() << std::endl;
    }
}

IAsyncAction ProcessFeedAsync()
{
    Uri rssFeedUri{ L"https://blogs.windows.com/feed" };
    SyndicationClient syndicationClient;
    SyndicationFeed syndicationFeed = co_await syndicationClient.RetrieveFeedAsync(rssFeedUri);
    PrintFeed(syndicationFeed);
}

sylveon 에 2020년 11월 20일

안녕하세요,

우리는 귀하의 피드백을 읽고 문제점에 대해 기록하고 있습니다.

@ericleigh007 XAML Designer는 고객 피드백을 수집한 후 개발자의 내부 루프를 개선하는 것이 가장 큰 고객의 고충이었기 때문에 종료되었습니다. Hot Reload와 Live Visual Tree가 상위권에 올랐습니다. In-app-toolbar는 미리보기 3을 만들 수 없다는 또 다른 상단입니다. XAML 디자이너가 언제 될 것인지 명확하지 않다는 것은 맞습니다. 기능 로드맵 생각을 업데이트해야 합니다. 현재 엔지니어링 계획에 따르면 3.0 RTM을 벗어났으므로 3.0 이후입니다.

@pjmlp C++/WinRT에 대한 귀하의 그림과 IDL 추가 필요성에 공감합니다. C++/CX가 이 측면에서 훨씬 더 좋습니다. C++/WinRT 환경 개선은 우리가 해결해야 하는 또 다른 주제입니다. Live Visual Tree 및 Hot Reload와 같은 도구는 C# 및 C++ 모두에서 작동하지만 C++에만 영향을 미치고 별도로 처리해야 하는 특정 항목이 있습니다. 현재 엔지니어링 계획에 따르면 IDL 문제를 해결하는 것은 3.0 RTM에서 벗어났습니다.

@robloo , 우리는 WPF로 작성된 데스크탑 앱을 제공하지 않습니다. C++/WinRT는 WinUI 생태계의 첫 번째 시민입니다. 그것은 우리가 WinUI를 작성하는 데 사용하는 것이므로 적절한 도구와 언어를 dogfood하고 있습니다.

@Chiramisu "비 MSIX 배포 지원"이 무엇을 의미하는지 설명하겠습니다. 오늘은 MSIX를 사용하여 Desktop WinUI 3 앱을 설치하고 실행해야 합니다. 이 기능은 이러한 필요성을 제거하는 것입니다. Desktop WinUI 3 앱을 실행하려면 .EXE에서 두 번만 실행하면 됩니다. 앱을 설치하려면 xcopy를 수행하면 됩니다(아무것도 서명할 필요가 없음). 기본적으로 WiX와 같은 다른 패키징 및 설치 시스템을 사용할 수 있습니다.

marb2000 에 2020년 11월 20일

@marb2000 문제를 인정

지금은 ASP.NET, WFP 및 Win32에 중점을 두고 있습니다. Microsoft가 결국 우리가 UAP => UWP에서와 같이 수동 구성에 끌리고 응용 프로그램을 다시 작성하는 데 지쳤음을 깨닫고 UWP에 대한 후속 조치를 취하기를 바랍니다. 전환, .NET Framework에서 .NET Core로, 또는 예 C++/CX => C++/WinRT.

이것은 Windows 8 도입 이후 지속적인 재작성으로 약간 실망감을 느끼는 Windows 개발자 커뮤니티의 보컬 멤버로서 피드백에 가깝습니다.

pjmlp 에 2020년 11월 20일

👍1

@pjmlp Windows API에 대한 (표준 호환) C++ 래퍼인 C++/WinRT를 왜 비판하는지 잘 모르겠습니다. 도구(및 IDL 파일 등) 없이 C++/WinRT로 응용 프로그램을 작성할 수 있습니다.

MarkIngramUK 에 2020년 11월 20일

@pjmlp Windows API에 대한 (표준 호환) C++ 래퍼인 C++/WinRT를 왜 비판하는지 잘 모르겠습니다. 도구(및 IDL 파일 등) 없이 C++/WinRT로 응용 프로그램을 작성할 수 있습니다.

이것이 바로 문제입니다. Visual Studio에서 C++/CX의 개발 경험에 비해 도구 지원이 전혀 없다는 것입니다.

IDL 파일에 대한 편집 지원이 없으며 intelisense는 고사하고 구문 강조도 지원하지 않습니다. 그런 다음 생성된 번역 단위를 수동으로 복사하거나 병합하라는 지시를 받습니다!

이것은 옛날에 ATL을 하는 것과 같습니다.

ISO C++ 호환성은 신경 쓰지 않습니다. UWP는 어쨌든 Windows 전용이며 언어 확장이 없는 C++ 컴파일러는 없습니다.

WRL의 유일한 사용자였던 WinDev를 제외하고는 이를 진행 상황으로 볼 수 있는 사람이 없습니다.

pjmlp 에 2020년 11월 20일

👍1

@pjmlp ,

ISO C++ 호환성은 신경 쓰지 않습니다. UWP는 어쨌든 Windows 전용이며 언어 확장이 없는 C++ 컴파일러는 없습니다.

대규모 C++ 플랫폼 간 응용 프로그램을 작성하는 우리에게는 표준을 준수하는 것이 큰 문제입니다. C++/CX의 제한은 끔찍했습니다(원시 포인터가 아닌 멤버 변수, 모자! ( ^ ) 등). 현재 대규모 C++/CLI interop 라이브러리가 있으며 문제점이 너무 많아 나열할 수 없습니다.

IDL 파일에 대한 편집 지원이 없으며 intelisense는 고사하고 구문 강조도 지원하지 않습니다. 그런 다음 생성된 번역 단위를 수동으로 복사하거나 병합하라는 지시를 받습니다!

다시 말하지만, C++/WinRT와 도구를 병합하고 있습니다. 그것들은 2개의 별개의 것입니다. C++/WinRT는 WinRT API를 둘러싼 C++ 래퍼입니다. IDL은 코드 생성을 위한 것입니다. 예, 끔찍하다는 데 동의합니다. 너무 나빠서 사용하지 않습니다.

MarkIngramUK 에 2020년 11월 20일

저는 Windows 전용 앱을 작성하고 MSVC가 실패하는 경우 다른 컴파일러를 사용할 수 있기 때문에 여전히 표준 준수에 관심을 갖고 있습니다.

sylveon 에 2020년 11월 20일

@MarkIngramUK

다시 말하지만, C++/WinRT와 도구를 병합하고 있습니다. 그것들은 2개의 별개의 것입니다. C++/WinRT는 WinRT API를 둘러싼 C++ 래퍼입니다. IDL은 코드 생성을 위한 것입니다. 예, 끔찍하다는 데 동의합니다. 너무 나빠서 사용하지 않습니다.

저는 MS-DOS 3.3 이후로 Microsoft 플랫폼을 코딩해 왔으며 1992년 Turbo C++ 1.0과 함께 내 도구 상자에 C++를 추가했으며 C++ 개발과 관련된 대부분의 Borland 및 Microsoft 제품을 사용했습니다. C++/WinRT에 대한 강의가 필요하지 않습니다.

확실히 그렇지 않은 것은 C++ Builder 및 Qt(Qt Designer 포함) 개발자 경험과 일치하며, C++/CX는 25년 후에 결국 따라잡을 것이라는 약속을 보여주었습니다.

그러나 분명히 여기 있는 대부분의 사람들은 ATL 3.0이 포함된 Visual C++ 6.0을 원하고 나머지는 .NET 5, WPF 및 Win32 데스크톱 경험을 고수해야 합니다. 우리는 고려할 가치가 없는 소수자이기 때문입니다. 그렇지 않으면 C++/WinRT는 그대로 밀렸습니다.

솔직히 말해서, C++/WinRT는 이제 거의 4년이 되었고, Microsoft는 구문 강조 및 인텔리센스에 대한 지원조차 제공할 수 없었습니까?

우리 중 일부가 메모장++(구문 강조 표시)로 만든 것, 정말요?

우선 순위가 어디에 있는지 확실히 보여주며 Windows 8 이후로 너무 많은 재작성이 WinUI에 채택될 것입니다.

pjmlp 에 2020년 11월 21일

👍1

@pjmlp , 다시 당신은 잘못된 것에 대해 이야기하고 있습니다. C++/WinRT는 C++이므로 구문 강조 표시가 있고 인텔리센스를 지원합니다. 가지고 있는 다른 C++ 코드와 동일합니다.

MarkIngramUK 에 2020년 11월 21일

IDL 구문 강조 표시 및 IDL에서 .hpp 및 .cpp에 기본 구현을 생성하도록 제안하는 것과 같이 IDE 통합이 더 나을 수 있습니다(예: 헤더에 정의 없이 선언된 함수가 현재 녹색 물결선으로 표시되는 프롬프트) 하나 생성) C++/CX로 돌아가는 것은 순 다운그레이드 IMO입니다. 내가 C++/CX와 함께 사용하는 모든 라이브러리와 공유 코드를 통합하고 내 프로젝트를 C++20에서 C++17로 다운그레이드하려면 너무 많은 노력이 필요합니다(포기하고 싶지 않습니다. 20 나에게 너무 많은 좋은 것을 준다).

C++/WinRT는 또한 프로그램이 작성하지 않고 WinRT 클래스를 사용하기를 원할 때 C++/CX보다 훨씬 덜 방해가 됩니다.

Qt 및 C++ Builder는 대부분 표준을 준수하는 C++에서 경험을 쌓았습니다(Qt에는 Qt MOC라는 IDL과 유사한 것이 있습니다). 이것이 가능하다면 VS도 가능합니다. DevDiv의 누군가로부터 더 많은 사랑이 필요할 뿐입니다.

sylveon 에 2020년 11월 21일

그리고 이전에 @sylveon 에 대해 언급했듯이 다른 컴파일러로 자유롭게 빌드할 수 있습니다(현재 MSVC 및 Clang/LLVM으로 빌드). C++/CX 또는 기타 MS 확장을 사용하면 이것이 불가능합니다.

MarkIngramUK 에 2020년 11월 21일

@MarkIngramUK 및 @syveon

나는 이 스레드를 끝냈고, WinUI 개발자 경험과 도구 개선을 위해 나와 같은 피드백을 환영하지 않는다는 것이 분명합니다.

표준 호환 C++/WinRT로 즐거운 시간을 보내십시오.

pjmlp 에 2020년 11월 21일

'no 케이터링' 오타를 수정하기 위해 편집할 수 있나요.. '지금...'이 되어야 할 것 같습니다.

ericleigh007 에 2020년 11월 21일

@pjmlp 나는 당신이 의미하는 바를 정확히 이해한다고 생각합니다.

1년 정도 전에 UWP C++/CX 코드를 C++/WinRT로 이식하는 아이디어를 포기했습니다. 이식에 대한 인센티브는 MSVC++에 내가 약 18개월 전에 보고했지만 단순히 수정하는 데 관심이 없는 버그가 포함되어 있기 때문에 Clang을 사용하여 UWP 앱을 컴파일할 수 있다는 것이었습니다.

그러나 Visual Studio는 Clang을 사용하여 UWP 앱 빌드를 지원하지 않는 것으로 나타났습니다. 훌륭합니다. C++/WinRT의 "ISO C++ 전용" 이점이 바로 사라졌습니다. 여기에 C++/WinRT를 통해 C++/CX 코드 기반을 이식하는 것은 20년 전으로 시간 여행을 하는 것과 같다는 사실을 추가합니다.

저는 본질적으로 Android/iOS 앱을 Windows로 이식하는 것을 포기했습니다. Android/iOS용 개발 외에 Windows 앱 개발인 clusterfuck을 처리하는 것은 우리와 같은 작은 상점에서 단순히 실현 가능하지 않습니다.

@MarkIngramUK 도구가 매우 중요하다는 점을 이해하지 못하는 것 같습니다. 모든 사람이 적절한 툴링 부족을 보완할 수 있는 자원이 있는 것은 아닙니다.

이제 내 말을 마친 후 내 의견은 다음과 같습니다.

C++/CX와 함께 WinUI 3 사용을 지원합니다. 자체 도구를 구축할 리소스가 없는 회사에서 C++/WinRT용 도구를 사용할 수 있게 되면 C++/WinRT로 전환하는 것이 좋습니다. 지금은 확실히 아닙니다.

ackh 에 2020년 11월 21일

👎1 👍1

@pjmlp 나는 당신이 의미하는 바를 정확히 이해한다고 생각합니다.
1년 정도 전에 UWP C++/CX 코드를 C++/WinRT로 이식하는 아이디어를 포기했습니다. 이식에 대한 인센티브는 MSVC++에 내가 약 18개월 전에 보고했지만 단순히 수정하는 데 관심이 없는 버그가 포함되어 있기 때문에 Clang을 사용하여 UWP 앱을 컴파일할 수 있다는 것이었습니다.
그러나 Visual Studio는 Clang을 사용하여 UWP 앱 빌드를 지원하지 않는 것으로 나타났습니다. 훌륭합니다. C++/WinRT의 "ISO C++ 전용" 이점이 바로 사라졌습니다. 여기에 C++/WinRT를 통해 C++/CX 코드 기반을 이식하는 것은 20년 전으로 시간 여행을 하는 것과 같다는 사실을 추가합니다.
저는 본질적으로 Android/iOS 앱을 Windows로 이식하는 것을 포기했습니다. Android/iOS용 개발 외에 Windows 앱 개발인 clusterfuck을 처리하는 것은 우리와 같은 작은 상점에서 단순히 실현 가능하지 않습니다.
@MarkIngramUK 도구가 매우 중요하다는 점을 이해하지 못하는 것 같습니다. 모든 사람이 적절한 툴링 부족을 보완할 수 있는 자원이 있는 것은 아닙니다.
이제 내 말을 마친 후 내 의견은 다음과 같습니다.
C++/CX와 함께 WinUI 3 사용을 지원합니다. 자체 도구를 구축할 리소스가 없는 회사에서 C++/WinRT용 도구를 사용할 수 있게 되면 C++/WinRT로 전환하는 것이 좋습니다. 지금은 확실히 아닙니다.

궁금해서 18개월 전에 보고된 버그는 무엇입니까? 어딘가에 링크가 있습니까?

ericleigh007 에 2020년 11월 21일

안녕 미구엘,
___Android용 Outlook에서 회신한 후 끔찍한 상황을 수정하기 위해 수정했습니다.__

Winrt 플랫폼이 WINUI를 개발하는 데 사용하는 플랫폼이라고 말씀하셨기 때문에 미리 보기 및 릴리스에 대한 목표를 명확하게 만들 수 있는 아이디어가 있었습니다.

IDL이 작성하고 파일을 수동으로 복사하는 경우 무리를 호출하고 도구에서 작업 중인 상태와 일치하도록 수정하는 이 문서를 가져옵니다.

https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/binding-property

여기가 아니라면 다른 곳에서 논의할 수 있을 것입니다.

그건 그렇고, 특히 XAML 스튜디오와 같은 존재하는 도구를 사용하여 XAML 디자이너에 대해 확신을 갖게 되었습니다. (만약 IValueConverter 사용하는 XAML을 성공적으로 로드할 수 있도록 일부 코드를 로드할 수만 있다면 ...

ericleigh007 에 2020년 11월 21일

이전 게시물에서 언급했듯이 C++/WinRT 자체의 C++17 표준 준수는 대부분의 경우 Microsoft의 Visual C++ 컴파일러로 컴파일해야 하기 때문에 C++/CX 코드 기반을 C++/WinRT로 마이그레이션할 인센티브가 없습니다. 그래도. 컴파일러를 교체할 수 있다면 완전히 바뀔 것입니다.

그러나 Visual Studio는 Windows 런타임 구성 요소에 대한 컴파일러 전환을 지원하지 않습니다. 특히 이 블로그 게시물에 설명된 대로 데스크톱 앱에서 지원되기 때문에 이것이 지원되지 않는 이유는 제게 미스터리입니다. Clang 지원은 Windows 런타임 구성 요소에 대해 실제로 확장되어야 합니다.

Clang을 사용하여 Android 및 iOS용 코드 기반을 컴파일하고 있습니다. Clang을 사용하여 Windows용 코드 기반을 컴파일할 수 있다는 것은 실제로 C++/CX에서 마이그레이션해야 하는 매우 좋은 이유입니다. 이에 대한 Visual Studio 기능 요청 이 이미 존재하지만 Visual Studio 팀에서 지금까지 아무 것도 수행하지 않았습니다.

C++ 표준 준수가 있고 데스크톱 앱용 Visual Studio에서 Clang 지원이 있습니다. 따라서 마지막 단계를 수행하고 Windows 런타임 구성 요소에 대한 Clang 지원을 제공하여 C++/CX에서 마이그레이션하는 실제 이유를 제공하십시오.

ackh 에 2020년 11월 29일

표준 준수는 소비자에게 유용합니다. 생산자가 MSVC를 고수한다고 언급했듯이. CLToolExe 속성을 .vcxproj 파일의 clang-cl 경로로 설정하여 clang-cl을 "강제"하는 방법이 있습니다(이는 LLVM 도구 세트에서 이미 효과적으로 수행하고 있음 ). UWP 프로젝트에서 이것이 얼마나 잘 작동하는지 잘 모르겠지만 시도해 볼 가치가 있습니다.

XAML 및 C++/WinRT 생산자 도구가 데스크톱 프로젝트에서 잠금 해제되면 나에게도 문제가 줄어들 것입니다.

sylveon 에 2020년 11월 29일

@ackh Clang 11에서 빌드할 UWP 프로젝트가 있습니다.

내가 한 일은 다음과 같습니다.

프로젝트를 언로드하고 <Project> 아래의 첫 번째 지시문으로 다음 지시문을 추가합니다.

  <PropertyGroup>
    <CLToolExe>C:\Program Files\LLVM\bin\clang-cl.exe</CLToolExe>
  </PropertyGroup>

<AdditionalOptions>%(AdditionalOptions) /bigobj</AdditionalOptions> 를 <AdditionalOptions>%(AdditionalOptions) /bigobj -Xclang -std=c++20 -mcx16</AdditionalOptions> 바꾸기
<PreprocessorDefinitions>WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions> 를 <PreprocessorDefinitions>_SILENCE_CLANG_COROUTINE_MESSAGE;WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions> 바꾸기
바로 아래에 <ModuleOutputFile />
프로젝트 다시 로드
짓다

그러나 몇 가지 함정이 있습니다.

사용하지 않는 인수에 대한 몇 가지 경고가 표시됩니다. 사용하지 않는 인수를 변경/제거하여 문제를 해결할 수 있습니다.
어떤 이유로 Clang은 32비트로 64비트 개체 파일을 내보냅니다. CLI에 -m32 를 추가하기만 하면 됩니다.
Clang은 아직 코루틴을 완전히 구현하지 않았기 때문에 코루틴을 사용할 수 없습니다.
VS는 증분 및/또는 병렬이 아닌 앱을 실행할 때마다 전체 단일 스레드 다시 빌드를 수행합니다.

이에 대한 관심을 끌기 위해 https://github.com/microsoft/ProjectReunion 에서 문제를 여는 것이 좋습니다.

sylveon 에 2020년 11월 30일

@sylveon 이 지침을 게시

ackh 에 2020년 11월 30일

Microsoft-ui-xaml: WinUI 3.0 개발자 경험 및 도구 - 입력 필요

WinUI 3.0 개발자 경험 및 도구 - 입력 필요

항목은 다룹니다

데스크탑 앱의 WinUI

템플릿

열린 질문

언어 지원

이주

열린 질문

포장

가장 유용한 댓글

모든 212 댓글

아무도 이것을 접는 방법을 말해 줄 수 있습니까?

템플릿

이주

기타

데스크탑 앱의 WinUI

템플릿

언어 지원

포장

이주

압형

이주

압형

템플릿

관련 문제