Xamarin.forms: Uwp Xamarin.Forms.Shell

현재 셸 지원은 Android 및 iOS에 대해서만 제공됩니다. 우리는 잠재적인 향후 UWP 지원에 대한 피드백을 지속적으로 평가하고 있으며 향후 더 많은 정보가 제공되는 대로 제공할 것입니다.

저는 일반적으로 휴대폰 사용자에게는 iOS 및 Android를 사용하고 태블릿 및 데스크톱 사용자에게는 UWP를 사용합니다. 따라서 Windows 사용자의 참여를 유지하려면 UWP 지원이 매우 중요합니다.

뭐?? MS는 실제로 자체 플랫폼을 버리고 있습니다. 이것은 슬픈 소식입니다!

UWP 지원이 제공될 시기에 대한 가시성이 없나요? 아니면 이미 결정이 내려졌습니까?

UWP에 대한 셸 지원 - 제발!

셸에 대한 UWP 지원도 보고 싶습니다.

우리 회사의 경우 UWP가 매우 중요합니다. 고객이 Windows 태블릿을 일부 Android 휴대폰과 함께 사용하여 작업을 수행하기 때문입니다. UWP 지원이 누락된 경우 Shell로 마이그레이션할 수 없습니다.

동의함 -- UWP 호환성을 통해 모바일 구현과 함께 Windows 태블릿 기능을 베이크 인할 수 있습니다. 나는 그것 없이 이것을 완전히 별도로 코딩해야 할 것입니다. 왝! UWP 호환성은 필수입니다!

나는 아직 Shell을 사용하지 않았기 때문에 그것이 의미가 있는지 모르겠습니다. 하지만 UWP 구현을 위해 앱의 다른 모든 요소(셸 제외)를 사용하는 방법이 있을 수 있습니다. 결국 TabbedPage와 MasterDetailPage를 사용하면 동일한 결과를 얻을 수 있을 것 같습니다.

또한 Shell과 함께 UWP를 사용할 수 있는 기능에 대해 투표할 것입니다.

UWP 제발... 또는 우리가 몇 년 동안 의존할 수 있는 Microsoft UX API의 일부 버전. "나중에 지원할 수 있으면 알려 드리겠습니다"라는 이러한 접근 방식은 의미가 없습니다.

예, UWP 또는 기타 모든 것이 이를 지원하지만 더 중요한 것은 다음과 같습니다.

해당 인증 없이는 Shell로 이동할 수 없습니다.

UWP 뿐만 아니라 MacOS도 부탁드립니다.

UWP가 개발자가 여전히 널리 사용하는 플랫폼일 뿐만 아니라 Android 및 iOS 기반 XF 앱을 시작하고 실행하는 가장 빠른 방법이라는 것을 깨달았는지 모르겠습니다. 그에 비해 Android와 Mac 세계 모두에 제공되는 에뮬레이터는 엄청나게 느리고 문제가 발생하기 쉬우며 끔찍한 인증 경험에 대해 이야기하거나 여전히 실제 Mac을 사용해야 하는 상황에 대해 이야기하지 맙시다. 따라서 실제 개발을 대체할 수는 없지만 UWP 앱은 작업을... 완료하는 빠르고 쉽고 포괄적인 방법을 제공하여 개발자 생산성을 높입니다. 그런 다음: iOS 및 Android에서도 앱을 실행하고 실행하는 데 필요한 작업을 수행합니다.

UWP에 대한 셸 지원을 추가하시겠습니까?

https://github.com/xamarin/Xamarin.Forms/pull/6015

@Mephisztoe 는 정말 훌륭한 생산성 도구이며, 물론 Windows에서 실제로 앱을 사용할 수 있도록 하는 옵션도 좋은 플러스

Xamarin.Forms를 모바일 플랫폼으로만 분류하지 마세요. 특히 UWP뿐만 아니라 WPF 및 GTK#에 대한 지속적인 지원을 보고 싶습니다.

따라서 기본적으로 현재 Xamarin Forms의 세 플랫폼 모두에 대한 교차 플랫폼인 앱이 있는 사람은 이러한 기능을 업데이트하고 사용할 수 없습니다. UWP용 Xamarin Forms에 대한 향후 개발이 발생하지 않는 경우 교차 플랫폼 목록에서 UWP를 제거하지 않는 이유는 무엇인가요?

플랫폼마다 우선 순위가 항상 다릅니다. 결국 "일곱 플랫폼 모두"가 아니라 "세 플랫폼 모두"라고 말씀하셨습니다.

@GalaxiaGuy 맞습니다. 제가 7개의 플랫폼을 말한다면 가상의 플랫폼을 구성할 것이라고 생각한다면 3개의 플랫폼 모두를 말한 것입니다. Xamarin.Forms 문서에 따르면:

Xamarin.Forms
Xamarin.Forms는 .NET 개발자를 위한 완전한 플랫폼 간 UI 도구 키트를 제공합니다. Visual Studio에서 C#을 사용하여 완전한 기본 Android, iOS 및 유니버설 Windows 플랫폼 앱을 빌드합니다.

그리고 읽어보기에는 다음과 같이 나와 있습니다.

Xamarin.Forms는 iOS, Android, Windows 및 macOS용 네이티브 앱을 완전히 C#으로 빠르게 빌드하는 방법을 제공합니다.

그렇다고 GTK, WPF 및 Tizen도 지원하지 않는다는 의미는 아닙니다.

그런 플랫폼이 UWP보다 덜 중요할 수도 있다는 점에는 동의하지만 UWP가 iOS 및 Android보다 덜 중요하다고 생각하는 사람들이 많이 있습니다.

나는 일반적으로 그 감정에 동의하며 UWP에 없는 새로운 기능을 스스로 무시해야 합니다.

참고로 릴리스 정보를 잘못 읽지 않는 한 4.1 미리 보기에서 Tizen에 대한 ShellRenderer 구현이 있는 것 같습니다. UWP에 대한 언급이 없습니다.

@dotMorten 의 pull 요청이 병합되는 데 시간이 걸리면 누군가가 해당 구현을 가져와 공식 지원을 받을 때까지 커뮤니티에서 관리하는 별도의 "시험판" NuGet 패키지로 이동할 수 있습니다. 그렇게 하면 Xamarin.Forms의 전체 시험판 또는 사용자 지정 빌드를 사용하지 않고 사용할 수 있습니다. 공식적인 지원을 받지 못하면 리포지토리가 이미 설정되어 커뮤니티가 인수할 수 있습니다.

더 빨리 움직이지 못해서 죄송합니다. 나는 마스터와 동기화할 때 약간의 회귀를 겪었고, 나는 일과 가족과 관련된 것들로 완전히 휩쓸려 정말로 앉아서 그것을 시도하고 해결할 시간이 많지 않았습니다. 그러나 저는 제 지사에 대한 PR을 받게 되어 기쁩니다.

또한 UWP에서 사용 가능한 즉시 셸을 사용할 것입니다. 위와 같은 문제가 있습니다. Android와 Windows가 있는 태블릿, 휴대폰 및 노트북이 혼합되어 있습니다. 그리고 우리는 또한 최고의 개발 환경이 UWP라고 생각합니다.

이 문제는 내가 XF를 포기한 주된 이유 중 하나입니다. 고객에게 데스크탑과 모바일은 동일한 우선 순위를 갖습니다.

아직 하지 않은 말을 뭐라고 할까..

그래서 그것으로 시작!
UWP 지원은 Microsoft의 선택 사항이 아닙니다. 정말 이 사실을 알려야 합니까?

@papiermache 행동 강령은 이 프로젝트의 모든 커뮤니케이션, 문제 및 의견에 적용됩니다.

또한 이것을 개발자에 대한 MS Xamarin 약속의 테스트로 취급합니다. MS 측에서 무게를 측정할 준비가 된 사람이 있습니까?

죄송합니다. 더 많은 생각을 하게 될 것입니다. 하지만 UWP 지원이 없다는 사실에 완전히 놀랐습니다. UWP가 처음부터 포함된 플랫폼이 아닐 것이라는 생각조차 하지 못했습니다. 약간 뒤틀리게 하다.

보낸 사람: 제레미 알림 @
보낸 날짜: 2019년 8월 16일 오후 2:28
받는 사람: xamarin/Xamarin.Forms [email protected]
참조: 릭 피 오베 산 @noreply.github.com
제목: Re: [xamarin/Xamarin.Forms] Uwp Xamarin.Forms.Shell(#5593)

@papiermache https://github.com/papiermache 행동 강령은 이 프로젝트의 모든 커뮤니케이션, 문제 및 의견에 적용됩니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
직접이 이메일에 회신 볼을 GitHub의에 https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=ABJC5GJKYHEGIOR3P2UIKX3QE4EVLA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PT3PQ#issuecomment-522141118 , 또는 스레드 음소거 https://github.com/을 알림/구독 취소-인증/ABJC5GKCHSPBRJ5JNNEVD5LQE4EVLANCNFSM4G7ANE7A .

안녕하세요 @dotMorten , 업데이트할 수 있습니까? 여전히 UPW+Shell이 ​​작동하도록 시도할 계획입니까? 그것이 친절과 커뮤니티의 행동임을 이해하십시오. :) 귀하의 노력이 Shell+UWP를 작동시키는 데 가장 가까운 것 같아서 궁금합니다. Microsoft가 Xamarin을 통한 Windows 지원에서 멀어지는 것처럼 보이는 것에 여전히 완전히 신비화되어 있습니다. 다른 모든 선함에 감사하지만 여전히 당혹스럽고 실망스럽습니다.

죄송합니다. 지금은 불타버린 상태여서 다시 방문하지 않았습니다. 최신 버전과 병합하면 많은 회귀가 발생했고 다시 속도를 높일 시간도 에너지도 없었습니다. 또한 변경해야 하고 XF 팀의 광범위한 구매가 필요한 몇 가지 사항을 확인했지만 "꼭 살펴보겠습니다" 이상의 지원을 받지 못하고 결국 사라졌습니다. 일반적으로 XF 팀으로부터 받은 지원과 피드백은 격려에 불과했지만 후속 조치가 약간 부족했습니다. 여전히 내가 한 작업에 대한 피드백을 기다리고 있지만 이 시점에서 아마도 너무 구식일 것입니다. 곧 다시 시작할 수 있는 시간과 에너지를 갖게 되길 바랍니다.

이 문제는 현재 가장 댓글이 많이 달린 열린 ​​항목 상위 10개에 속하지만 완료할 로드맵에는 없습니다.

@pauldipietro 이에 대한 업데이트를 받을 수 있습니까? UWP 지원이 더 이상 XF 팀의 우선 순위가 아니라는 신호를 보내는 것 같습니다. 그것이 사실이라면 우리가 그것에 대한 계획을 세울 수 있도록 알려주십시오.

감사 해요

동의합니다. XF에 Windows 지원이 포함되지 않는지 알고 싶습니다. 그렇지 않다면 왜 안되는지 나도 알고 싶습니다. 그들은 UWP 이외의 "다음" Windows UX 스택이 무엇인지 알고 있고 주기를 낭비하고 싶지 않습니까? Blazor/HTML이 다음 작품이 될까요? 그렇다면 전환할 수 있도록 알려주세요... 아마도 uno 플랫폼으로?

보낸 사람: Scott Kuhl [email protected]
보낸 날짜: 2019년 8월 22일 목요일 오후 1:21:22
받는 사람: xamarin/Xamarin.Forms [email protected]
참조: David Gerding [email protected] ; 댓글 [email protected]
제목: Re: [xamarin/Xamarin.Forms] Uwp Xamarin.Forms.Shell(#5593)

이 문제는 현재 가장 댓글이 많이 달린 열린 ​​항목 상위 10개에 속하지만 완료할 로드맵에는 없습니다.

@pauldipietro https://github.com/pauldipietro 업데이트를 받을 수 있나요? UWP 지원이 더 이상 XF 팀의 우선 순위가 아니라는 신호를 보내는 것 같습니다. 그것이 사실이라면 우리가 그것에 대한 계획을 세울 수 있도록 알려주십시오.

감사 해요

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
직접이 이메일에 회신 볼을 GitHub의에 https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=AAD7YD4EYE5XBBSXIR6MGV3QF3KKFA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD456VUI#issuecomment-524020433 , 또는 스레드 음소거 https://github.com/을 알림/구독 취소-인증/AAD7YD42CJSV4KS5ZFWWJU3QF3KKFANCNFSM4G7ANE7A .

솔직히 말해서 가장 좋은 방법은 실제로 XF를 Uno Platform으로 대체하는 것입니다...

Xamarin은 그들의 목표가 데스크톱이나 노트북이 아닌 대부분 모바일 장치(전화, 태블릿, 시계)임을 분명히 했습니다.

그들은 UWP 자체를 지원하고 유지 관리하는 데 관심이 없으므로 고객에게 추천하는 것이 좋지 않습니다.

내 요구 사항을 명확히 하고 싶습니다. Xamarin Forms에는 _UWP_가 필요하지 않습니다. Xamarin Forms용 _일부 Windows 대상_이 필요합니다. UWP는 가장 실행 가능한 후보처럼 보입니다. Microsoft가 결국에는 데스크톱용 HTML 및 Blazor 클라이언트로 이동할 것이라고 추측해야 한다면 Windows 이후 세계에서 가장 광범위한 UX 범위를 제공할 수 있기 때문입니다. 구성 가능한 셸(xf 셸 아님) 경로에 더 적합할 수도 있습니다. UX의 Windows 측면에 대한 일관된 로드맵이 없는 상황에서는 그들이 계획하고 있는 다른 것을 상상할 수 없습니다.

그러나 분명히 "WE DON'T AND WON'T DO WINDOWS"라는 굵은 글씨로 발표하지 않고 Xamarin에 대한 Windows 지원을 중단하는 것은 최소한 정말, 정말 불친절합니다. 그것은 "오래된 마이크로소프트"의 울림입니다.

@davidortinau et al: "XF Shell + Windows에 대한 커뮤니티 지원"( @dotMorten 의 최신 게시물 참조)이 이제 효과적으로

Xamarin의 새롭고 멋진 모든 것에 대해 매우 감사합니다. 하지만 Xamarin을 사용하는 Windows 대상의 미래 생존 가능성에 대해 더 솔직한 답변이 필요합니다.

변경해야 하고 XF 팀의 광범위한 구매가 필요한 몇 가지 사항

이 중 하나가 우리가 이 PR에 종속성으로 가져오기를 희망하는 WinUI와 관련이 있다는 것을 알고 있습니다.
https://github.com/xamarin/Xamarin.Forms/pull/7214

해당 PR은 16299 호환성을 유지하며 내 테스트에서 nuget에 포함되어 있고 사용자가 WinUI를 설치할 필요가 없을 때 훌륭하게 작동합니다. 확인하려면 여전히 VM에서 16299를 회전해야 하지만 낙관적입니다. @dotMorten 이

여기 그 덩어리가 있습니다.

Xamarin.Forms.4.3.0.1853.zip

다른 사람이 우리를 위해 그것을 테스트하고 정말로 도움이 될 문제가 있으면 알려주십시오. 기본 UWP 템플릿으로 테스트했으며 충돌 없이 잘 작동합니다.

현재 내가 보는 경로는

• WinUI 종속성을 처리하도록 #7214 병합
• UWP Shell PR 재기반 가져오기
• Morten은 이미 Gastropods와 함께 작동하고 있으므로 몇 가지 더 많은 샘플(주로 Xaminals)로 테스트하고 싶습니다. 일단 작동하고 필요한 코드 정리 변경을 수행하면 병합합니다.

해당 경로에서 누락된 것이 있으면 알려주시면 해결하도록 노력하겠습니다. 따라서 Xaminals에 대한 리베이스와 검증만 하면 됩니다.

@퓨어윈 ,
제공한 Xamarin Nuget으로 App132.zip을 실행할 수 있습니다. 앱이 잘 작동하는 것 같습니다 ... 목록 컨트롤에 타임스탬프 요소를 추가해야 한다고 가정합니다. 상단의 버튼과 새로고침으로 끌어오기 동작은 모두 요소를 추가합니다.

내가 찾고 있는 것이 무엇인지 잘 모르겠지만 당신의 노력에 감사하고 내가 할 수 있는 한 노력하고 도울 것입니다.

데이브 지

@PureWeen WinUI 와 함께 발전하고 계시다니 반갑습니다. WinUI가 전이적으로 추가되지 않은 종속성을 추가하고 있었기 때문에 WinUI에 대한 종속성은 저에게 잘못된 동작을 생성했습니다. VS2019를 사용하는 경우 수정할 수 있지만 WinUI가 아직 해당 기능을 활용했는지 확실하지 않습니다(그리고 여전히 VS2017 사용자에게 영향을 미치지만 최소한 해결 방법이 있음).
또한 WinUI에는 많은 골치거리를 야기하는 버그가 있었지만 최근에 내가 기록한 버그 중 일부가 수정되었다는 것을 알게 되었기 때문에 모두 고무적입니다. 7214가 들어오면 저에게 핑을 보내십시오. 그러면 이 노력을 시작하겠습니다.
또한 리베이스에 대한 도움을 원합니다. 저번에 했을 때 이 홍보를 완전히 망쳐버렸어요 :-)

@dotMorten 잘 들리

VS 2017에서 위에 포함된 앱을 테스트했고 저에게 효과적이었으므로 우리는 그 부분에서 괜찮다고 생각합니다.

내가 찾고 있는 것이 무엇인지 잘 모르겠지만 당신의 노력에 감사하고 내가 할 수 있는 한 노력하고 도울 것입니다.

가장 중요한 것은 기본 UWP 프로젝트에 너겟을 추가하고 모두 제대로 컴파일되고 실행되는지 확인하는 것입니다.

WINUI 종속성을 추가해도 두통이 발생하지 않는다는 것을 확인하려고 합니다 :-)

VS 2017에서 위에 포함시킨 앱을 테스트했습니다.

프로젝트 헤드에 WinUI도 추가하지 않고? 이것이 내가 찾은 문제입니다. 사람들이 WinUI에 의존하는 XF 버전으로 업그레이드하면 WinUI에 종속성을 수동으로 추가하지 않고는 작동하지 않을 것입니다. IMHO는 획기적인 변화입니다. WinUI는 암시적으로 작동하도록 패키지를 변경할 수 있지만 NuGet 5.0 기능에 의존하기 때문에 VS2019가 필요합니다.

WinUI에 로그인한 문제는 다음과 같습니다. https://github.com/microsoft/microsoft-ui-xaml/issues/596#issuecomment -524187369

VS2019 사용자가 수동으로 추가 종속성을 추가할 필요가 없도록 최소한 해결하기 위해 빠른 PR을 만들 수 있습니다.

app123을 테스트했을 때 VS2019와 함께 추가했습니다.

프로젝트 헤드에 WinUI도 추가하지 않고?

예, 위에서 링크한 프로젝트는 VS2017 내부에서 열 수 있으며 잘 컴파일되고 실행됩니다. UWP 헤드에 WinUI nuget을 추가하지 않았으며 nuspec 내부의 종속성으로만 표시됩니다.

나는 그것이 어떻게 작동하는지 정말로 이해하지 못한다. 추가해야 하는 스타일과 패키지와 함께 설치해야 하는 추가 appx 프레임워크 패키지가 있으며 모두 .targets에 의해 수행됩니다. 프레임워크 패키지가 이미 컴퓨터에 설치되어 있습니까?

Visual Studio Magazine은 특히 이 문제를 다루었습니다. 마이크로소프트, 공식 답변이 필요한 시점입니다.

https://visualstudiomagazine.com/articles/2019/08/23/xamarin-forms-4-2.aspx

@dotMorten 며칠 동안 외출을 하지 않았지만 돌아오면 살펴보겠습니다. 또한 WinUI 팀에 연락하여 검토했습니다.

이 대상은 VS 2017에서 테스트할 때 전이적으로 잘 실행됩니다.
https://github.com/microsoft/microsoft-ui-xaml/blob/8f8cd0fe32754cfcd83dafb2fc8539703b6aec26/build/NuSpecs/MUXControls-Nuget-Common.targets#L6

다음은 로컬 양식 프로젝트의 설정을 재정의할 수 있는 업데이트된 너겟입니다.
Xamarin.Forms.4.3.0.1853.zip

<SkipMicrosoftUIXamlCheckTargetPlatformVersion>false</SkipMicrosoftUIXamlCheckTargetPlatformVersion>

Forms 프로젝트에서 사람들을 놀라게 하지 않도록 이것을 true로 강제했습니다.

https://github.com/xamarin/Xamarin.Forms/pull/7214/files#diff -5e6292d5925c776aa9aa6d6f8c63ddf6R19

@PureWeen 이것은 다음 줄을 명시적으로 추가하지 않고 작동해야 하는 비트입니다(모든 사용자가 프로젝트 헤드도 업데이트해야 하기 때문에).

나는 당신이 그것이 효과가 있다고 말하고 있다고 생각하지만 우리가 같은 페이지에 있는지 확인하십시오.

이것이 수용 가능한 주요 변경 사항이라고 생각할 수도 있지만 최근에 다른 종속성으로 인해 이러한 일이 발생했으며 업그레이드 경로가 새 XF 버전을 선택하는 것만큼 깨끗하지 않기 때문에 많은 사람들을 실망시켰습니다.

Re: Xamarin Forms용 데스크탑/노트북/태블릿 대상의 필요성

기업 환경에서 모바일 앱을 구축하는 사람들에게는 Android/iOS 기반과 동일한 기본 코드 기반에서 "동일한" 데스크톱/노트북 실행 파일을 생성하는 기능이 필수적입니다. Windows 전용일 필요는 없지만(HTML/JS와 같은 브라우저 기반 대상도 적합함) 대다수의 사용자는 Windows 데스크톱/노트북 + iPhone/Android 전화를 사용하므로 Windows 실행 파일은 대부분 괜찮습니다.

우리는 조직 내에서 모바일 앱을 사용할 수 있게 만들 때 대부분의 사용자가 먼저 랩톱/데스크톱에서 사용해 보고 싶어한다는 사실을 알게 되었습니다. 그것은 그들의 전화에 있습니다. 또한 특정 순간에 작업하는 위치에 따라 데스크톱이나 장치에서 데이터를 입력하거나 결과를 쿼리할 수 있는 경우 사용자 동의(및 피드백)를 받는 것이 훨씬 더 효과적입니다.

Xamarin Forms는 이러한 시나리오에서 잘 작동하며 Shell 및 CollectionView를 사용하고 싶지만 데스크톱/노트북 작업 유사 제품을 생성하는 데 사용할 수 있을 때까지는 선반웨어입니다...

@dotMorten 따라서 예외가 표시되지 않는 이유는 WinUI가 너겟에 대한 종속성으로 있으므로 UWP 헤드에 XF를 설치하면 WinUI가 함께 이동하여 대상을 적용하기 때문입니다.

이렇게 하면 XF 패키지 자체가 작동하기 위해 UWP 헤드 프로젝트에 설치되어야 합니다. netstandard 프로젝트에만 XF를 설치하여 위의 예를 테스트했으며 예외를 다시 생성할 수 있었습니다.

이 문제에 대해 조금 더 이야기했습니다.
https://github.com/xamarin/Xamarin.Forms/issues/4126

이것은 사람들이 UWP 헤드 프로젝트가 아닌 공유 라이브러리에 XF만 설치한 경우 중단됩니다. 그래서 우리는 이것에 대해 우리가 무엇을 하고 싶은지 알아보기 위해 이것에 대해 약간 논의해야 합니다.

@pureween 알았어. 그때도 같은 것을 보게 되어 기쁩니다. 토론에서 고려해야 할 몇 가지 사항:

• WinUI의 내 PR이 병합되면 VS2017 사용자에게만 영향을 미칩니다(그러나 팀에서 둘 다 사용하고 일부 사용자에게만 영향을 주는 경우 이상해질 수 있음).
• Init() 중에 이것을 감지하고 사용자에게 정확히 무엇을 해야 하는지 알려주는 오류를 발생시켜 고통이 그렇게 나쁘지 않을 수 있습니다.
• 나는 XF에 아직 존재하지 않는 경우 참조 프로젝트에 종속성을 추가하는 대상 파일이 있지만
  이상한 개발자 경험을 만듭니다.
• WinUI가 플랫폼에서 분리되면 모든 UWP 프로젝트는 항상 이 종속성을 사용합니다(그러나 그때까지는 VS2017이 지원되지 않을 수 있음).
  
  
  
  • 이 변경으로 더 낮은 버전의 Win10을 지원할 수 있으며 이를 정당화할 수 있는 부가 가치를 생성할 수 있습니다.
  
  
  • 팀에 따르면 어쨌든 UWP를 실제로 사용하는 사람은 아무도 없기 때문에 아무도 눈치채지 못할 것입니다 😜 j/k
  
  

또 다른 가능한 접근 방식: 초기화 중에 WinUI가 참조되는지 감지하되 앱은 실행하도록 둡니다. WinUI에 의존하는 모든 렌더러는 대신 이러한 새로운 기능의 사용자에게만 영향을 미치므로 던집니다. 따라서 이야기는 "Shell 또는 PullToRefresh를 사용하려면 WinUI에 대한 참조도 추가해야 합니다(VS2017에 있는 경우)"가 됩니다.

@dotMorten Shell을 UWP로 가져오기 위한 모든 노력에 감사드립니다! 이것은 매우 필요하며 핵심 Xamarin 팀에서 해결해야 합니다.

다음은 CV 및 Shell을 사용하여 UWP에서 실행되는 Xaminals의 맛입니다!!!

훌륭한 일!

멋진 직업. 엔터프라이즈급 애플리케이션을 구축하기 위한 프레임워크가 나오는 즉시 포함할 것입니다.

잘했습니다. 향후 내 앱 릴리스에서 시도해 보겠습니다. ;)

예, Xamarin이 해냈습니다! 나는 우리가 Uno로 이사한다는 한 사람을 읽었습니다. 아니!!!! Xamarin은 우리에게 훌륭했으며 swift + Java를 배우기 위해 많은 시간을 절약했습니다. 인내심을 갖고 팀을 지원하자

#6015에 의해 폐쇄

수고하셨습니다. 모든 팀 <3에 감사드립니다.

훌륭한 작품, 정말 감사합니다!

확인 이상한 일이 일어나고 있습니다. 4.3.0.947036을 사용하도록 프로젝트를 업그레이드했습니다. 이제 form.init를 호출할 때 프로젝트가 실패합니다.
'Windows 런타임 유형 'Microsoft.UI.Xaml.Controls.XamlControlsResources를 찾을 수 없습니다.

매우 이상한 점은 현재 XamlTypeInfo.g.cs에서 발견된 코드의 양입니다. 이전 버전의 Xamarin에서는 항목이 13개였지만 지금은 43개가 넘습니다. 프로젝트에 Win.UI Nuget을 설치했는데 여전히 그렇습니다. 도움이되지 않습니다. 모든 아이디어

@abrantie1z - (비록 주제가 아니지만 언급할 것이라고 생각했습니다.) Uno와 Xamarin Forms는 더 이상 상호 배타적인 선택일 필요가 없습니다. - https://platform.uno/xamarin-forms/ 및 https:/ 참조 /visualstudiomagazine.com/articles/2019/09/19/uno-platform-2.aspx 주의 사항: Uno를 사용하지 않았기 때문에 이 지원이 얼마나 강력한지 모르겠습니다. 그러나 더 많은 사람들이 브라우저에서 XF에 관심을 갖게 하는 것은 좋은 일입니다.