몇 년 전 처음 WPF 앱을 포팅하기 시작했을 때 나는 당신의 좌절 수준이었습니다. 그래서 나는 확실히 당신의 마음을 이해합니다. 그 이후로 약간의 진전이 있었고 당신이 말했듯이 WinUI 팀은 정말로 노력하고 있습니다.

내 관점에서 볼 때 우리가 해결할 수 없는 근본적인 디자인 문제가 있습니다. WinRT는 C++ 및 JavaScript와 직접 상호 운용되어야 하기 때문에 기술적으로 장애가 있습니다( 여기 에 예와 다른 것이 있음 ). 제네릭과 같은 많은 고급 개념과 실제로 잘 작동하지 않습니다. 물론 이 아키텍처에는 한 가지 큰 이점이 있습니다. 이제 모든 Windows에서 동일한 WinRT API를 공유할 수 있습니다.

WinRT는 Sinofsky의 Windows 팀에서도 수행했습니다. 즉, 그들은 자신의 세계에 살았고 기존 최종 사용자 개발자 에코시스템과 함께 작업한 경험이 없었습니다. 우리는 네이티브 개발자와 관리 개발자 모두가 작업하는 것을 좋아하지 않는 '최소 공통 분모' API를 갖게 되었습니다. 이것은 근본적으로 Windows Phone이 죽은 주요 원인 중 하나입니다. 개발자는 앱을 쉽게 개발/포팅할 수 없었습니다. 앱이 없으면 고객도 없습니다. Microsoft는 이 교훈을 배웠습니다.

따라서 우리는 수년 동안 익숙해져 온 관리 코드의 몇 가지 특전을 잃어버렸습니다. 확실히 여전히 WPF에서 한 걸음 뒤로 물러난 것처럼 보입니다. 저는 항상 버그와 불완전한 기능을 찾습니다. #1830은 WPF 시대에는 절대 일어나지 않을 것이라고 생각합니다. 우리는 여전히 어떻게든 앞으로 나아가야 합니다.

WinUI 3.0은 적어도 프론트엔드에서 이 문제를 해결하기 위한 올바른 방향으로 나아가는 단계입니다. 하지만 저는 Microsoft가 새로운 컨트롤을 출시하기 전에 더 강력한 개발 프로세스와 더 많은 테스트를 구현하는 것을 선호합니다... 개발이 이제 푸시 변경 사항이라는 것을 알고 나중에 수정합니다. 앱에서는 작동할 수 있지만 일단 설정되면 나중에 변경하기가 매우 어려운 플랫폼에는 좋은 패턴이 아닙니다. (TreeView, NumberBox 등은 15년 전의 계획 단계는 고사하고 첫 번째 릴리스에 너무 많은 문제가 있습니다.)

한때 가장 강력한 UI 플랫폼이었던 WPF가 이것으로 진화하는 것을 보니 안타깝습니다. 그러나 Microsoft는 이제 느리지만 확실하게 피드백을 듣고 문제를 해결하고 있습니다. 해야 할 일이 더 많다는 것을 이해합니다.

사용자가 위와 같이 만족할 것이라고 생각하십니까? 아니요. 실제로는 79.8%가 하지 않습니다(내 AppCenter 데이터가 이를 뒷받침함). 사용자가 내 앱을 사용하지 않거나 내 앱이 다른 기본 앱에 비해 하위 수준으로 보이도록 둡니다.

아마도 당신은 사용자가 실제로 멈춰서 "잠깐만, 이 앱에 내 전체 드라이브에 대한 액세스 권한을 부여하고 싶습니까?"라고 생각하고 있다는 사실을 고려하고 있지 않을 것입니다. 앱/개발자/회사에 익숙하지 않은 사람들을 위한 빨간불 경고입니다.

낮은 유지율을 위해 사용자가 전체 드라이브에 대한 액세스 권한을 앱에 부여하기 위해 거쳐야 하는 프로세스를 탓하고 있습니다. 아마도 처음부터 broadFileSystemAccess에 대한 "필요성"을 재고해야 하며, 오히려 사용자가 수동으로 액세스 권한을 부여하는 폴더를 편안하게 선택하도록 해야 합니다.

참고로, 앱을 사용해 보고 설치 후 "어이, 어디서나 모든 것에 액세스할 수 있는 권한을 주세요"와 같았으면 나도 실행했습니다.

broadSystemAccess를 요청하면 기본적으로 애플리케이션에는 해당 액세스 권한이 없습니다.

분명히... 당신은 단지 요청을 했을 뿐입니다. 당신의 사용자는 실제로 그렇게 하는 것이 편안하다고 느끼면 당신에게 접근 권한을 부여해야 합니다.

또한 Microsoft Open Source Code of Conduct 를 위반하는 무례한 제목과 WinUI에 대한 내용이 아니라는 점을 근거로 이 문제는 종료되어야 합니다. @jevansaks @jesbis

마지막으로 추가할 사항. Rich Lander가 1월 15일 .NET 커뮤니티 스탠드업 (1:12:40에서 시작)에서 가장 잘 말한 것 같습니다.

@verelpode 당신은 위의 비디오에서 언급한 라인을 타고 있지만 대부분의 경우 건설적이고 주제에 집중하기 때문에 WinUI 리포지토리에 대한 당신의 기여를 소중하게 생각합니다. 코멘트).

broadSystemAccess를 요청하면 기본적으로 애플리케이션에는 해당 액세스 권한이 없습니다.

분명히... 당신은 단지 요청을 했을 뿐입니다. 당신의 사용자는 실제로 그렇게 하는 것이 편안하다고 느끼면 당신에게 접근 권한을 부여해야 합니다.

그것은 문제가 아닙니다. 적어도 Android/iOS에서는 앱이 HDD에 액세스하려고 시도하는 동안 해당 항목을 묻는 메시지가 표시되고 우리의 경우와 같이 닫히지 않습니다 .

사용자가 앱에 액세스 권한을 부여할 항목을 선택할 수 있는 파일 선택기를 표시한 경우 앱이 닫히지 않습니다.

대신 당신은 모든 것을 원하고 사용자가 취해야 하는 사소한 일회성 추가 단계에 대해 불평하고 이 단계에서 유지율을 비난하고 있습니다.

또한 Microsoft Open Source Code of Conduct 를 위반하는 무례한 제목과 WinUI에 대한 내용이 아니라는 점을 근거로 이 문제는 종료되어야 합니다. @jevansaks @jesbis

내가 거의 정신을 잃을 때 존경하는 것은 정말 어렵습니다. 말할 것도 없이 - 전에도 말 했지만 WinRT에 대해 쓸 곳이 없습니다. 내가 실제로 글을 쓸 수 있고 누군가가 들어준다면 기꺼이 다른 어조를 사용하고 싶습니다. 위의 모든 외침은 단순히 존재하지 않아야 합니다. WinRT는 충분히 성숙해야 합니다 . 그래도... 아니...

커뮤니티가 실제로 WinRT 팀과 대화할 수 있는 곳은 어디입니까? 듣고 있는 사람이 있습니까?

사용자가 앱에 액세스 권한을 부여할 항목을 선택할 수 있는 파일 선택기를 표시한 경우 앱이 닫히지 않습니다.

대신 당신은 모든 것을 원하고 사용자가 취해야 하는 사소한 일회성 추가 단계에 대해 불평하고 이 단계에서 유지율을 비난하고 있습니다.

내 앱을 사용하면 사용자가 사진과 비디오를 편집할 수 있으며 사용자가 이전 스타일의 파일 선택기를 사용하지 않고 원하는 대로 쉽게 미리 볼 수 있기를 바랍니다. 네, 모든 HDD에 액세스하는 것이 정말 중요합니다. 그리고 아니요. "사진" 및 "동영상" 가상 폴더는 Microsoft가 사용자가 사진과 동영상을 보관한다고 생각하는 폴더입니다. 그건 현실이 아닙니다.

전에도 말했지만 WinRT에 대해 쓸 곳이 없습니다.

귀하의 링크에서 알 수 있듯이 귀하는 이미 UWP Q&A 포럼에서 WinRT에 대해 호언장담했습니다.

따라서 여기에 게시하면 실제로 무엇이든 달성하기보다는 더 많은 청중을 원하는 것처럼 보입니다(WinUI 팀은 WinRT에서 작동하지 않기 때문에).

귀하의 링크에서 알 수 있듯이 귀하는 이미 UWP Q&A 포럼에서 WinRT에 대해 호언장담했습니다.

그러나 내 문제에 대한 해결책은 없습니다. Q&A에서는 질문하고 답변을 받습니다. 그러나 (불행히도) 변경할 것을 제안할 수는 없습니다.

내 앱을 사용하면 사용자가 사진과 비디오를 편집할 수 있으며 사용자가 이전 스타일의 파일 선택기를 사용하지 않고 원하는 대로 쉽게 미리 볼 수 있기를 바랍니다. 네, 모든 HDD에 액세스하는 것이 정말 중요합니다.

아니요. 사용자는 드라이브 전체에 사진과 비디오를 가지고 있지 않으며 특수 폴더가 아닌 특정 위치에 있습니다.

사용자가 해당 폴더를 한 번 선택하게 하면 FutureAccessList 를 통해 항상 액세스할 수 있습니다. 그들이 당신에게 그들의 모든 파일에 접근할 수 있도록 하지 마십시오. 그러면 그들은 도망가지 않을 것입니다.

@kmgallahan 물론, 톤을 약간 되돌릴 수는 있지만 우리 모두는 전에 좌절했습니다. 명백한 문제가 해결되지 않고 있다고 생각하면 더욱 실망스럽습니다. 사람들이 이를 검증하고 잠재적인 솔루션을 제공할 수 있는 포럼에서 이러한 좌절감을 표출하는 것이 때때로 건설적이라고 생각합니다. 그의 기술 요점은 유효하며 WinRT 및 약간의 UWP에만 해당되며 둘 다 이 리포지토리가 나타내는 WinUI XAML 컨트롤이 아닙니다. 그런 이유로 이것은 주제를 벗어난 것으로 닫아야 합니다.

저는 이러한 유형의 토론이 좌절과 개발 생태계의 성공에 대한 많은 기득권에서 비롯된 것임을 알고 전문적으로 유지할 수 있다고 생각합니다.

물론, 톤을 약간 되돌릴 수는 있지만 우리 모두는 이전에 좌절한 적이 있습니다. 명백한 문제가 해결되지 않고 있다고 생각하면 더욱 실망스럽습니다.

감사 해요 :)

아니요. 사용자는 드라이브 전체에 사진과 비디오를 가지고 있지 않으며 특수 폴더가 아닌 특정 위치에 있습니다.

사용자가 해당 폴더를 한 번 선택하게 하면 FutureAccessList 를 통해 항상 액세스할 수 있습니다. 그들이 당신에게 그들의 모든 파일에 접근할 수 있도록 하지 마십시오. 그러면 그들은 도망가지 않을 것입니다.

분명히, 그들은 그 특정 위치에 있지 않습니다....

물론, 나는 그 FutureAccessList를 사용할 수 있고 사용자들이 사진/비디오를 보관하는 위치를 기억하게 할 수 있습니다.

(내 앱이하는 일) 폴더를 멋지게 미리보고 사진 / 비디오가있는 폴더를 표시하는 대신.

몇 가지 참고 사항:

시간을 내어 경험과 피드백을 작성하고 Q&A 페이지 에 시간을 내주신 @jtorjo 께 감사드립니다.

@robloo 와 @kmgallahan이 언급했듯이 이 대부분은 WinUI와 직접적인 관련이 없으며 행동 강령을 약간 밀고 있을 수 있습니다 🙂

그러나 Windows 개발자 플랫폼의 다른 영역과 관련하여 Q&A 사이트 및 Feedback Hub에 대한 참여가 더 나을 수 있음도 알고 있습니다. 우리는 실제로 이를 개선하기 위해 적극적으로 노력하고 있지만 피드백을 제공하고 문제가 발생하는지 확인할 수 있는 좋은 장소를 찾는 것이 답답하다는 것을 알게 되었습니다.

예를 들어 Feedback Hub를 통해 들어오는 모든 것을 실제로 보고 있지만 토론에 응답하거나 계속할 수 있는 좋은 방법이 없습니다. 따라서 건설적인 상태를 유지하고 Windows 앱 UX/개발과 관련이 있는 한 주제가 현재 다른 곳에서 잘 맞지 않는 경우 여기에서 몇 가지 일반적인 플랫폼 피드백을 논의하는 것이 좋습니다.

그만한 가치가 있기 때문에 이러한 주제는 내부적으로도 심각한 관심을 받습니다. 오늘 일부 WinRT 전문가 에게 연락하여 전체 플랫폼 및 도구의 주요 문제 중 일부를 깔끔하게 요약하여

데스크톱 앱 개발의 경우: WinUI 3은 Windows 개발자 플랫폼을 분리하여 이러한 상호 운용성 장벽을 제거하고 WinUI 및 UWP를 더 쉽게 점진적으로 채택할 수 있도록 하려는 우리 노력의 큰 부분입니다. 우리는 현재의 모든 제한 사항을 요구하지 않고 최신 UX로 데스크톱 앱을 더 잘 활성화해야 한다는 것을 알고 있습니다. WPF의 주요 제작자 중 일부를 포함하여 많은 전문가가 작업하고 있습니다.

특히, 우리는 Xaml 섬과 데스크톱 앱용 WinUI에 많은 시간을 할애하고 있으며 올해 후반에 사람들이 시도할 수 있도록 미리 보기를 릴리스할 다음 단계를 기대하고 있습니다. 우리는 피드백 중심의 투명도를 높이려고 노력하고 있으며 전체 Xaml 플랫폼(예: WinUI 3)을 오픈 소스로 옮기면 더 쉬워질 것입니다.

사람들이 데스크톱 계획의 현재 상태에 관심이 있는 경우 월간 커뮤니티 호출 중 하나에서 좀 더 자세히 설명할 수도 있습니다. 여기에서 주제를 자유롭게 제안하세요.

WinUI 커뮤니티 콜(2020년 1월 22일) #1857

안녕하세요 @jesbis 님

내 문제를 봐 주셔서 감사합니다!

@robloo 와 @kmgallahan이 언급했듯이 이 대부분은 WinUI와 직접적인 관련이 없으며 행동 강령을 약간 밀고 있을 수 있습니다 🙂

네, 정말 죄송합니다. 제 정신이 나간 것 같았습니다. 여기에서 언급한 사항은 매우 중요합니다. 위의 모든 경우에 직면했기 때문에 저는 이에 대해 정말 열정적입니다. 그들 모두는 엄청난 대가를 치르고, 많은 사람들은 시도조차 하지 않고 단순히 포기합니다.

그러나 Windows 개발자 플랫폼의 다른 영역과 관련하여 Q&A 사이트 및 Feedback Hub에 대한 참여가 더 나을 수 있음도 알고 있습니다. 우리는 실제로 이를 개선하기 위해 적극적으로 노력하고 있지만 피드백을 제공하고 문제가 발생하는지 확인할 수 있는 좋은 장소를 찾는 것이 답답하다는 것을 알게 되었습니다.

전적으로 동의 한. 참고로 저는 실제로 Feedback Hub에서 broadSystemAccess를 보고하려고 시도했으며 모든 세부 정보를 제공하고 약 15분을 보낸 후 "뒤로"에 해당하는 단축키를 어떻게든 눌렀을 것입니다. 모든 작업을 잃어버렸습니다(실행 취소 없음, 클립보드에 복사되는 텍스트 없음, 아무것도 없음). 분명히, 나는 미친 듯이 좌절하고 그냥 포기했습니다.

그만한 가치가 있기 때문에 이러한 주제는 내부적으로도 심각한 관심을 받습니다. 오늘 일부 WinRT 전문가 에게 연락하여 전체 플랫폼 및 도구의 주요 문제 중 일부를 깔끔하게 요약하여

멋있는!

데스크톱 앱 개발의 경우: WinUI 3은 Windows 개발자 플랫폼을 분리하여 이러한 상호 운용성 장벽을 제거하고 WinUI 및 UWP를 더 쉽게 점진적으로 채택할 수 있도록 하려는 우리 노력의 큰 부분입니다. 우리는 현재의 모든 제한 사항을 요구하지 않고 최신 UX로 데스크톱 앱을 더 잘 활성화해야 한다는 것을 알고 있습니다. WPF의 주요 제작자 중 일부를 포함하여 많은 전문가가 작업하고 있습니다.

굉장해! 확실히 더 기대됩니다. 이 작업이 완료되면 앱을 업데이트할 가능성이 매우 높지만 그때까지는 많은 문제에 봉착했습니다.

사람들이 데스크톱 계획의 현재 상태에 관심이 있는 경우 월간 커뮤니티 호출 중 하나에서 좀 더 자세히 설명할 수도 있습니다. 여기에서 주제를 자유롭게 제안하세요.

WinUI 커뮤니티 콜(2020년 1월 22일) #1857

여기서 언급한 WinRT 주제를 제안할 수 있습니까?

다시 한번 감사합니다!

예를 들어 Feedback Hub를 통해 들어오는 모든 것을 실제로 보고 있지만 토론에 응답하거나 계속할 수 있는 좋은 방법이 없습니다. 따라서 건설적인 상태를 유지하고 앱 개발과 관련이 있는 한 주제가 현재 다른 곳에서 잘 맞지 않는 경우 일반적인 플랫폼 피드백을 여기에서 받아도 괜찮습니다.

@jesbis
이것은 좋은 소식입니다! 이러한 유연성을 보여주고 (인식된) WinRT 피드백 시스템 문제를 완화하려고 노력할 필요가 없음에도 불구하고 WinUI 팀에게 많은 감사를 드립니다!

@kmgallahan

Rich Lander가 1월 15일 .NET 커뮤니티 스탠드업(1:12:40에서 시작)에서 가장 잘 말한 것 같습니다.

그래서 Rich Lander는 약간의 공격성이 있지만 동시에 좋은 사람들을 선호한다고 말합니다. 사회의 가장 큰 문제 중 하나는 많은 사람들이 너무 '예의바르게' 행동하여 극단주의가 되어 무례함과 무례함으로 바뀌면서 표면적으로는 '예의바른' 것처럼 보인다는 것입니다. 매우 "예의바른" 사람들은 간접적이고 모호하게 말하며, 이는 의사소통을 이해하기 어렵게 만들고 잘못 해석하기 쉽습니다. 매우 "정중한" 사람들은 다음과 같은 말을 하기 때문에 무례하고 무례합니다.

"직접적인 진실을 감당할 수 없다고 믿으니까 두툼한 솜털장갑을 끼고 뽁뽁이에 싸서 아주 정중하게, 간접적으로, 막연하게 말하겠다. 성숙한 어른이고 내 솔직한 의견을 내세우면 펄쩍 뛰고 터지고 미쳐버릴거야 너는 아주 연약하고 연약한 사람이고 철도 없고 그래서 내가 너에게 극도로 공손하고 간접적으로 말해야 하니까. 직접적인 진실을 다루지 마라."

그런 식으로, 소위 "공손함"이 극단적으로 취해지면(많은 사람들이 그러하듯이), 여전히 "공손함"인 것처럼 보이지만 무례하고 무례하게 됩니다. 즉, 예의와 존중에 대한 오해는 사회의 가장 큰 문제 중 하나입니다. 많은 사람들은 과도한 예의가 무례하고 프로젝트가 실패하는 등의 원인이 된다는 사실을 깨닫지 못합니다. 이 거짓 예의 문제는 세계 어딘가에서 매일 매초 또 다른 통신 장애를 유발합니다. 그로 인해 크게 고통받습니다.

@jtorjo
문제의 원인은 다음과 같습니다.

노키아의 치명적인 실수 반복

WinRT/UWP는 실수로 노키아, 블랙베리, 애플과 같은 실수를 한 지점에서 반복했다. Nokia 이야기: Nokia는 매우 성공적인 거물이었지만 나중에 Nokia는 스마트폰 기술에서 뒤쳐져 있다는 것을 깨달았습니다. 이 문제를 해결하기 위해 그들은 기존 시스템의 일련의 개선된 버전을 구현하는 것을 최우선 과제로 삼아야 했습니다. 그렇게 하는 대신, 그들은 새로운 시스템으로 전환하려고 했고, 그것은 그들을 죽였습니다. 말 그대로 그들을 죽였다. 노키아 모바일은 마이크로소프트의 인수를 받아들일 수밖에 없었다.

그렇다면 마이크로소프트가 노키아의 실수로부터 교훈을 얻고 같은 문제를 반복하지 않을 것이라고 예상할 것이다. 불행하게도 마이크로소프트는 노키아와 같은 실수를 반복했다. Microsoft는 WPF 및 .NET Framework의 새 버전을 생성하는 대신 WinRT/UWP에 착수했습니다. 무슨 일이 있었는지 맞춰보세요? 노키아와 똑같은 재앙이 그들을 죽였습니다. Windows Mobile은 죽었고 Microsoft 경영진에 의해 취소되었습니다. 따라서 불행하게도 마이크로소프트는 노키아의 치명적인 실수로부터 교훈을 얻지 못했다. 이제 모든 스마트폰은 WinRT/UWP 대신 Android 또는 Apple을 실행하므로 WinRT/UWP는 Microsoft가 수십억 달러 규모의 스마트폰 산업에서 완전히 자리를 잃게 만든 치명적인 실패였습니다. WinRT/UWP는 Microsoft에 수십억 달러의 손실을 초래했습니다.

블랙베리는 노키아와 마이크로소프트와 같은 실수를 저질렀다. 블랙베리는 매우 성공적이었지만 나중에 블랙베리는 스마트폰 기술에서 뒤쳐져 있다는 것을 깨달았습니다. 이 문제를 해결하기 위해 그들은 기존 시스템의 일련의 개선된 버전을 구현하는 것을 최우선 과제로 삼아야 했습니다. 그렇게 하는 대신 새로운 시스템으로 전환하려고 했습니다. 블랙베리는 원래 블랙베리 OS를 사용하다가 2013년경에 QNX 시스템으로 전환했습니다. 무슨 일이에요? WinRT 및 Nokia와 동일합니다. 그것은 그들을 죽였다. 2016년 블랙베리는 자체 휴대폰 설계를 중단하겠다고 발표했습니다.

과거 어느 시점에서 Apple에서도 발생했습니다. 애플은 거의 무너질 뻔했고 살아남은 것은 운이 좋았다. 몇 년 후, 애플은 결국 스마트폰을 통해 강력한 회복세를 보였습니다. 치명적인 실수 이후에 살아서 운이 좋습니다.

주요 변경 사항

Microsoft는 WPF 개발을 계속할 수 없다고 주장합니다. 브레이킹 체인지 때문에 스마트폰/태블릿용 WPF를 사용할 수 없었지만 브레이킹 체인지에 대한 극도의 두려움이 있는 경우입니다. 예, 변경 사항을 깨는 것과 관련하여 매우 조심하는 것이 현명하지만 극단적으로 취하면 프로젝트와 회사가 죽습니다. 현실은 깨는 변화가 실제로 도입 될 수 있다는 것입니다. Microsoft는 스마트폰/태블릿/터치스크린을 지원하는 "WPF 5"를 출시할 수 있었고 여기에는 주요 변경 사항이 포함되어 있다고 발표했지만 개발자가 즉시 업그레이드해야 하는 것은 아닙니다. 기존 앱은 앱 개발자가 편안하고 WPF 5로 전환할 준비가 될 때까지 WPF 4로 계속 실행되기 때문에 중단되지 않습니다. 따라서 주요 변경 사항으로 인해 혼란이나 실패가 발생하지 않습니다.

주요 변경 내용이 포함된 NuGet 패키지의 새 버전과 동일한 원칙입니다. 패키지의 새 버전이 출시될 때 앱이 갑자기 중단되지 않습니다. 사용자는 계속해서 앱을 사용하고 문제가 발생하지 않습니다. 사용자가 편안하고 최신 버전의 NuGet 패키지를 사용하도록 앱을 업그레이드할 준비가 될 때까지 앱에서 이전 버전의 패키지를 계속 사용하기 때문입니다. 따라서 주요 변경 사항을 도입할 수 있습니다.

관리 코드에 대한 관점의 반전

Microsoft는 관리 코드가 뛰어난 이점을 제공한다고 말했으며 관리 코드와 비관리 코드를 모두 사용한 경험에 따르면 이는 절대적으로 사실입니다. 비관리 코드 작성 경력을 시작했습니다. 나중에 Microsoft의 주장을 테스트하고 관리 코드로 전환했으며 생산성과 안정성이 크게 향상되었습니다. 나중에 마이크로소프트는 기이하게도 그들의 입장을 바꾸어 1993년부터 비관리 코드와 고대 COM(구성 요소 개체 모델), 그리고 Win16(Win32라고도 함)의 과도한 사용을 기반으로 WinRT를 생성했습니다. WinRT의 기반은 수십 년이 지난 기술입니다. 네이티브 코드, COM 및 Win16(일명 Win32)입니다. 대부분의 앱 개발자가 WinRT/UWP로 전환하는 것을 꺼리는 것은 놀라운 일이 아닙니다.

Android는 이제 시장의 리더입니다. 마이크로소프트는 안드로이드에서 배울 수 있습니다. Android 앱은 일반적으로 관리 코드를 사용하여 작성됩니다. Java를 싫어하고 C#을 사용하는 것을 선호하지만 Java가 기본 Win16 및 COM보다 훨씬 낫다고 말해야 합니다.

여러 Microsoft 직원은 여전히 ​​좋은 일인 것처럼 "네이티브"라고 계속 말합니다. 저는 "네이티브"로 경력을 시작했으며 수년간의 경험을 통해 "네이티브"가 나쁜 것임을 알고 있습니다. 수많은 Android 개발자들도 네이티브가 나쁘다는 것을 알고 있지만 너무 많은 UWP 직원이 좋은 것처럼 말합니다. @jtorjo 의 말을 사용하면 WinRT 팀은 "현실과

이 말을 계속해서 반복해야 합니다. WinRT/UWP는 치명적인 실패였습니다. WinRT 팀이 WinRT/UWP가 치명적인 실패였으며 Microsoft가 동일한 실수를 계속 반복해서는 안 된다는 점을 인정하지 않는다는 의미에서 WinRT 팀이 "현실과 동떨어진" 상태이기 때문에 이 말을 계속 반복해야 했습니다. 아무 일도 없었던 것처럼 WinRT.

예를 들어, 현재 DataGrid 는 최신 관리 코드로 작성되어 있지만 WinUI 팀은 "네이티브" 코드를 사용하도록 DataGrid를 다시 작성하려고 하며 실제로는 다운그레이드 및 관행으로 회귀할 때 이것이 "업그레이드"라고 생각합니다. 수십 년이 지난 것입니다. 일반적으로 WinRT/UWP는 최신 소프트웨어 엔지니어링 방식과 구식 소프트웨어 엔지니어링 방식이 혼재되어 있습니다. 따라서 @jtorjo가 _"현실과

_"현실과 동떨어진"_의 또 다른 예는 WebView2 의 디자인을 보세요. 마치 수십 년 전 쓸모없는 개념을 사용했던 제 커리어의 시작으로 시간 여행을 하는 것과 같습니다. 예를 들어 현대적인 예외 처리 대신 HRESULT 입니다. WebView2가 2020년에 새로운 프로젝트로 출시되었지만 HRESULT 및 LPCWSTR 와 같은 고대 기술을 여전히 사용하는 것을 보는 것은 놀라운 일입니다. WebView2의 디자인은 현대적인 소프트웨어 엔지니어링 방식과 동떨어져 있습니다.

따라서 Rich Lander가 말한 대로, 이전 메시지는 WinUI 팀 에 대한 나의 정중 하게 대하거나 아무 말도 하지 않을 것이기 때문입니다. 내가 팀을 존중하지 않는다면 WinUI를 무시하고 무시할 것입니다. 나는 어떤 메시지도 작성하지 않을 것입니다. 나는 WinUI를 "희망이 없는" 그리고 "잃어버린 원인"으로 볼 것이고 피드백을 제공하지 않을 것입니다. 모두. 제가 자세한 피드백을 해준다는 것은 제가 팀을 존중한다는 것을 보여줍니다. 많은 사람들이 피드백을 제공하지 않습니다. 이는 팀에 대한 무례한 행동입니다. 팀이 너무 절망적이어서 피드백을 쓸 가치가 없다고 보는 것은 무례한 일입니다.

법정에 섰다면 판사의 배짱이 싫더라도 아주 정중하게 판사에게 "판사님"이라고 말했을 것입니다. 극도의 공손함은 무례함입니다. 판사들은 "Your Honor"를 존경으로 해석하지만 실제로는 무례합니다.

Microsoft는 WPF 및 .NET Framework의 새 버전을 생성하는 대신 WinRT/UWP에 착수했습니다. ...

동의. 나는 지금 꽤 몇 달 동안 UWP를 개발해 왔습니다... 꽤 많은 제한 사항이 있지만 그것에 대해 "선"하기 위해 최선을 다했고 어느 정도 진행했습니다. 하지만 일을 하면 할수록 한계가 사실은 UWP가 아니라 WinRT라는 것을 깨달았습니다.

문제는 이것이 우리가 갖고 있는 것이며 분명히 앞으로 나아가야 한다는 것입니다. 내 생각에는 다음과 같아야 합니다.

1. UWP는 WinRT를 사용하고 있다는 사실을 최대한 숨겨야 합니다.
2. WinRT는 가능한 한 많은 (불필요한) 제한을 제거하기 위해 노력해야 합니다.
3. 주요 초점은 데스크탑이어야 하고 그 다음 다른 플랫폼(Hololens, xbox 등)이어야 합니다.

(ps 파일의 속성을 얻으려면 비동기 함수를 호출해야 한다는 사실이 여전히 저를 움찔하게 만듭니다)

관리 코드에 대한 관점의 반전

WinRT에서 COM을 다루어야 하는 이유는 정말 이해가 되지 않습니다. 오래된 DCOM 코드나 다른 것을 포장한 것 같지만 WinRT 사용자에게는 100% 숨겨져 있어야 합니다.
COM을 알아야 한다는 사실은 정말 나쁜 것입니다. 다시 한 번, 가능한 한 많이 숨겨야 하며, 라이브러리 사용자인 나에게 숨겨져 있어야 합니다.

[나중에 편집] 이제 생각해 보니 DirectX를 처리하려면 최소한 COM이 필요합니다. 그래도 라이브러리 사용자에게는 가능한 한 숨겨져 있어야 합니다.

여러 Microsoft 직원은 여전히 ​​좋은 일인 것처럼 "네이티브"라고 계속 말합니다.

네이티브는 ".net 네이티브로 컴파일"이라는 맥락에서 좋은 일이라고 생각하지만 제한 사항이 마음에 들지 않습니다. 내 프로젝트는 UWP로 포팅한 다른 라이브러리를 사용하고 강력한 Store 직원이 "허용할 수 없다"고 생각하는 일부 API를 사용하기 때문에 .net 네이티브로 컴파일하지 못합니다. 문제의 라이브러리는 https://github.com/naudio/NAudio - 엄청나게 강력한 라이브러리입니다. 이러한 이유로 나는 단순히 내 앱을 MS 스토어에 게시하지 않을 것이라고 말했습니다.

_"현실과 동떨어진"_의 또 다른 예는 WebView2 의 디자인을 보세요. 마치 내 경력의 시작점으로 시간 여행을 하는 것과 같습니다.

100% 확신할 수는 없지만 아마도 당신이 맞을 것입니다. WebView가 Win32 컨트롤에 대한 래퍼라는 것을 알고 있으며 WebView가 다른 컨트롤 위에 있을 때 WebView 링크가 작동하지 않는다는 이상한 버그를 알고 있습니다.

안녕하세요 @roblo 님

늦은 답변 죄송합니다

몇 년 전 처음 WPF 앱을 포팅하기 시작했을 때 나는 당신의 좌절 수준이었습니다. 그래서 나는 확실히 당신의 마음을 이해합니다. 그 이후로 약간의 진전이 있었고 당신이 말했듯이 WinUI 팀은 정말로 노력하고 있습니다.

예, 전적으로 동의합니다. 2016-2017년에는 UWP를 건드리지도 않았습니다.

내 관점에서 볼 때 우리가 해결할 수 없는 근본적인 디자인 문제가 있습니다. WinRT는 C++ 및 JavaScript와 직접 상호 운용해야 하기 때문에 기술적으로 장애가 있습니다.

그것은 슬픈 일이 아닙니다... JS 상호 운용성을 원하는 이유는 무엇입니까?

...는 예이고 다른 하나는 )입니다. 제네릭과 같은 많은 고급 개념과 실제로 잘 작동하지 않습니다. 물론 이 아키텍처에는 한 가지 큰 이점이 있습니다. 이제 모든 Windows에서 동일한 WinRT API를 공유할 수 있습니다.

내가 WinRT에 대해 싫어하는 것이 많이 있습니다. 목록에 하나가 더 있습니까?

내가 이것에 대해 알아야 한다는 사실조차 나쁘다. 사실, 나는 2개의 작은 프로젝트를 만들어야 했고, 실제로 내가 무엇을 사용할 수 있는지 이해하기 위해 시행착오를 겪었습니다.

따라서 우리는 수년 동안 익숙해져 온 관리 코드의 몇 가지 특전을 잃어버렸습니다. 확실히 여전히 WPF에서 한 걸음 뒤로 물러난 것처럼 보입니다. 저는 항상 버그와 불완전한 기능을 찾습니다. #1830은 WPF 시대에는 절대 일어나지 않을 것이라고 생각합니다. 우리는 여전히 어떻게든 앞으로 나아가야 합니다.

그래, 우리는...

WinUI 3.0은 적어도 프론트엔드에서 이 문제를 해결하기 위한 올바른 방향으로 나아가는 단계입니다. 하지만 Microsoft는 새로운 컨트롤을 출시하기 전에 더 강력한 개발 프로세스와 더 많은 테스트를 구현하는 것을 선호합니다... [...]

100% 동의합니다.

한때 가장 강력한 UI 플랫폼이었던 WPF가 이것으로 진화하는 것을 보니 안타깝습니다. 그러나 Microsoft는 이제 느리지만 확실하게 피드백을 듣고 문제를 해결하고 있습니다. 해야 할 일이 더 많다는 것을 이해합니다.

예, MS에는 분명히 듣고 있는 멋진 사람들이 있습니다 . 우리가 이것을 뒤집을 수 있기를 바랍니다...

파일 쿼리 API는 느림을 넘어

분명히 누군가가 이에 대한 해결 방법을 찾았습니다. 분명히, 이 작업이 너무 오래 걸린다는 것은 정말 슬픈 일입니다. 그리고 이것은 제가 파일 검색을 처리할 때 선호하는 방식은 아니지만 적어도 실제로는 작동합니다.
https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

@duke7553 에게 감사드립니다!

@jtorjo 기꺼이 도와주세요!

저는 이 토론이 매우 흥미롭고 실제로 Windows UI의 미래와 매우 관련이 있다는 것을 알았습니다. WinUI가 진공 상태에 있지 않기 때문입니다. 이 전체 리포지토리는 WinRT/UWP 이외의 다른 항목에서 실행되는 앱을 만드는 데 유용하지 않는 한 거의 가치가 없습니다. WinUI 3.0은 곧 나올 수 없습니다.

Windows의 UI에 대한 비전과 로드맵이 있지만 스택의 맨 위에 있고 해당 표면 레이어 아래에 있는 내용에 대한 비전이 없습니다.
WinUI가 좋아 보이나요? 예
지금(2020년 1월) Windows에서 현대적이고 멋진 앱을 만들 수 있습니까? 아니요
UWP로 좋은 앱을 만들 수 있나요? 지옥 NO!

우리는 방의 코끼리를 다루지 않고는 앞으로 나아갈 수 없습니다. 앞에서 WinRT와 UWP가 비즈니스 면에서뿐만 아니라 기술적으로도 완전히 실패했다는 사실을 언급했습니다. 나는 개인적으로 신체 수에 속합니다. 내 앱이 초점을 잃었을 때 소리를 재생하는 방법을 알아낼 수 없을 때 취미 프로젝트 개발을 중단했습니다. 하찮은. 사소한 일도 UWP만큼 어려워야 합니까? 사소한 일이 불가능할 정도로 어려울 때 플랫폼을 훌륭하다고 할 수 있습니까? WinUI는 플랫폼의 일부일 뿐입니다.

방에 있는 또 다른 코끼리. 누군가가 새 Windows 프로그램을 만들고 싶다고 묻는다면 가장 좋은 방법은 무엇입니까? 2020년 1월 정답은 없다! 답변에 UWP를 넣으려고 하면 시간이 많이 걸릴 것입니다. (누군가가 다음과 같이 말한 댓글, 블로그 게시물, YouTube 동영상이 있습니까? UWP로 훌륭한 앱을 만들었고 그 과정이 마음에 들었습니까? 우리 모두는 그렇지 않다는 것을 압니다. 아무도 UWP로 앱을 만드는 것에 대해 글을 쓰지 않고 말 그대로 그렇습니다. 인터넷에 존재하지 않음). WPF? 현대적인 컨트롤이 없음 - 죽은 기술, 좋은 생각은 아닙니다(그래도 UWP보다 낫습니다). 정직한 대답은 다음과 같습니다. 전자를 사용해보십시오. 아마도? VSCode는 그것으로 만들어졌기 때문에 좋은 앱을 만들 수 있다는 것을 압니다.

그리고 당신이 원하는 어떤 언어로든 윈도우용 앱을 만들 수 있다는 이 아이디어는 그저 막연한 생각일 뿐입니다. 우리는 당신이 원하는 어떤 언어로도 아주 나쁜 UWP 앱을 만들 수 있는 상황에 있습니다. 봇은 적어도 하나의 훌륭한 방법이 아닙니다.

전에 쓰레드에서 언급한 네이비? 완전히 동의합니다. Visual Studio - Juggernaut 자체(UI)는 관리 코드인 WPF로 만들어집니다. 훌륭합니다. 심지어 환상적입니다. 마이크로소프트도 이 슈퍼리온 네이티브 코드로 OK 앱을 만들 수는 없지만. 나는 OneNote, 날씨, 심지어 시작/검색/작업 표시줄에서 매일 예기치 않은 동작을 봅니다. 불안정한 느낌이 들고 때때로 초점이 제대로 작동하지 않습니다.

이것은 풍부하고 중요한 주제입니다. WinUI와 매우 관련이 있으며 슬프게도 그것에 대해 이야기하기에 더 좋은 곳이 없습니다. 이러한 항목은 Microsoft에서 공개적으로 처리해야 합니다.

Windows의 UI에 대한 비전과 로드맵이 있지만 스택의 맨 위에 있고 해당 표면 레이어 아래에 있는 내용에 대한 비전이 없습니다.
WinUI가 좋아 보이나요? 예

그렇습니다!

지금(2020년 1월) Windows에서 현대적이고 멋진 앱을 만들 수 있습니까? 아니요

나는 당신이 할 수 있다고 믿습니다 - 하지만 그것은 정말 정말 어렵습니다. 사소한 일은 하기가 엄청나게 어렵습니다(나는 그것이 가능하다는 살아있는 증거이지만, 당신은 확실히 강철의 신경이 필요합니다):

• UI 전면에는 문제가 있지만 일반적으로 문제가 해결됩니다.
• "다른 모든 것" 전면에서는 상황이 매우 어둡습니다.
• UWP에서 파일을 처리하는 것은 StorageFile/Folder API로 인해 완전히 지옥입니다.

우리는 방의 코끼리를 다루지 않고는 앞으로 나아갈 수 없습니다. 앞에서 WinRT와 UWP가 비즈니스 면에서뿐만 아니라 기술적으로도 완전히 실패했다는 사실을 언급했습니다. 나는 개인적으로 신체 수에 속합니다. 내 앱이 초점을 잃었을 때 소리를 재생하는 방법을 알아낼 수 없을 때 취미 프로젝트 개발을 중단했습니다. 하찮은. 사소한 일도 있는 만큼 힘들어야 합니까?

동의. 실제로 WPF에서 SystemSounds.Beep.Play() 와 같은 시스템 사운드를 재생하는 것은 UWP에서 사용할 수 없습니다.

기본적으로 "훌륭한" WinRT 제한으로 인해 UWP에는 사운드 라이브러리가 없습니다. 이는 기본적으로 win32인 DLL에서 함수를 가져올 수 없음을 의미합니다. 거의 모든 적절한 라이브러리를 UWP로 이식할 수 없습니다. 라이브러리도 앱도 없습니다.

UWP의 "사운드 라이브러리"에서 naudio는 UWP에서 작동하기 위해 최선을 다했습니다. 분명히, 그것은 평평하게 떨어졌습니다. 포크를 수행하고 많은 #ifdef를 제거했으며 이제 필요에 맞게 작동합니다. 내 앱을 MS Store에 게시할 수 없으며, 그렇게 하고 싶지도 않습니다.

내 생각에 올바른 방향으로 가는 가장 좋은 단계는 MS가

1. 마지막으로 Windows Desktop FIRST에 중점을 둡니다 . Hololens, Xbox 등과 같은 수천 개의 플랫폼을 찾지 마세요. 물론 이러한 플랫폼을 위해 개발하려는 사람들이 있을 수 있지만 그 비율은 미미합니다.
2. 모든 제한 API를 현명하게 제거 하여 사람들이 실제로 라이브러리를 UWP로 컴파일할 수 있도록 합니다.
3. BroadSystemAccess를 요청하면 제공하고 너무 보호하지
4. broadSystemAccess를 요청하면 모든 HDD에 대해 System.IO를 허용합니다.
5. MS 스토어 외부에 쉽게 배포할 수 있도록 합니다 (+ "새 인증서" 문제 수정).

방에 있는 또 다른 코끼리. 누군가가 새 Windows 프로그램을 만들고 싶다고 묻는다면 가장 좋은 방법은 무엇입니까? 2020년 1월 정답은 없다! 답변에 UWP를 넣으려고 하면 시간이 많이 걸릴 것입니다. (누군가가 다음과 같이 말한 댓글, 블로그 게시물, YouTube 동영상이 있습니까? UWP로 훌륭한 앱을 만들었고 그 과정이 마음에 들었습니까? 우리 모두는 그렇지 않다는 것을 압니다. 아무도 UWP로 앱을 만드는 것에 대해 글을 쓰지 않고 말 그대로 그렇습니다. 인터넷에 존재하지 않음). WPF? 현대적인 컨트롤 없음 -

예, 동의합니다. UWP에서 좋은 리소스를 찾는 것은 거의 0에 가깝습니다. 많은 문제를 스스로 해결하고 해결해야 합니다.

죽은 기술, 좋은 생각은 아닙니다(그래도 UWP보다는 낫습니다). 정직한 대답은 다음과 같습니다. 전자를 사용해보십시오. 아마도? VSCode는 그것으로 만들어졌기 때문에 좋은 앱을 만들 수 있다는 것을 압니다.

WPF에 대해 칭찬의 말만 있습니다. 나는 꽤 몇 년 동안 개발했습니다. 학습 곡선이 상당히 가파르지만 일단 익숙해지면 놀랍습니다! 나는 결코 고쳐지지 않을 것이라는 것을 알고 있었던 몇 가지 하드코어 버그를 발견했지만, 그게 전부입니다.

내 앱을 충분히 빠르게 만들기 위해 win2d를 사용해야 했기 때문에 UWP로 이동해야 했습니다. UI와 관련하여 UWP에서 누락된 것이 있습니다(예: 포팅을 시작할 당시 컨트롤에 대해 Cursor 를 정의하는 기본 방법이 없음). 하지만 대체로 저는 항상 해결 방법을 찾았습니다. .

전에 쓰레드에서 언급한 네이비? 완전히 동의합니다. Visual Studio - Juggernaut 자체(UI)는 관리 코드인 WPF로 만들어집니다. 훌륭합니다. 심지어 환상적입니다. 마이크로소프트조차 할 수 없는 동안

분명히, 나는 평생 UWP에서 Visual Studio를 만들 수 없다고 확신합니다. UI에 대해 말하는 것이 아니라 Visual Studio의 UI와 일치하고 능가할 수 있지만 나머지는 마찬가지입니다. ...

이것은 풍부하고 중요한 주제입니다. WinUI와 매우 관련이 있으며 슬프게도 그것에 대해 이야기하기에 더 좋은 곳이 없습니다. 이러한 항목은 Microsoft에서 공개적으로 처리해야 합니다.

100% 동의합니다!

지금(2020년 1월) Windows에서 현대적이고 멋진 앱을 만들 수 있습니까? 아니요

나는 당신이 할 수 있다고 믿습니다 - 하지만 그것은 정말 정말 어렵습니다. 사소한 일은 하기가 엄청나게 어렵습니다(나는 그것이 가능하다는 살아있는 증거이지만, 당신은 확실히 강철의 신경이 필요합니다):

• UI 전면에는 문제가 있지만 일반적으로 문제가 해결됩니다.
• "다른 모든 것" 전면에서는 상황이 매우 어둡습니다.
• UWP에서 파일을 처리하는 것은 StorageFile/Folder API로 인해 완전히 지옥입니다.

우리는 여기에서 구타당한 개와 같습니다. Windows 데스크탑을 위한 새로운 최신 앱을 만드는 것은 실제로 너무 어렵습니다! 앱을 실행하는 훌륭한 방법이 적어도 하나는 있어야 하지 않습니까? Windows에서 Microsoft Store로 이동하여 앱 범주를 스크롤하려고 하면 UWP로 만든 괜찮은 앱을 찾을 수 없습니다. Btw 내가 직접 확인할 수는 없기 때문에 ...

네, "모던", "네이티브" 앱 신사 숙녀 여러분. Windows는 이제 거의 무료이기 때문에 수익 창출의 주요 소스는 시스템에서 가장 견고한 앱이 되어서는 안 됩니다. 실제로 어떤 기술로 앱을 만들었는지 알기 위해 앱을 조사할 필요는 없습니다. 한 번만 봐도 UWP로 빌드되었는지 알 수 있습니다. UWP로 구축된 심각한 상용 프로젝트는 없으며, UWP로 구축된 것은 ... 아시다시피 ...

그리고 그것은 너무 어렵기 때문입니다. Window10은 인터넷, 안드로이드 다음으로 큰 플랫폼입니다!!! 그러나 아무도 그 목적을 위해 만들어진 도구로 앱을 만들고 있지 않습니다! 그것에 대해 생각해보십시오. UWP가 있는 Windows용보다 3가지 운영 체제용 Electron 앱을 빌드하는 것이 더 쉽습니다!

우수한 도구를 요구하는 Windows 데스크톱 앱을 구축하려는 구타당한 우리에게 괜찮습니까? 나는 당당하게 예라고 말합니다! 그러나 우리에게 있는 것은 Microsoft의 무전 무음뿐입니다. 앱이 Holo Lens, Windows Phone 또는 Xbox에서 작동할 수 있다는 동화를 누가 듣고 싶습니까? 아무도. 5년 후 UWP에 대해 약속된 플랫폼에서 작동하는 상용 앱이 없습니다. (대부분 해당 플랫폼이 종료되지 않기 때문입니다). 다시 한 번 생각해보세요! 우리에게 일어난 가장 좋은 일은 WinUI가 이전 win32로 다시 포팅되고 있다는 것입니다.

저는 Windows 데스크탑을 좋아하고 WinForms 및 WPF에서 C#을 프로그래밍하는 방법을 배웠습니다. 그리고 나 같은 멍청한 놈에게는 쉽고 훌륭했습니다. 오늘 저는 WinUI의 이 멋진 컨트롤을 보고 침이 고이지만, 누군가는 플랫폼에 대한 큰 그림을 명확하게 이해해야 합니다. 우리는 일부 MS 비즈니스 임원의 시장 열망이 아니라 실용적인 기술 리더십에 대한 명확한 메시지가 필요합니다.

안녕하세요,
나는 이 토론에 조금 늦었지만 어쨌든 나의 겸손한 의견을 말하고 싶었습니다.
상용 UWP 앱에 관하여: 내 마음에 떠오르는 것은 Adobe XD입니다. 이것은 UWP이며 매우 성숙하고 완성된 느낌입니다.
13년 동안 .Net 개발자로 일하면서 UWP에 대한 제 경험: 물론 이 도구를 사용하여 보기 좋고 성능이 좋은 앱을 만들 수 있습니다. 그러나 ... 그것은 아름다운 경험이 아닙니다. 우리는 의료 애플리케이션을 만드는 과정에 있으며 여기와 다른 곳에서 이미 언급한 많은 것들도 우리가 겪었습니다.

• 믿을 수 없는 느린 파일 API
• 매우 느린 "F5 시간". 따라서 디버그로 이동하여 응용 프로그램을 빌드/시작하여 무언가를 시도하는 것은 WPF에서보다 최소 10배 느립니다. (Surface Book 2에서 약 2분 정도)
• 일반적으로 샌드박스에 의해 제한됩니다.
  이것들은 내 머리 꼭대기에서 나온 것들입니다. 결국 XamlIslands가 출시되었을 때 우리는 WPF 창에서 전체 UWP UI를 호스팅하기로 선택했으며 모든 것 뒤에 빠른 .net 코어가 있습니다. 많은 사람들이 이 정도 규모로 XamlIsland를 사용했다고 생각하지 않습니다(우리가 만든 github 문제/PR에서 결론을 내림). 그러나 이 기술에는 몇 가지 매우 심각한 제한 사항도 있습니다. 예를 들어 컴파일 시간이 훨씬 더 길어집니다. Xaml을 실시간으로 편집할 수 있는 기능을 잃습니다. 심각한 WPF/XamlIsland/UWP 앱용 설치 프로그램을 만드시겠습니까? 아파요. 등...
  요약하자면 아름다운 UWP 앱을 만드는 것은 물론 가능합니다. 그러나 그것은 너무 비생산적이고 느립니다. 그리고 제한적입니다.
  다른 많은 사람들과 마찬가지로 우리는 "UWP" 프론트엔드와 .net 코어(또는 .net 5 ;-) ) 백엔드를 트릭 없이 가질 수 있는 WinUI 3의 출시와 성숙을 기쁘게 기다리고 있습니다.

@jasonwurzel 아주 좋은 포인트입니다.

• 파일 API는 느리지만 그동안 @duke7553 은 #1465(댓글)에 해결 방법을 게시했습니다.
  그것은 사실이지만 그때 우리는 그것에 대해 알지 못했습니다. 말할 것도 없이, 단지 빠른 파일 I/O를 얻기 위해 이 해결 방법을 구현하는 것은 미친 짓입니다...
• F5 시간은 속도를 늦추고 몇 가지 개선 사항을 사용할 수 있다고 생각합니다.
• xaml 섬 루트를 사용하는 것과 반대로 일반 UWP 앱을 개발하려고 하면 어떤 한계에 부딪혔는지 궁금합니다. 저는 지금 몇 가지 앱을 작업 중이며 Win32 프로세스를 포함하여 모든 제한 사항을 해결할 수 있었지만 앱을 만드는 데 항상 이상적인 방법은 아니라는 것을 이해합니다.
  결국 우리가 만난 장애물의 총합이라고 생각합니다. 의심할 여지 없이 일부는 외부 프로세스로 해결할 수 있었습니다. 특별한 순서 없이:
• 삽입된 미디어의 CD 트레이/USB 포트 관찰
• 로컬 PC의 어느 곳에서나 사용자가 선택한 디렉토리를 관찰하고 업데이트할 때 앱/Windows가 액세스 권한을 기억하도록 합니다.
• broadFileSystemAccess 요구, 예외 발생, 해당 Windows 설정 페이지 열기, 사용자가 앱의 토글을 확인하고, 앱이 경고 없이 닫히고, 개입할 기회가 없습니다.
• 동일한 도메인: 사용자가 Windows 스타일의 FolderPicker를 열지 않고도 디렉토리를 선택할 수 있도록 합니다.
• 닭과 계란 문제: 너겟 패키지의 가용성/지원(더 많은 사람들이 여전히 WPF를 사용하고 있으므로 작은 문제에 대한 솔루션을 찾는 것이 훨씬 더 빠름)
• 설치 위치 제어

@AndrewPawlowski GitHub의 오픈 소스인 소수를 포함하여 현대적이고 보기 좋은 훌륭한 UWP 앱이 많이 있을 때 당신이 말할 수 있다는 것에 놀랐습니다.
어떻게 해야 할지 몰라서 앱 만들기를 포기했다고 해서 플랫폼이 실패한 것이 아니라 앱이 실패한 것입니다. 주변을 둘러보면 앱이 초점을 잃을 때 소리를 계속 재생하는 앱을 포함하여 정말 좋은 앱을 만들고 열심히 일한 개발자를 많이 볼 수 있습니다.

불가능하다는 말은 아니지만 매우 어렵습니다. 그리고 저는 단순한 "메모장과 같은" 앱에 대해 이야기하는 것이 아니라 UI / 비디오 편집 / 사운드 편집 / 디스크에 많은 항목 로드/저장을 처리하는 매우 복잡한 앱에 대해 이야기하고 있습니다. ) 출시(그리고 fullTrust API에 대해 알려주지 마십시오). 50-100K 이상의 코드 줄 앱에 대해 이야기하고 있습니다.

그게 더 어렵습니다.

그리고 앱이 초점을 잃을 때 소리를 재생할 수 있다는 사실 - 아무도 당신이 할 수 없다고 말하지는 않지만 지금보다 훨씬 쉬워야 합니다.

UWP 앱을 개발하는 과정을 즐기는 사람이 있느냐고 묻자 대답은 많고 최근 몇 달간 다른 개발자들로부터 앱에 대한 도움을 요청하는 요청을 많이 받아 플랫폼이 분명히 관심을 얻고 있다는 것입니다.

동의합니다. 그래서 실제로 내 앱을 UWP로 이식하기 시작했습니다. 그러나 그것은 매우 울퉁불퉁한 길이었고, 지금도 그렇습니다.

당신은 또한 UWP 앱 개발에 대해 글을 쓰는 사람이 없다고 주장하며 그것은 단지 거짓이라고 말해야 합니다. @rudyhuyn , Martin Zikmund는 UWP에 대해 글을 쓰는 개발자의 두 가지 예일 뿐이지만 다른 많은 사람들도 있습니다.

나는 전적으로 동의하지만 wpf에 대해 쓰는 사람들과 비교하십시오. 물 한 방울입니다.

"c# wpf"(3701개 결과) 대 "c# uwp"(337개 결과)와 같은 간단한 github 검색을 수행하십시오.
같은 것을 검색하고 "커밋 수 > 500"으로 필터링하면(이는 일종의 '사용자가 프로젝트에 갇혀 있음을 의미합니다) -> 어두컴컴한 희미한 그림을 찾을 수 있을 것입니다.

이는 2020년에 보기 좋은 앱과 최신 UWP 앱을 모두 만들 수 있으며 귀하의 진술 중 많은 부분이 정확하지 않다는 것을 거의 보여줍니다.

나는 동의하지 않습니다. UWP 복잡한 앱을 개발하고 그것을 행복하게 하기 위해서 -> 우리는 그것과는 거리가 멉니다.

• xaml 섬 루트를 사용하는 것과 반대로 일반 UWP 앱을 개발하려고 하면 어떤 한계에 부딪혔는지 궁금합니다. 저는 지금 몇 가지 앱을 작업 중이며 Win32 프로세스를 포함하여 모든 제한 사항을 해결할 수 있었지만 앱을 만드는 데 항상 이상적인 방법은 아니라는 것을 이해합니다.

결국 9월에 Xaml Islands를 사용하여 win2d를 사용하려고 시도했지만 작동하지 않았습니다. MS의 몇 가지 예를 시도했지만 작동하지 않았습니다. 그 시점에서 저는 앱을 UWP로 이식해야 한다는 사실을 깨달았습니다. 그렇지 않으면 이것이 작동하지 않을 것입니다.

더 최근의 테스트에 관해서는 - https://github.com/microsoft/Win2D/issues/731

• 매우 느린 "F5 시간". 따라서 디버그로 이동하여 응용 프로그램을 빌드/시작하여 무언가를 시도하는 것은 WPF에서보다 최소 10배 느립니다. (Surface Book 2에서 약 2분 정도)

어 그래! 나는 이것을 언급조차하지 않았지만 네, 그것은 미친 듯이 느립니다. 나는 내가 컴파일하는 프로젝트와 컴파일하지 않는 프로젝트를 조정하여 문제를 해결했습니다. 그리고 내가 작업하고 있는 앱의 어느 부분에 따라 이것은 괜찮거나 끔찍합니다. 초)

• 일반적으로 샌드박스에 의해 제한됩니다.

오 예 :)

• 파일 API는 느리지만 그동안 @duke7553 은 #1465(댓글)에 해결 방법을 게시했습니다.

동의하지만 누군가가 해결 방법을 찾는 데 시간이 얼마나 걸렸는지 생각해보십시오. 분명히 존재하지만 문서에 깊이 묻혀 있습니다. 그리고 지금 당장은 아마 아주 소수의 사람들만이 그것을 알고 있을 것입니다(저를 포함하여).

Google 검색을 수행하면 해결 방법을 보여주는 게시물을 찾을 수 없으므로 대부분의 개발자가 알아차리기까지 몇 개월이 걸릴 것입니다.

@jasonwurzel

다른 많은 사람들과 마찬가지로 우리는 "UWP" 프론트엔드와 .net 코어(또는 .net 5 ;-) ) 백엔드를 트릭 없이 가질 수 있는 WinUI 3의 출시와 성숙을 기쁘게 기다리고 있습니다.

MS가 .NET 5가 출시되면 UWP 프로젝트에 사용할 수 있을 것이라고 말했습니다. "트릭"이나 .NET Core 3.x와 같은 상황이 필요하지 않습니다. 다음은 .NET 5 발표 게시물입니다. https://devblogs.microsoft.com/dotnet/introducing-net-5/

네 제가 언급한 내용입니다👍

_"현실과 완전히 동떨어진 "_의 "완전히"라는 단어는 불공평하고 정확하지 않다고 생각하지만 완전히 동 떨어져 있었다면 WinUI 팀은 UWP에서 WinUI를 분리하는 작업을 하지 않았을 것입니다. 전반적으로 WinUI 팀은 UWP/WinRT의 다른 부서보다 ​​더 많은 연락을 주고받는 것 같습니다. 현 시점에서 몇몇 팀들 사이에 어느 정도의 접촉 불감증이 존재한다는 것이 정확한 설명이 아닐까 생각합니다.

list-with-columns GUI의 중요성

WinUI 팀이 UWP/WinRT와 관련된 모든 팀 중에서 가장 실적이 좋은 팀이지만 WinUI의 프로젝트 관리에서 여전히 몇 가지 실수가 있었다고 생각합니다. 열이 포함 된 DataGrid )는 모든 고객이 매일 사용하는 필수 주요 기능입니다(예: Windows 탐색기 및 Spotify 등의 다양한 기타 예). WinRT가 시작된 이래로 열이 포함된 목록 GUI에 대한 공식 지원 이 없는지 ! 나는 이 상황이 충격적이라고 생각한다. 그런 이유로 UWP는 오늘날에도 여전히 알파 버전이라고 말합니다(아직 기능이 완전하지 않으므로 진정한 베타가 아닙니다). 대부분의 앱 개발자가 UWP를 진지하게 받아들이지 않았기 때문에 Windows Mobile이 취소된 것은 놀라운 일이 아닙니다.

WinUI의 DataGrid 공식 버전은 지난 8년 동안 지연되었습니다. DataGrid는 WinRT 1.0이 출시되었을 때 기한이 지났습니다. Microsoft가 새 시스템을 시작해서는 안 되었기 때문입니다(Nokia 등에 대한 이전 메시지에서 설명한 대로). 기본이 누락된 8년, 지연된 8년, 이제 WinUI 팀은 DataGrid를 네이티브 코드로 다운그레이드하여 더 많은 시간을 낭비함으로써 더욱 지연된 DataGrid를 만들고자 합니다. 여러 가지 이유로 UWP를 진지하게 받아들이고 신뢰하기 어렵습니다.

C++/CX는 최근에 C++/WinRT로 대체되었습니다.

다음은 "현실과 동떨어진" 상태의 또 다른 예입니다.
분명히 소프트웨어는 제정신이 아닌 방식으로 작성되어야 합니다. "제정신"이라는 용어는 단순하고 간단한 작업을 수행하기 위해 모호한 복잡한 흑마법을 사용해서는 안 된다는 의미입니다.
C++/CX는 최근에 C++/WinRT로 대체되었습니다. C++/WinRT는 정적 디스패치를 ​​통한 함수 호출을 위해 소위 _"기묘하게 반복되는 템플릿 패턴"_을 사용합니다. 단순하고 간단한 작업을 수행하기 위해 모호한 복잡한 흑마법을 사용하는 경우이기 때문에 제정신이 아닌 디자인이기 때문에 정말 끔찍한 디자인입니다. 게다가 CLR/C#은 이미 수십 년 전에 이 문제를 해결했는데 왜 WinRT 팀은 수십 년 전에 이미 해결된 아주 오래되고 원시적인 주제로 여전히 어지럽히고 시간을 낭비하고 있습니까? WinRT 팀이 바퀴를 재발명하는 이유는 무엇입니까?

나는 C++/WinRT의 새로운 소스 코드를 찾아보았고 그것에 대한 나의 인상은 그것이 매우 낮은 품질의 소프트웨어라는 것입니다. 그러나 WinRT 팀은 그것을 훌륭하게 발전된 것으로 봅니다. 따라서 "현실과 동떨어진"이 정확한 설명입니다.

UWP 파일 시스템은 아직 알파 버전입니다.

@jtorjo 와 다른 사람들은 UWP 파일 시스템 API의 성능 문제를 언급했습니다. 성능은 기능이 완전한 베타 버전으로 설명하는 데 필요한 수준 이하입니다. UWP FS API가 여전히 알파 버전인 또 다른 이유는 폴더를 이동하는 기능이 없기 때문입니다. 25년 전 Windows 95에는 폴더를 이동할 수 있는 기능이 있었지만 UWP에는 여전히 이 기본 기능이 없습니다. 어떤 면에서 Windows 95는 UWP보다 강력합니다. 다양한 면에서 WPF 및 .NET Framework는 여전히 UWP보다 강력합니다. Microsoft는 앱 개발자가 UWP를 진지하게 받아들일 것으로 예상했지만 Microsoft가 UWP를 알파에서 베타 단계로 진행하지 않았기 때문에 이는 매우 비합리적(또는 "현실과 동떨어진" 상태)이었습니다.

Windows는 "App Dev"와 같은 모바일이 급성장하는 시장이고 보안과 배터리 수명이 핵심이라는 점에서 현대적이라고 가정했습니다.

그들은 시장의 힘으로 인해 모바일 시장에서 밀려났습니다. Hololens 및 Xbox와 같은 장치는 Win32 레거시 지원을 제거하여 개발을 더 단순하게 만들고 더 성능이 좋은 OS 코드베이스를 만들려고 합니다.

이러한 내기는 완전히 성과를 거두지 못했지만 현대적인 앱 제공 및 보안 모델에 대한 이상은 칭찬할 만한 목표입니다.

따라서 Microsoft는 몇 가지 영혼 검색 후 UI 프레임워크에서 최신 앱 프레임워크를 분리하기로 결정했습니다.

WinUI 3.0은 언어 프로젝션, 최신 코딩 표준 및 모바일 친숙함의 이점을 제공하는 대부분의 최신 API에 액세스할 수 있도록 하여 두 세계 모두에서 최고여야 합니다. 또한 앱이 덜 안전하지만 더 강력한 Win32 및 .NET 런타임을 사용하도록 허용합니다.

물론 Win32 액세스에 의존하면 실행되는 플랫폼이 제한되고 향후 시장이 어디로 이동할지 누가 알 수 있습니까?

나는 똑같은 오래된 근거와 불만을 참작하는 대신 제안하고 싶습니다. 이 커뮤니티는 개발자가 앞으로 무엇을 원하는지 묻는 데 사용되며 프로젝트를 진행하지 않는 방식으로 비난하거나 비난하지 않습니다.

@mdtauk 은 다음

그들은 시장의 힘으로 인해 모바일 시장에서 밀려났습니다.

다양한 UWP/WinRT 직원은 무슨 일이 일어났는지 _기분_좋게 하기 위해 그 설명을 매우 믿고 싶어합니다. 나는 그 설명을 믿지 않는다. 다음과 같은 이유로 UWP가 실패했다고 생각합니다.

1. 잘못된 관리와
2. UWP가 준비되지 않았고 여전히 황금기를 사용할 준비가 되지 않았다는 인상 때문에 앱 개발자가 앱의 UWP 버전을 영구적으로 연기하는 문제를 해결하지 못하고
3. 비생산적인 오래된 소프트웨어 엔지니어링 기술의 과도한 사용 및
4. 대다수의 앱 개발자의 신뢰를 얻지 못하고,
5. Java 대신 JavaScript 사용을 촉진하는 것과 같이 UWP를 바보처럼 보이게 만든 것은 스크립팅 언어와 프로그래밍 언어의 차이점을 인식하지 못하는 것을 의미합니다.

안타깝게도 관리 부실이 UWP 실패의 주요 원인임을 고려할 때 UWP가 관리되지 않는 코드로 작성되었다는 것은 아이러니합니다. 왜냐하면 "관리되지 않는"이라는 단어가 실제로 실패의 원인을 요약하기 때문입니다. 소스 코드와 프로젝트 관리의 부실 관리입니다.

@jtorjo 는 다음

네이티브, ".net 네이티브로 컴파일"이라는 맥락에서 나는 좋은 일이라고 생각합니다.

나는 동의한다. 차이점은 네이티브 코드의 자동 생성과 수동 생성에 있습니다. 네이티브 코드가 컴파일러나 도구에 의해 자동으로 생성되면 일반적으로 좋은 일이지만 네이티브 소스 코드가 소스 코드를 수동으로 작성하면 생산성, 기능 집합 및 안정성이 크게 저하됩니다.

WPF 개발 기간과 WinUI 개발 기간을 비교하면 WinUI가 WPF보다 개발하기 쉽고 빨라야 한다는 사실에도 불구하고 WPF의 개발은 훨씬 더 빨랐습니다(훨씬 더 나은 생산성). WPF용으로 _이미_ 만든 개념입니다. 불행히도 Microsoft는 이전의 소프트웨어 엔지니어링 기술을 과도하게 사용하기로 결정하여 이전의 관점과 모순되고 생산성이 저하되어 앱 개발자가 UWP 앱 개발을 영구적으로 연기하게 되었습니다.

과거의 실수를 해결하기 위해 지금 무엇을 할 수 있습니까? UWP 실패로 이어진 동일한 실수를 반복하지 마십시오. 나쁜 일이 없었던 것처럼 계속하지 마십시오. 여기서는 DataGrid 를 예로 사용하겠습니다. DataGrid를 더 지연시키는 대신 DataGrid 새 기능을 추가합니다. 쓸모없는 수동 재작성/네이티브 코드로의 변환을 수행하여 DataGrid를 8년 이상 지연시키지 마십시오.

최종 사용자는 DataGrid가 관리되는 코드로 작성되었는지 또는 비관리되는 코드로 작성되었는지 여부에 신경을 덜 쓸 수 없었으며 이러한 용어가 무엇을 의미하는지 알지 못합니다. 따라서 훨씬 더 중요하고 합리적인 것은 관리 코드를 있는 그대로 유지하고 개선하는 것입니다. DataGrid의 기능/특징. UWP에서 수동으로 작성된 네이티브 코드의 양은 이미 재앙적인 상황인데, Win16/32 및 COM을 기반으로 더 많은 네이티브 코드와 훨씬 더 오래된 코드를 작성하여 상황을 더욱 악화시키는 이유는 무엇입니까?

구식 코드를 모두 버릴 수는 없지만 상황을 이미 더 악화시키는 것을 막을 수는 있다는 것을 이해합니다. 즉, 더 오래된 네이티브 코드 작성을 중단하십시오. 지금부터 모든 새로운 코드/프로젝트는 최신 소프트웨어 엔지니어링 기술을 사용하여 작성된다는 정책을 만드십시오. DataGrid 등과 같은 기존 관리 코드를 다운그레이드하지 마십시오.

UWP 파일 시스템은 아직 알파 버전입니다.
@jtorjo 와 다른 사람들은 UWP 파일 시스템 API의 성능 문제를 언급했습니다. 성능은 기능이 완전한 베타 버전으로 설명하는 데 필요한 수준 이하입니다. [...]

나는 이것을 전에 언급했고 다시 언급할 것입니다 - StorageFolder/StorageFile API는 내가 본 최악의 API 중 하나입니다. 우리는 21세기에 접어들었습니다. "아 제발, 이것과 저것에 액세스할 수 있습니까? 그런 다음 훌륭한 FuturesAccessList에 추가할 수 있습니까?"라고 묻고 싶습니다.

그리고 파일 크기와 같은 기본 속성을 비동기식으로 요청해야 합니까? 나는 이것이 어떤 근거를 가지고 있었는지 상관하지 않지만, 지금은 현실과 동떨어져 있습니다.

이러한 내기는 완전히 성과를 거두지 못했지만 현대적인 앱 제공 및 보안 모델에 대한 이상은 칭찬할 만한 목표입니다.

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

[....] 물론 Win32 액세스에 의존하면 실행될 플랫폼이 제한되고 향후 시장이 어디로 이동할지 누가 알 수 있습니까? [...]

전적으로 동의하지만, 너무 미래에 대해 생각하는 것도 고통이 될 수 있습니다...
즉, 처음부터 Win32 액세스를 제한하면 라이브러리를 이식하는 것은 거의 "금지"이므로 미래는 고사하고 현재도 없습니다.

우리가 Win32 코드도 사용할 수 있게 함으로써 다른 (예정된) 플랫폼으로 이식할 수 없을 수도 있지만 적어도 오늘을 위한 코드는 갖게 될 것입니다. 그리고 내일, 그것은 또 다른 날이 될 것이고, 우리가 거기에 도착하면 우리가 정말로 원할 때 우리의 코드를 이식할 방법을 찾아낼 것입니다.

그러나 나는 선택에 주어진 일을 하고 위험을 이해할 것입니다.

나는 똑같은 오래된 근거와 불만을 참작하는 대신 제안하고 싶습니다. 이 커뮤니티는 개발자가 앞으로 무엇을 원하는지 묻는 데 사용되며 프로젝트를 진행하지 않는 방식으로 비난하거나 비난하지 않습니다.

이것이 나를 대상으로 한 것인지 확실하지 않습니다. 저는 영어가 모국어가 아닙니다. 그렇긴 하지만, 저는 이 프로젝트가 계속 진행되기를 분명히 원하지만 배포를 방해하는 몇 가지 문제를 해결하는 것이 중요하다고 생각합니다. 바로 오늘입니다.

나는 똑같은 오래된 근거와 불만을 참작하는 대신 제안하고 싶습니다. 이 커뮤니티는 개발자가 앞으로 무엇을 원하는지 묻는 데 사용되며 프로젝트를 진행하지 않는 방식으로 비난하거나 비난하지 않습니다.

이것이 나를 대상으로 한 것인지 확실하지 않습니다. 저는 영어가 모국어가 아닙니다. 그렇긴 하지만, 저는 이 프로젝트가 계속 진행되기를 분명히 원하지만 배포를 방해하는 몇 가지 문제를 해결하는 것이 중요하다고 생각합니다. 바로 오늘입니다.

나는 누군가를 목표로 삼고 있지는 않지만 토론 제목이 약간 부정적이고 사람들이 모욕과 비난에 둘러싸여 있으면 정당한 문제에 대응하고 해결하는 경향이 없습니다.

또한 이제 우리는 Win32/.NET 앱 프레임워크가 WinUI 3.0과 함께 제공될 것이라는 것을 알고 있습니다. 과거에만 WinRT였다고 여전히 비판하는 것은 거의 의미가 없습니다. 😁

@jtorjo

우리는 21세기에 접어들었습니다. "아 제발, 이것과 저것에 액세스할 수 있습니까? 그런 다음 훌륭한 FuturesAccessList에 추가할 수 있습니까?"라고 묻고 싶습니다.

앱이 사용자에게 물어야 한다는 사실이 제 생각에는 올바른 방향으로 나아가는 단계라고 생각합니다. Winforms 및 WPF 앱과 달리 앱은 단순히 내 모든 파일을 스캔할 수 없으며 액세스할 수 있는 폴더를 제어할 수 있다는 사실은 보안상 매우 중요합니다. 사용자를 보호하기 위해 앱이 액세스할 수 있는 리소스를 제한하는 것이 나쁘다고 생각한다면 그것이 귀하의 견해라고 생각하지만 모든 앱이 내 파일로 원하는 대로 하는 것을 원하지 않습니다.

그리고 파일 크기와 같은 기본 속성을 비동기식으로 요청해야 합니까? 나는 이것이 어떤 근거를 가지고 있었는지 상관하지 않지만, 지금은 현실과 동떨어져 있습니다.

UX 포인트에서 일어날 수 있는 최악의 상황은 개발자가 디스크 작업에 약간의 시간이 걸릴 수 있다는 사실을 잊어버려 앱이 더 이상 응답하지 않는다는 것이기 때문에 UI 스레드를 차단해서는 안 된다는 근거였던 것 같습니다. await를 사용하면 문제를 해결할 수 있으며 어느 시점에서 UI 스레드를 차단 해제해야 합니다. (적어도 이것이 내가 async wait를 이해하는 방식입니다).

@mdtauk이 정확히 지적한 것처럼 토론 제목이 다소 부정적인 것은 사실이며, 같은 오래된 불만을 반복하기 보다는 그러한 토론을 사용하여 이러한 문제를 해결하기 위한 아이디어를 도출해야 합니다.

저는 우리 모두가 Microsoft 오픈 소스 행동 강령을 준수하고, 전문적인 토론을 유지하며, 참석 여부에 관계없이 모든 사람을 존중한다는 점을 명심해야 한다고 생각합니다.

https://opensource.microsoft.com/codeofconduct/

앱이 사용자에게 물어야 한다는 사실이 제 생각에는 올바른 방향으로 나아가는 단계라고 생각합니다. Winforms 및 WPF 앱과 달리 앱은 단순히 내 모든 파일을 스캔할 수 없으며 액세스할 수 있는 폴더를 제어할 수 있다는 사실은 보안상 매우 중요합니다. 사용자를 보호하기 위해 앱이 액세스할 수 있는 리소스를 제한하는 것이 나쁘다고 생각한다면 그것이 귀하의 견해라고 생각하지만 모든 앱이 내 파일로 원하는 대로 하는 것을 원하지 않습니다.

따라서 WPF 앱에 비해 큰 단점부터 시작합니다. 그것은 한 가지입니다 - 다른 것은

1. 설치 시 이미 묻고 있습니다.
2. 사용자가 주의를 기울이지 않더라도 Windows는 사용자에게 "이 앱은 파일에 대한 액세스를 원합니다"라는 메시지를 다시 표시하고 사용자는 예/아니요라고 말할 수 있습니다. 나는 그것으로 완전히 괜찮을 것입니다. 그러나 이것은 일어나고 있는 것과는 거리가 멀다.

그리고 파일 크기와 같은 기본 속성을 비동기식으로 요청해야 합니까? 나는 이것이 어떤 근거를 가지고 있었는지 상관하지 않지만, 지금은 현실과 동떨어져 있습니다.

UX 시점에서 일어날 수 있는 최악의 상황은 개발자가 잊어버려서 앱이 더 이상 응답하지 않는다는 것이기 때문에 UI 스레드를 차단해서는 안 된다는 근거가 아닐까 싶습니다.

파일 크기는 미리 가져와야 합니다(마지막 액세스 날짜/마지막 쓰기 날짜와 동일) - 매우 중요하므로 파일을 쿼리할 때 미리 가져와야 합니다.

@mdtauk이 정확히 지적한 것처럼 토론 제목이 다소 부정적인 것은 사실이며, 같은 오래된 불만을 반복하기 보다는 그러한 토론을 사용하여 이러한 문제를 해결하기 위한 아이디어를 도출해야 합니다.

나는 이것들이 완전히 해결되기를 원합니다. 다른 것은 없습니다.

저는 우리 모두가 Microsoft 오픈 소스 행동 강령을 준수하고, 전문적인 토론을 유지하며, 참석 여부에 관계없이 모든 사람을 존중한다는 점을 명심해야 한다고 생각합니다.

이 토론은 실제로 이러한 질문을 할 장소가 있고 WinRT가 다른 곳에서 피드백을 들을 수 있는 장소가 있었다면 여기에서 일어나지 않았을 것입니다.

나는 누군가를 목표로 삼고 있지는 않지만 토론 제목이 약간 부정적이고 사람들이 모욕과 비난에 둘러싸여 있으면 정당한 문제에 대응하고 해결하는 경향이 없습니다.

나는 그것이 약간 부정적이라는 데 동의합니다. 다시 한 번, WinRT 문제에 대한 피드백을 제공할 다른 곳이 있었다면 이런 일은 일어나지 않았을 것입니다.

또한 이제 우리는 Win32/.NET 앱 프레임워크가 WinUI 3.0과 함께 제공될 것이라는 것을 알고 있습니다. 과거에만 WinRT였다고 여전히 비판하는 것은 거의 의미가 없습니다. 😁

솔직히 이렇게 되기를 진심으로 바랍니다. 나는 확실히 이러한 문제가 해결될 때까지 기다릴 것이며 개인적으로 샌드박스가 아닌 플랫폼을 사용할 수 있기를 기다릴 수 없습니다. 하지만 그때까지 저는 여전히 앱을 개발 중이며 처음에 설명한 문제에 여전히 직면하고 있습니다.

따라서 WPF 앱에 비해 큰 단점부터 시작합니다. 그것은 한 가지입니다 - 다른 것은

분명히 말해서 앱이 모든 파일에 액세스하는 것을 거부하는 선택을 남겨두는 것이 당신의 의견으로는 불리합니까?
개발자로서 우리는 사용자에 대한 소프트웨어를 개발해야 합니다. 그리고 사용자가 앱에 표시되는 데이터에 대해 선택의 여지가 없도록 하는 것은 사용자에게 보안상의 단점이라고 생각합니다.

1. 설치 시 이미 묻고 있습니다.

"broadFileSystemAccess" 기능을 의미합니까? 제 생각에는 이 기능을 사용할 정당한 이유가 있는 앱이 거의 없습니다. ( @kmgallahan이 이미 지적했듯이)
매일 사용하는 모든 앱을 살펴보세요. 그 중 얼마나 많은 파일이 항상 모든 파일에 액세스해야 합니까? 아마 그렇게 많지는 않을 것입니다.

귀하의 초기 의견에서 말했듯이 :

사용자가 위와 같이 만족할 것이라고 생각하십니까? 아니요. 실제로는 79.8%가 하지 않습니다(내 AppCenter 데이터가 이를 뒷받침함).

나는 아마도 사용자들이 이것을 하는 것을 좋아하지 않는 이유가 있다고 생각합니다(이것이 그들이 변경해야 하는 보안 설정이라는 사실 외에).

그러나 모든 파일에 액세스해야 하는 모든 비즈니스 사례를 알지 못할 수도 있으므로 문제가 있으면 기꺼이 듣습니다. 하루의 끝에서 우리는 싸우기 위해 여기에 있는 것이 아니라 서로의 관점을 풍부하게 하기 위해 여기에 있습니다(잘하면) 😅

편집하다:

파일 크기는 미리 가져와야 합니다(마지막 액세스 날짜/마지막 쓰기 날짜와 동일) - 매우 중요하므로 파일을 쿼리할 때 미리 가져와야 합니다.

예, 그 중 일부는 확실히 미리 가져와야 합니다. 나는 이것이 우리 개발자들에게 다소 불편하다는 데 동의합니다.

이 토론은 실제로 이러한 질문을 할 장소가 있고 WinRT가 다른 곳에서 피드백을 들을 수 있는 장소가 있었다면 여기에서 일어나지 않았을 것입니다.

공식적으로 피드백 허브는 (내 생각에) 그것을 위한 것이지만 예, 언젠가는 약간 반응이 없는 것처럼 느껴집니다. 피드백 허브가 개선되기를 바랍니다. 내가 볼 때, 그들은 이미 시간이 지남에 따라 약간의 변경을 가했기 때문에 이것도 변경되기를 바랍니다.

@Felix-Dev

여기 .NET 5 발표 게시물이 있습니다.

링크해주셔서 감사합니다. 특히 이 부분이 흥미롭고 긍정적인 소식이라고 생각합니다.

"자바 상호 운용성은 모든 플랫폼에서 사용할 수 있습니다.

또한 Rich Lander가 양방향 상호 운용성을 확인하는 해당 웹 페이지의 끝에 있는 주석에 약간의 Java 토론이 있습니다. 저는 이것을 Microsoft가 현실에 다시 접근하고 있다는 긍정적인 신호로 해석합니다. 저는 Java 팬이 아니지만(C# 선호) Java 상호 운용성이 매우 유용하며 처음부터 UWP/WinRT의 초점이 되어야 한다는 점을 인정합니다. UWP/WinRT가 투박한 이전 네이티브 코드(C++/CX, Win16/32, COM) 대신 Java 및 C#(관리 코드)에 최우선 순위를 부여하고 UWP가 JavaScript와 Java의 목적을 혼동하지 않았다면 그렇다면 UWP는 더 많은 앱 개발자를 끌어들였을 것이고 Windows Mobile은 오늘날에도 살아있을 것입니다.

좋든 싫든 일어나서 상황의 현실을 인정해야 합니다. 시장 리더는 Java 앱 개발에 중점을 둔 Android입니다. Java 및 C#은 관리 코드를 의미합니다. Microsoft는 관리 코드에 대한 입장을 뒤집었을 때 막대한 비용이 드는 실수를 저질렀습니다.

나는 자바를 별로 좋아하지 않지만, 안드로이드의 자바 기술이 마이크로소프트가 16비트 대 32비트 포인터와 같은 고대 Win16 프로그래밍 기술을 사용하여 WebView2를 개발하는 투박한 옛날 방식보다 훨씬 낫다는 것은 분명합니다. , 및 HRESULT 대신 현대적인 예외 처리 등. WebView2는 LPCWSTR 를 사용하고 L 는 16비트가 아닌 32비트 포인터를 의미하는 "긴 포인터"를 의미합니다. Win16의 "짧은" 포인터. W 는 8비트 ASCII/ANSI 문자가 아닌 유니코드(UTF-16)를 의미하는 "와이드 문자"를 의미합니다. 이에 비해 Android의 Java 사용은 Microsoft의 일부 부서에서 수행하는 것보다 훨씬 더 전문적이고 현대적이며 신뢰를 불러일으키고 있습니다.

따라서 긍정적인 측면에서 Microsoft가 Java를 지원할 것이라는 소식을 듣게 된 것은 정말 좋은 소식입니다(개인적으로는 Java보다 C#을 선호하지만). Android 앱 개발자는 신뢰할 수 있는 Java interop이 출시되는 즉시 Windows에 대한 관심을 높일 것입니다.

또한 이제 우리는 Win32/.NET 앱 프레임워크가 WinUI 3.0과 함께 제공될 것이라는 것을 알고 있습니다. 과거에만 WinRT였다고 여전히 비판하는 것은 거의 의미가 없습니다. 😁

1. 미래는 밝습니다. 저는 WinUI에서 개발되고 있는 것을 보고 있습니다.
2. 과거는 매우 암울했습니다. 9억 개의 장치가 있는 플랫폼에서 UWP의 낮은 보급률은 방어하기 어렵습니다. 편집: 과거는 우리가 배울 수 있는 유일한 장소이므로 토론하는 것이 중요합니다.
3. 내 생각에 현재 는 이 스레드의 요점이며 다루지 않고 있습니다. 개발에 1~1.5년이 소요되는 간단한 앱을 오늘 시작하려는 사람이 있다면 어떤 솔직한 조언을 해줄 수 있을까요? 내 대답은 다음과 같습니다. WinUI로 실험하고, dotnet Core에서 라이브러리를 만들고, 실제로 앱 만들기를 시작하기 위해 WinUI3.0이 나올 때까지 기다리세요. 어쨌든 UWP를 앱에서 버리고 싶기 때문에 UWP를 신경 쓰지 마십시오. 현재에 대한 질문은 사소한 것이 아닙니다. 비즈니스 결정은 오늘 내려야 합니다.

말하지 않았지만 실제로 일어나고 있는 일은 UWP 및 최신 UI가 win32로 확장되지 않고 있지만 실제로 UWP가 스택에서 리팩터링되고 있다는 것 입니다. dotnet standard 2와 dotnet core 3, 그리고 사용 가능한 모든 라이브러리를 사용할 수 있는데 왜 UWP를 다루려고 할까요?

UWP에 소개된 샌드박싱 및 기타 좋은 아이디어: 좋은 아이디어였지만 훨씬 더 잘 실행될 수 있었습니다. 그들이 돌아와서 샌드박스에 OPT-IN 또는 UWP와 유사한 상태 관리에 OPT-IN의 가능성이 있기를 바랍니다. 개발자로서 우리는 사용자에게 서비스를 제공하고 싶지만 UWP에서는 플랫폼이 포함해야 하는 문제로 위협을 받았습니다.

어떤 정직한 조언을 할 수 있습니까? 기다리다?

@AndrewPawlowski UWP와 샌드박스가 작동하지 않는다고 판단했다면 WinUI 3이 출시될 때까지 MSIX 패키지 WPF 앱을 작성하는 것이 좋은 선택이라고 생각합니다. 이미 Windows 10 독점 API를 호출하고, 사용자에게 최신 설치/제거 경험을 제공하고, 일반적으로 Windows 10 API 표면에서 원하는 것과 그렇지 않은 것을 선택할 수 있습니다(즉, Windows 10 Shell API 사용을 시작할 수 있음). 일부 WinRT API는 과거의 win32 방식에 비해 작업하기가 정말 즐겁고 일부 시나리오는 순수 UWP가 아닌 DesktopBridge에서 가장 잘 수행된다고 생각합니다. 적절한 사례: 로그인 시 자동 시작을 위한 앱 등록, UWP와 DesktopBridge 동작 비교는 이 게시물 을 참조 두 번 묻지 않습니다(처음에는 앱에서 토글한 다음 확인을 요청하는 시스템 프롬프트). 앱에서.

불행히도, WPF API의 많은 부분이 UWP UI API와 비교할 때 실제로 수명을 보여주고 있으므로 최소한 몇 개월은 더 견뎌야 합니다. 사용 가능한 많은 WPF 도구 키트가 이러한 사실을 완화할 수 있지만 Windows 데스크톱 앱(및 최신 XAML 개발 환경!)에 대한 기본 모양과 느낌을 진정으로 원하는 경우 UWP UI API(및 나중에 WinUI 3 API). 즉, 나중에 WinUI용 WPF UI 코드 중 일부를 재사용할 수 있다고 해도 UI 현대화는 여전히 꽤 큰 작업 항목이 될 것이라고 생각합니다.

WinUI 3가 출시될 때까지 기다릴 수 없고 UWP가 옵션이 아닐 때 현재 보고 있는 기본 Windows 앱 개발 상태입니다.

@AndrewPawlowski

1. 미래는 밝습니다. 저는 WinUI에서 개발되고 있는 것을 보고 있습니다.

동의

1. 과거는 매우 암울했습니다. 9억 개의 장치가 있는 플랫폼에서 UWP의 낮은 보급률은 방어하기 어렵습니다. 편집: 과거는 우리가 배울 수 있는 유일한 장소이므로 토론하는 것이 중요합니다.
2. 내 생각에 현재 는 이 스레드의 요점이며 다루지 않고 있습니다. 개발에 1~1.5년이 소요되는 간단한 앱을 오늘 시작하려는 사람이 있다면 어떤 솔직한 조언을 해줄 수 있을까요? 내 대답은 다음과 같습니다. WinUI로 실험하고, dotnet Core에서 라이브러리를 만들고, 실제로 앱 만들기를 시작하기 위해 WinUI3.0이 나올 때까지 기다리세요. UWP로 귀찮게하지 마십시오.

처음 생각은 똑같았는데 기다리지 않고....

UWP에 소개된 샌드박싱 및 기타 좋은 아이디어: 좋은 아이디어였지만 훨씬 더 잘 실행될 수 있었습니다.

100% 동의

그러나 모든 파일에 액세스해야 하는 모든 비즈니스 사례를 알지 못할 수도 있으므로 문제가 있으면 기꺼이 듣습니다. 하루의 끝에서 우리는 싸우기 위해 여기에 있는 것이 아니라 서로의 관점을 풍부하게 하기 위해 여기에 있습니다(잘하면) 😅

자료를 미리 보고 싶은 곳이면 어디에서나 파일에 빠르게 액세스할 수 있습니다. 제 경우에는 사진/비디오가 있는 위치를 사용자에게 시각적으로 보여주기 위해 폴더를 미리 보고 싶고, 비디오의 경우 사용자가 선택하기 전에 비디오를 미리 보기를 원합니다. 요점은 파일 선택기가 상당히 수준 이하의 경험을 제공한다는 것입니다. 저는 이를 풍부하게 만들고 싶었습니다.

공식적으로 피드백 허브는 (내 생각에) 그것을 위한 것이지만 예, 언젠가는 약간 반응이 없는 것처럼 느껴집니다. 피드백 허브가 개선되기를 바랍니다. 제가 볼 땐 이미 시간이 지나면서 약간의 변경을 가했으니 이것도 변경되리라 생각합니다(^∇^)

개인적으로 나는 피드백 허브를 좋아하지 않습니다. 다른 문제들 중에서 너무 구체적이지 않습니다.

@jtorjo @chingucoding WinRT API용 피드백 허브는 곧 Microsoft Q&A와 교체/ 하세요 .

Chigusa가 거기에 언급된 것을 보면: @chigy Microsoft Q&A 플랫폼이 WinUI가 아닌 WinRT API에 대해 선호되는 피드백 플랫폼이 될까요? 그렇지 않은 경우 피드백 허브와 어떤 관련이 있습니까(예: Q&A의 버그/질문, 피드백 허브의 API 요청...)?

세 가지 다른 피드백 플랫폼으로 끝나지 않기를 바랍니다 😆

이것은 UWP에 대한 토론이므로 기능 요청을 승격할 수 있습니다. https://aka.ms/AA71n2t btw 파일 형식 연결 없이 파일 탐색기 통합으로 상황에 맞는 메뉴 동사 허용. https://aka.ms/AA6rmrk (하지만 잘못된 카테고리에 있습니다. 누군가 이 문제를 해결할 수 있을까요?)

기능 요청의 좋은 출처는 다음과 같습니다.
https://web.archive.org/web/20161221051552/https://wpdev.uservoice.com/forums/110705-universal-windows-platform/category/171141-missing-apis
유감스럽게도 이 사용자 음성의 스냅샷은 꽤 오래되었습니다(2016). 다음과 같은 내용이 있었던 것으로 기억합니다.

• 카메라, 위치, 시작 시 앱 시작을 요청할 때 동작하는 것처럼 broadFileSystemAccess 요청 동작을 정렬합니다.
• 자동. 인쇄(현재 내가 기억하는 한 IoT의 POS에만 지원됨)
• 인쇄를 더 구성 가능하게 만들기

@jtorjo

자료를 미리 보고 싶은 곳이면 어디에서나 파일에 빠르게 액세스할 수 있습니다. 제 경우에는 사진/비디오가 있는 위치를 사용자에게 시각적으로 보여주기 위해 폴더를 미리 보고 싶고, 비디오의 경우 사용자가 선택하기 전에 비디오를 미리 보기를 원합니다. 요점은 파일 선택기가 상당히 수준 이하의 경험을 제공한다는 것입니다. 저는 이를 풍부하게 만들고 싶었습니다.

내 생각에는 먼저 사용자가 앱을 사용하려는 폴더를 선택하게 하는 것 같습니다. 결국 사용자는 자신의 비디오를 저장한 위치를 가장 잘 압니다.

그렇지 않으면 다음을 살펴보고 싶을 수 있습니다.
https://docs.microsoft.com/en-us/windows/uwp/files/quickstart-managing-folders-in-the-music-pictures-and-videos-libraries

그러나 솔직히 말해서, 나는 그 경우에 broadFileSystemAccess가 정확히 무엇을 도울 것인지 모르겠습니다. 사용자와 달리 파일이 정확히 어디에 있는지 확신할 수 없습니다. 하지만 앱의 개념을 제대로 이해하지 못한 것일 수도 있습니다.

@Felix-Dev
정보 감사합니다. WinRT 피드백이 움직일 줄은 몰랐습니다.

세 가지 다른 피드백 플랫폼으로 끝나지 않기를 바랍니다 😆

하하 예, 아니길 바랍니다!

@jtorjo -- WPF에서 UWP로 앱 이식을 취소 하는 것을 고려했습니까? 취소하고 WinUI 3이 출시될 때까지 기다리면 문제가 있는 UWP 파일 시스템 API, broadFileSystemAccess 등을 강제로 사용하지 않아도 됩니다. 그동안 WinUI 3을 기다리는 동안 계속해서 앱의 WPF 버전을 계속 개발하여 사용자에게 새 버전의 앱을 제공합니다.

WinRT가 시작된 후 8년 동안 우리는 실제로 사용자에게 WinRT나 UWP 앱을 제공한 적이 없습니다. 대신 우리는 소프트웨어의 WPF 버전을 계속 사용하는 많은 업데이트를 제공했습니다. 사용자는 WPF, WinUI, UWP와 같은 기술 세부 정보에 신경 쓰지 않고 앱이 얼마나 잘 작동하고 어떤 기능을 가지고 있는지에 관심이 있기 때문에 이에 대해 전혀 불만이 없습니다. 또한 WPF 앱에는 GUI 현대화가 많이 포함되어 있기 때문에 사용자는 이전 GUI에 대해 불만이 없습니다.

@AndrewPawlowski 는 "

UWP에서 WinUI 3의 분리가 큰 도움이 되지만 완전한 솔루션은 아니라고 생각합니다. WinUI 3은 WinUI의 낮은 생산성/느린 개발 속도를 해결하지 않습니다. WPF는 WinUI보다 훨씬 어려웠지만 WPF는 WinUI보다 훨씬 빠르게 개발되었습니다.

WinUI 팀은 WinUI 3가 오픈 소스일 때 속도가 빨라질 것이라고 말하고 아마도 그럴 수도 있지만 개인적으로 WinUI 3에 대한 C++/CX, C++/WinRT, Win16/32 또는 COM 기여를 작성하지 않을 것이라고 말합니다. 수십 년 전에 Win16/Win32로 경력을 시작했으며 Win32는 악몽이었습니다. 저는 그런 오래되고 문제가 있는 프로그래밍 기술로 되돌릴 생각이 없습니다. 수년에 걸쳐 저는 소프트웨어 엔지니어링 기술을 최신 상태로 유지하고 C# 및 .NET Framework로 전환했으며 이는 주요 개선 사항이자 이점이었으며 이전 Win16/32의 악몽으로 돌아가지 않을 것입니다. 일과 많은 양의 수동으로 작성된 네이티브 코드.

@AndrewPawlowski 는 다음

어떤 정직한 조언을 할 수 있습니까? 기다리다?

정말 대답하기 어려운 질문입니다. 한편으로는 WinUI 3을 기다리지만, 다른 한편으로는 WinUI 3이 8년 전에 WinRT에서 시작된 큰 문제의 완전한 해결이 아닙니다. WinUI 3은 유용한 부분 해결 방법입니다.

Ignite의 멋진 비디오: https://youtu.be/Ul5JcdIJv5s

나는 여기서 많은 토론이 WinRT의 목적에 의문을 제기한다고 생각합니다. 개발자와 사용자는 여전히 WinUI 3 및 .NET 5.0이 서로 다른 기술 간의 쉬운 상호 운용을 허용하면 어떤 역할을 할지 궁금해합니다. 말할 것도 없이 샌드박스와 클래식 앱 모델 사이에서 선택하는 궁극적인 기능입니다.

Microsoft가 내부적으로 새 WinRT API를 작성하는 것이 더 쉽다고 가정합니다. 이는 API 계층 혁신의 대부분이 WinRT 내에서 수행될 것이라고 이전에 여러 번 언급한 이유를 설명합니다. 이는 새롭고 현대적인 Windows 응용 프로그램의 경우 새로운 폼 팩터와 함께 제공될 새로운 경험과 가장 최신의 통합을 제공할 것이기 때문에 WinRT를 사용하는 것이 합리적임을 의미합니다. WinRT는 Windows의 .NET 앱에서 켜지는 특정 범용 API 집합으로만 사용됩니다.

즉, UWP 데스크톱 확장 팩이 기존 Windows 셸과 더 나은 통합 기능을 제공한다면 유니버설 앱의 가치를 높일 수 있다는 데 모두 동의한다고 생각합니다.

누가 알겠습니까? Microsoft는 결국 Windows 탐색기 셸을 Windows 10X 등에서 발견된 최신 구성 가능한 셸(CShell)로 교체할 계획을 가지고 있을지 모릅니다. Twitter의 전문가들도 Windows에서 발견된 새로운 UDK(도킹되지 않은 개발 키트)를 발견했습니다. 앞으로 이 새로운 쉘과 더 잘 통합될 것입니다.

@AndrewPawlowski

900million 하나가 충분히 크므로 다른 플랫폼을 원하지 않을 것입니다.

무슨 말인지 알겠지만 UWP와 .NET은 더 이상 상호 배타적인 것이 아니라는 점을 깨달아야 합니다. 따라서 유니버설 기능으로 앱을 시작하는 것이 합리적이라면 WinRT의 일부를 이해하는 데 투자해야 합니다.

나는 탈선한다. 순수한 UWP 앱 모델로 Windows 파일 탐색기 경쟁자를 구축한 사람으로서 WinUI 3는 충분히 빨리 올 수 없습니다. 가까운 장래에 유니버설 기능과 "9억 명의 사용자" 중 하나를 선택하지 않아도 됩니다 😀

@jtorjo 덜 부정적으로 인식될 제목으로 변경하는 것이
아마도 "WinRT에 가치를 더할 기회"

@verelpode

@jtorjo -- WPF에서 UWP로 앱 이식을 취소 하는 것을 고려했습니까? 취소하고 WinUI 3이 출시될 때까지 기다리면 문제가 있는 UWP 파일 시스템 API, broadFileSystemAccess 등을 강제로 사용하지 않아도 됩니다. 그동안 WinUI 3을 기다리는 동안 계속해서 앱의 WPF 버전을 계속 개발하여 사용자에게 새 버전의 앱을 제공합니다.

나는 이것에 대해 오랫동안 열심히 생각했습니다. 이것이 내가 하고 싶은 것입니다. 그러나 나는 그것을 할 수 없습니다. 왜냐하면 저는 정말로 win2d(또는 그 이상, Direct2D에 대한 좋은 래퍼)가 필요하기 때문입니다. ShapDX(Direct2D에 대한 또 다른 래퍼)는 훨씬 더 복잡해 보였으므로 win2d(UWP)를 사용하기로 결정했습니다. 따라서 모든 것을 UWP로 이식하십시오.

내 생각에는 먼저 사용자가 앱을 사용하려는 폴더를 선택하게 하는 것 같습니다. 결국 사용자는 자신의 비디오를 저장한 위치를 가장 잘 압니다.

당신은 정말로 그것에 당신의 인생을 걸고 있습니까? 나는 - 분명히, 당신이 고급 사용자라면 미친 듯이 조직적이고 모든 것이 어디에 있는지 알고 있을 것입니다. 그렇지 않으면....

그런 다음 사용자(사용자)가 어떻게든 사진/비디오를 새 폴더에 복사할 때마다 내 앱에 해당 항목도 포함하도록 알려야 합니다...

"훌륭한" FutureAccessList - 실제로 지정하지 않음 -> 폴더를 추가하면 모든 하위 폴더에 내 앱에 액세스할 수 있습니까?

또한 FutureAccessList에 무언가를 추가했다면 거기에서 검색해야 합니까 아니면 GetFolderFromPathAsync/GetFileFromPathAsync를 사용하여 얻을 수 있습니까(전자는 절벽에서 뛰어내리고 싶습니다)?

그리고 FutureAccessList.AddOrReplace를 사용하고 파일의 경로를 토큰으로 사용하면 예외가 발생한다는 사실을 알고 계셨습니까? 얼마나 사려깊은가... (설명 어디에도 없음)

WinUI 3 및 .NET Core는 향후 옵션이 될 것입니다. UWP의 샌드박스가 없는 조합은 WPF와 동일한 방식으로 작동하지만 최신 XAML 컨트롤, Visual Layer 및 간단한 WinRT API 액세스를 통해 작동할 것이라고 가정합니다.

내 생각에는 먼저 사용자가 앱을 사용하려는 폴더를 선택하게 하는 것 같습니다. 결국 사용자는 자신의 비디오를 저장한 위치를 가장 잘 압니다.

당신은 정말로 그것에 당신의 인생을 걸고 있습니까? 나는 - 분명히, 당신이 고급 사용자라면 미친 듯이 조직적이고 모든 것이 어디에 있는지 알고 있을 것입니다. 그렇지 않으면....

사용자가 자신의 동영상을 어디에 저장했는지 모른다면 앱은 어떻게 해야 할까요? 가장 빠른 소프트웨어로도 몇 시간이 걸릴 수 있는 시스템의 모든 파일을 스캔합니까? 적어도 나에게 이것은 좋은 경험처럼 보이지 않습니다. 결국, 앱이 비디오로 무언가를 하려는 사용자를 대상으로 하는 경우 사용자는 이미 어딘가에 비디오가 있다는 것을 알고 있다는 의미에서 어느 정도 "조직화"되어 있습니다. 하지만 다시 말하지만, 귀하의 앱과 특정 비즈니스 사례를 제대로 알지 못한 채 제 생각일 뿐입니다.

그런 다음 사용자(사용자)가 어떻게든 사진/비디오를 새 폴더에 복사할 때마다 내 앱에 해당 항목도 포함하도록 알려야 합니다...

상위 디렉토리에 대한 액세스 권한이 있으면 향후 하위 폴더에도 액세스할 수 있다고 생각합니다(100% 확신할 수는 없지만).

그리고 FutureAccessList.AddOrReplace를 사용하고 파일의 경로를 토큰으로 사용하면 예외가 발생한다는 사실을 알고 계셨습니까? 얼마나 사려깊은가... (설명 어디에도 없음)

이상합니다. 이것은 확실히 문서화되어야 하는 것입니다!

개인적으로 많은 앱이 필요하지 않기 때문에 "broadFileSystemAccess"를 요청하는 앱의 팬이 아닙니다. 이해가 되는 경우가 있을 수 있지만(파일 탐색기 작성 등) 일부 폴더에 액세스해야 하는 많은 경우에는 "모든 파일에 대한 액세스를 허용해 주세요"라고 말하면 안 됩니다. 특히 해당 폴더.

그러나 아마도 나는 그러한 비즈니스 사례를 충분히 알지 못합니다. 더 있으면 듣고 싶습니다!

그러나 아마도 나는 그러한 비즈니스 사례를 충분히 알지 못합니다. 더 있으면 듣고 싶습니다!

• 압축 해제 도구와 같은 도구 및 유틸리티 소프트웨어. 현재 파일이 있는 동일한 디렉터리에 압축 파일을 추출하려는 경우 Windows 탐색기 상황에 맞는 메뉴에서 앱을 호출할 때 선택한 파일에 대한 쓰기 권한만 얻었습니다. 따라서 (압축되지 않은 파일의 경우) 새 파일이나 디렉토리를 생성할 수 없습니다.

  • 사용자가 파일을 uwp 앱으로 드래그하면 해당 파일에 대한 쓰기 권한이 없습니다!
    https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

(압축 해제 도구처럼). 현재 파일이 있는 동일한 디렉터리에 압축 파일을 추출하려는 경우 Windows 탐색기 상황에 맞는 메뉴에서 앱을 호출할 때 선택한 파일에 대한 쓰기 권한만 얻었습니다. 따라서 (압축되지 않은 파일의 경우) 새 파일이나 디렉토리를 생성할 수 없습니다.

단일 파일을 마우스 오른쪽 버튼으로 클릭할 때 전체 폴더에 액세스해야 하는지 여부는 매우 논쟁의 여지가 있다고 생각합니다. 비록 보통 백업이나 다운로드/업로드와 같은 "교환"에만 필요하기 때문에 압축/압축 해제할 때 다른 폴더를 지정합니다. 따라서 파일을 정확히 저장할 위치를 지정하는 것이 거의 필요합니다. 그러나 이것은 사용자 선택에 따라 유효한 사용 사례일 수 있습니다 😅

사용자가 파일을 uwp 앱으로 드래그하면 해당 파일에 대한 쓰기 권한이 없습니다!
https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

글쎄, 그것은 사용자와 개발자에게 약간 지나치게 복잡해 보입니다. 삭제된 파일에 대해 최소한 쓰기 액세스 권한을 얻을 수 있을 것으로 예상했습니다. 제 생각에는 이것은 개발자에게 불필요한 제약일 뿐입니다.

적어도 일상적인 앱 사용에서는 파일을 GitHub 주석에만 드롭합니다. 다른 모든 경우에는 두 번 클릭하거나 마우스 오른쪽 버튼을 클릭하지만 일부 경우에는 좋지 않다는 데 동의했습니다. 결국 모든 파일에 액세스할 수 있는 것이 타당한 경우가 몇 가지 있다고 생각합니다.

사용자가 자신의 동영상을 어디에 저장했는지 모른다면 앱은 어떻게 해야 할까요? 가장 빠른 소프트웨어로도 몇 시간이 걸릴 수 있는 시스템의 모든 파일을 스캔합니까? ...

분명히 많은 가능성이 있습니다. 그 중 하나는 사용자가 폴더를 확장할 때 미리보기를 하는 것입니다. 그래서 어떤 폴더에 사진/비디오가 있고 어떤 폴더가 없는지 쉽게 알 수 있습니다. 내 앱이 실제로 수행할 작업 중 하나는 Windows에서

개인적으로 많은 앱이 필요하지 않기 때문에 "broadFileSystemAccess"를 요청하는 앱의 팬이 아닙니다.

난 상관없어. WinRT의 샌드박스 파일 시스템 보호 모델은 현실과 동떨어져 있습니다. 이것은 누군가가 단순히 데스크탑에 적용되지 않는 "모바일 퍼스트" 만트라에서 가져온 것입니다.

사실, 파일/폴더를 샌드박스 처리하는 훨씬 더 현명한 방법은 사용자가 보호하려는 파일/폴더를 결정하게 하는 것입니다. 그렇게 하는 매우 쉬운 방법이 있어야 합니다(예: 파일 탐색기에서 마우스 오른쪽 버튼 클릭 명령으로). .

이는 기본적으로 모든 것을 차단한 다음 실수로 사용자가 실수로 기밀 파일에 대한 액세스 권한을 부여하는 것과 대조됩니다.

직설적으로 말하겠습니다. 사소하지 않은 앱은 진공 상태에 있지 않습니다.

분명히 많은 가능성이 있습니다. 그 중 하나는 사용자가 폴더를 확장할 때 미리보기를 하는 것입니다. 그래서 어떤 폴더에 사진/비디오가 있고 어떤 폴더가 없는지 쉽게 알 수 있습니다. 내 앱이 실제로 수행할 작업 중 하나는 Windows에서

네, 그럴 가능성이 있습니다. 하지만 언제 폴더를 스캔할 예정입니까? 그리고 사용자가 앱에서 정확히 어떤 폴더를 확장할 수 있습니까?

난 상관없어.

여기서 정확히 무엇을 말하려는 것입니까?

사실, 파일/폴더를 샌드박스 처리하는 훨씬 더 현명한 방법은 사용자가 보호할 파일/폴더를 결정하도록 하는 것입니다. 그렇게 하는 매우 쉬운 방법이 있어야 합니다(예: 파일 탐색기에서 마우스 오른쪽 버튼 클릭 명령으로). . 사용자는 어떤 문서/파일이 기밀인지 명확하게 알고 보호할 수 있습니다.

이 전체 액세스 보호는 "기밀" 파일뿐만 아니라 일반적인 개인 정보, 예를 들어 구성 파일(일반적으로 사용자가 볼 수 없는 폴더에 숨겨져 있음) 또는 설치된 프로그램에 관한 것입니다. 이것들은 모든 프로그램, 특히 당신이 부르는 "사소한 앱"이 액세스할 수 있기를 원하지 않는 정보입니다.

그리고 실제 비유도 있습니다. 그냥 seifs를 생각해 보세요.

예, 금고에서 물건을 멀리 볼 수 있습니다. 그러나 이것은 당신이 아파트나 집의 열쇠를 가지고 있다는 사실을 바꾸지 않습니다. 그러나 모든 프로그램이 금고에 있는 것을 제외하고 모든 것에 접근할 수 있다고 말하는 것은 귀중품을 위한 금고가 있기 때문에 아파트에 문이 필요하지 않다고 말하는 것과 같습니다.

이는 기본적으로 모든 것을 차단한 다음 실수로 사용자가 실수로 기밀 파일에 대한 액세스 권한을 부여하는 것과 대조됩니다.

이 실수는 두 경우 모두 발생할 수 있지만 실수로 기밀 파일에 액세스 권한을 부여하는 것보다 기밀 파일을 잠그는 것을 잊어버릴 가능성이 더 높다고 생각합니다.

직설적으로 말하겠습니다. 사소하지 않은 앱은 진공 상태에 있지 않습니다. 어딘가(입력)에서 데이터를 가져와 어딘가에 출력해야 합니다. 입력 및 출력은 종종 파일입니다. 다른 앱 등과 상호 운용해야 합니다. 그리고 WinRT는 사용자에게 제공할 멋진 UI를 디자인하는 것을 불가능하게 만듭니다.

(불행하게도 많지는 않지만) 훌륭한 UWP 앱이 많기 때문에 불가능하다고 말하는 것은 여기에서 스트레치입니다.

네, 그럴 가능성이 있습니다. 하지만 언제 폴더를 스캔할 예정입니까? 그리고 사용자가 앱에서 정확히 어떤 폴더를 확장할 수 있습니까?

Windows 탐색기의 개념에 대해 알고 있습니까? 폴더나 드라이브를 확장하면 스캔이 시작됩니다.

이 전체 액세스 보호는 "기밀" 파일뿐만 아니라 일반적인 개인 정보, 예를 들어 구성 파일(일반적으로 사용자가 볼 수 없는 폴더에 숨겨져 있음) 또는 설치된 프로그램에 관한 것입니다. 이것들은 모든 프로그램, 특히 당신이 부르는 "사소한 앱"이 액세스할 수 있기를 원하지 않는 정보입니다.

앱이 자체 "이 앱만 액세스할 수 있음" 폴더에 파일을 보관하는 경우 문제가 되지 않습니다.

이는 기본적으로 모든 것을 차단한 다음 실수로 사용자가 실수로 기밀 파일에 대한 액세스 권한을 부여하는 것과 대조됩니다.

이 실수는 두 경우 모두 발생할 수 있지만 실수로 기밀 파일에 액세스 권한을 부여하는 것보다 기밀 파일을 잠그는 것을 잊어버릴 가능성이 더 높다고 생각합니다.

나는 완전히 동의하지 않습니다. "기밀"의 요점은 해당 파일을 잠그고 싶게 만들어야 합니다.

(불행하게도 많지는 않지만) 훌륭한 UWP 앱이 많기 때문에 불가능하다고 말하는 것은 여기에서 스트레치입니다.

당신은 여기에서 자신과 모순됩니다. 그러나 훌륭한 UWP 앱의 광대함을 탐구해 보겠습니다.

얼마나 많은 사람들이 그것을 사용하고 있는지 알려줄 '좋아요'의 "풍부함"에 주목하십시오. 애플스토어와 대조를 하고 싶었는데 사과가 없어서 그러지 못해요. 하지만 Android를 살펴보겠습니다. Facebook에는 7천만 개 이상의 리뷰가 있습니다(Windows의 경우 1353개). Instagram에는 9300만 개 이상의 리뷰가 있습니다(여기서는 1578개와 비교). 그리고 저는 Fb와 Instagram이 UWP가 아니라 실제로 전자 앱이라고 거의 확신합니다.

Windows 탐색기의 개념에 대해 알고 있습니까? 폴더나 드라이브를 확장하면 스캔이 시작됩니다.

그래서 폴더에서 비디오 파일을 미리 볼 수 있는 Windows 탐색기와 유사한 것을 구축하고 있습니까?

앱이 자체 "이 앱만 액세스할 수 있음" 폴더에 파일을 보관하는 경우 문제가 되지 않습니다.

따라서 앱은 일반적으로 모든 파일에 액세스할 수 있어야 하지만 다른 한편으로 일부 파일과 폴더는 사용자에 의해 잠깁니다(그는 "기밀" 파일만 갖고 나머지는 자동으로 기밀이 아님). 일부 폴더는 앱 테마 자체에 의해 차단되었습니까? 그리고 프로그램에 의해 생성된 파일을 처리할 앱을 프로그래밍하려면 어떻게 해야 합니까? 모든 백업 프로그램이 프로그램을 백업할 수 없기 때문에 실패합니까? 어떻게 될지 잘 모르겠고, 여기서 당신의 생각을 오해했다면 죄송합니다.

나는 완전히 동의하지 않습니다. "기밀"의 요점은 해당 파일을 잠그고 싶게 만들어야 합니다.

그렇다면 정확히 무엇을 기밀로 선택하지 않을 것입니까? 모든 앱에서 내 휴가 사진을 볼 수는 없지만 Photoshop에서는 사진을 볼 수 있어야 합니다. 그래서 그들은 기밀입니까? 아니면 이 기밀 "플래그" 목록이 일부 앱에 대해 기밀이 아닌 프로그램 및 일부 파일입니까?

당신은 여기에서 자신과 모순됩니다.

그래, 거기 내 말은 쓰레기였어. 미안합니다. 나는 잘 작동하는 "사소하지 않은" 훌륭한 앱이 분명히 존재한다는 것을 나타내고 싶었습니다.

얼마나 많은 사람들이 그것을 사용하고 있는지 알려줄 '좋아요'의 "풍부함"에 주목하십시오. 애플스토어와 대조를 하고 싶었는데 사과가 없어서 그러지 못해요. 하지만 Android를 살펴보겠습니다. Facebook에는 7천만 개 이상의 리뷰가 있습니다(Windows의 경우 1353개). Instagram에는 9300만 개 이상의 리뷰가 있습니다(여기서는 1578개와 비교). 그리고 저는 Fb와 Instagram이 UWP가 아니라 실제로 전자 앱이라고 거의 확신합니다.

이것은 UWP의 문제가 아니라 다음과 같은 사실에 있습니다.

1. 사람들은 일반적으로 댓글을 작성하지 않는 경향이 있습니다.
2. iTunes Store/Google Play Store는 Microsoft Store보다 훨씬 오래되었습니다.
3. 마이크로소프트 스토어는 유저들 사이에서 좋은 평가를 받지 못했고 시작도 좋지 않았다.
4. 플랫폼 제한 앱 대신 웹사이트 개발을 선호하는 대부분의 회사

그리고 저는 Fb와 Instagram이 UWP가 아니라 실제로 전자 앱이라고 거의 확신합니다.

웹 사이트와 앱이 크게 다르기 때문에 전자인지 아닌지 구별하기 어렵습니다. 대화 상자가 기본 대화 상자와 거의 동일하게 보인다는 사실에 따라 UWP 앱일 수 있습니다.

그래서 폴더에서 비디오 파일을 미리 볼 수 있는 Windows 탐색기와 유사한 것을 구축하고 있습니까?

그것은 내 앱의 마법사의 일부입니다.

따라서 앱은 일반적으로 모든 파일에 액세스할 수 있어야 하지만 다른 한편으로 일부 파일과 폴더는 사용자에 의해 잠깁니다(그는 "기밀" 파일만 갖고 나머지는 자동으로 기밀이 아님). 일부 폴더는 앱 테마 자체에 의해 차단되었습니까? 그리고 프로그램에 의해 생성된 파일을 처리할 앱을 프로그래밍하려면 어떻게 해야 합니까?

내 생각은 지금 우리가 가지고 있는 것과 반대였습니다. 나는 그것이 완벽하다고 말하는 것이 아닙니다. 그러나 지금 일어나고 있는 것보다 더 나은 것이 있습니다. 따라서 기본적으로 모든 비기밀 파일에 액세스할 수 있습니다. 기밀 파일에 액세스해야 하는 경우 먼저 요청해야 합니다.

그렇다면 정확히 무엇을 기밀로 선택하지 않을 것입니까? 모든 앱에서 내 휴가 사진을 볼 수는 없지만 Photoshop에서는 사진을 볼 수 있어야 합니다. 그래서 그들은 기밀입니까? 아니면 이 기밀 "플래그" 목록이 일부 앱에 대해 기밀이 아닌 프로그램 및 일부 파일입니까?

내가 보기에 이 "플래그"는 파일이나 폴더를 "액세스 거부됨"으로 바꿉니다. 정말로 액세스하고 싶다면 권한을 요청할 수 있고 사용자는 제공할지 여부를 선택할 수 있습니다(그리고 권한은 - 이번 한 번만 또는 영원히).

그래, 거기 내 말은 쓰레기였어. 미안합니다. 나는 잘 작동하는 "사소하지 않은" 훌륭한 앱이 분명히 존재한다는 것을 나타내고 싶었습니다.

없다고 하는게 아닙니다. WPF에 비해 만들기가 엄청나게 어렵다는 뜻입니다.
나는 단순히 존재해서는 안되는 문제를 처리하는 데 시간을 낭비하고 있다고 말하고 있습니다.

예를 들어, 때때로 예외(구체적으로 COM 예외)가 발생하고 실패 지점에서 가져오는 대신 실제로 다른 스레드에서 가져옵니다. 대부분의 경우 스택 추적조차도 잃어버린. 무슨 일이 일어 났는지 알아내는 것은 매우 고통 스럽습니다.

또 다른 문제는 전체 "정보를 비동기식으로 얻을 수 있습니다"라는 주문입니다. 이는 제가 매우 싫어합니다. 즉시 처리해야 하는 렌더링을 처리하고 있지만 비트맵 로드는 비동기식입니다. 그래서 그것을 위해 정말 복잡한 캐싱 메커니즘을 구축해야 했습니다.

그리고 컴파일 시간에 들어가지 말자. 그리고 최근에 빌드할 때 "...dll이 릴리스 모드로 빌드되었습니다"라는 메시지가 표시됩니다(디버그를 빌드 중이기 때문에 기본적으로 불가능함). 해결 방법은 모든 솔루션을 정리하고 다시 빌드하는 것입니다(1분 이상 소요).

그리고 예, 충돌합니다. VS는 10-20번 실행될 때마다 충돌합니다.

그리고 이것들은 지금 내 머리에 떠오른 문제입니다. 셀 수 없이 많습니다.

이것은 UWP의 문제가 아니라 다음과 같은 사실에 있습니다.

1. 사람들은 일반적으로 댓글을 작성하지 않는 경향이 있습니다.
2. iTunes Store/Google Play Store는 Microsoft Store보다 훨씬 오래되었습니다.
3. 마이크로소프트 스토어는 유저들 사이에서 좋은 평가를 받지 못했고 시작도 좋지 않았다.
4. 플랫폼 제한 앱 대신 웹사이트 개발을 선호하는 대부분의 회사

글쎄, 나는 애플 스토어를 비교할 수 있었다면 좋았을 텐데 - 나는 그들의 최고의 앱이 수백만 개의 리뷰를 가지고 있다고 확신한다. 사람들이 UWP/WinRT를 포기하기 때문에 MS 스토어는 절대 따라가지 않습니다. win2d가 필요하지 않았다면 적어도 20번은 포기했을 것입니다.

생각해 보세요. Windows에 UWP 앱으로 전체 화면으로 전환하도록 요청해야 합니다. 정신 이상입니다. 그리고 더 어리석게 만들기 위해 다음 실행 에만 적용됩니다.

"화면 캡처" API를 보고 있었는데 그냥 포기했습니다. 소용이 없습니다. 나는 기본적으로 현재 화면을 기반으로 앱을 시작하는 멋진 방법을 원했습니다(일종의 앱으로 전환) -> 사용자 상호 작용이 필요하기 때문에 불가능합니다(즉, 사용자가 - 예 , 전체를 망치는 스크린샷 캡처를 허용하고 싶습니다)

앱이 포그라운드에 있을 때만 작동하는 클립보드로 시작하지 않겠습니다. 그리고 더 재미있게 만들기 위해 Microsoft는 "디버그에 있을 때 항상 클립보드에 대한 액세스를 제공할 것"이라고 생각했지만 릴리스에서는 멋진 "액세스 거부" 예외가 발생합니다. 내 앱이 릴리스에서 시작되지 않는 이유를 마침내 알아내는 데 몇 시간이 걸렸는지 아십니까(디버그에서는 모든 것이 멋있었지만)

목록은 계속됩니다. 저는 책을 쓸 수 있을 것 같아요. 물론 UWP/WinRT는 이론적으로 훌륭합니다. 그런데 사용하기 시작하면 음..

웹 사이트와 앱이 크게 다르기 때문에 전자인지 아닌지 구별하기 어렵습니다. 대화 상자가 기본 대화 상자와 거의 동일하게 보인다는 사실에 따라 UWP 앱일 수 있습니다.

맞습니다. 제 요점은 사람들이 UWP 앱을 포기한다는 것입니다. 이점은 그에 따른 많은 문제보다 더 큽니다.

@jtorjo
(단순히 당신이 그것을 알고 있는지 확인하십시오.)

앱이 포그라운드에 있을 때만 작동하는 클립보드로 시작하지 않겠습니다.

UWP 앱 중 하나를 개발하는 동안 클립보드에 데이터를 배치해야 하는 동일한(또는 유사한) 문제에 도달했으며 결국 동반된 win32 완전 신뢰 프로세스(Win32의 SetClipboardData 만 호출함)를 통해 해결했습니다. UWP 앱에 대한 win32 완전 신뢰 프로세스를 수반하는 개념이 뉴스라면 여기 에서 좋은 소개를 들을 수 있을 것입니다(저자는 이전에 Microsoft에서 UWP에 대해 작업했습니다).

@Felix-Dev

UWP 앱 중 하나를 개발하는 동안 클립보드에 데이터를 배치해야 하는 동일한(또는 유사한) 문제에 도달했으며 결국 동반된 win32 완전 신뢰 프로세스(Win32의 SetClipboardData 만 호출함)를 통해 해결했습니다. UWP 앱에 대한 win32 완전 신뢰 프로세스를 수반하는 개념이 뉴스라면 여기 에서 좋은 소개를 들을 수 있을 것입니다(저자는 이전에 Microsoft에서 UWP에 대해 작업했습니다).

포인터 주셔서 감사합니다! win32 완전 신뢰 프로세스에 대해 알고 있었습니다. 나는 아마도 그 기사를 여러 번 읽었을 것입니다. :) 실제로 win32 완전 신뢰 프로세스 동반자 앱이 있는 것에 대해 여러 번 생각했습니다. 복잡성이 추가되었기 때문에 선택하지 않았습니다. 이미 MS 스토어 없이도 실제로 작동하는 설치 키트를 생성하는 데 어려움을 겪고 있습니다. 나는 이것을 방정식에도 가져오고 싶지 않았습니다.

그래서 폴더에서 비디오 파일을 미리 볼 수 있는 Windows 탐색기와 유사한 것을 구축하고 있습니까?

그것은 내 앱의 마법사의 일부입니다.

그런 종류의 추가 단계가 있는 파일 탐색기처럼 들립니다(⊙ˍ⊙)

내 생각은 지금 우리가 가지고 있는 것과 반대였습니다. 나는 그것이 완벽하다고 말하는 것이 아닙니다. 그러나 지금 일어나고 있는 것보다 더 나은 것이 있습니다. 따라서 기본적으로 모든 비기밀 파일에 액세스할 수 있습니다. 기밀 파일에 액세스해야 하는 경우 먼저 요청해야 합니다.

따라서 기본적으로 파일이 기밀인지 절대 알 수 없기 때문에 결국 앱에서 지금과 같은 문제가 발생할 수 있습니다. 모든 것을 기밀로 표시하는 사용자는 어떻습니까? 그래서 당신은 당신이 접근할 수 있는 더 많은 변형과 함께 지금과 같은 시스템을 만들었습니다.

예를 들어, 때때로 예외(구체적으로 COM 예외)가 발생하고 실패 지점에서 가져오는 대신 실제로 다른 스레드에서 가져옵니다. 대부분의 경우 스택 추적조차도 잃어버린. 무슨 일이 일어 났는지 알아내는 것은 매우 고통 스럽습니다.

그런 일이 자주 발생하면 매우 성가신 일입니다. 그러나 나에게 발생하는 거의 모든 예외(예: XCG에서)에는 StackTrace가 연결되어 있으며 때로는 유용한 예외 메시지도 있습니다. 그래서 나는 그것에 대해 정말로 아무 말도 할 수 없습니다. 왜냐하면 그것은 저에게 실제로 문제가 된 적이 없었기 때문입니다.

또 다른 문제는 전체 "정보를 비동기식으로 얻을 수 있습니다"라는 주문입니다. 이는 제가 매우 싫어합니다. 즉시 처리해야 하는 렌더링을 처리하고 있지만 비트맵 로드는 비동기식입니다. 그래서 그것을 위해 정말 복잡한 캐싱 메커니즘을 구축해야 했습니다.

때때로 async는 약간 성가시지만, 대부분의 경우 async 메서드는 async여야 하는 이유가 있습니다. 네트워크 또는 파일 작업과 같은 작업에서 UI를 차단하고 싶지 않기 때문입니다. 즉, 다음 메서드를 사용하여 비동기 메서드를 동기적으로 실행할 수 있습니다.

```c#
// MyAsyncMethod가 완료될 때까지 스레드를 차단합니다.
var myResult = MyAsyncMethod().결과;

// 메서드 실행이 완료되면 이 작업도 완료됩니다.
// ConfigureAwait로 인해 다른 컨텍스트에서 메서드가 호출될 수 있습니다.
var myResult2 = MyAsyncMethod().ConfigureAwait(거짓);
`` For ConfigureAwait` 다음 문서를 볼 수 있습니다. https://devblogs.microsoft.com/dotnet/configureawait-faq/

그리고 컴파일 시간에 들어가지 말자. 그리고 최근에 빌드할 때 "...dll이 릴리스 모드로 빌드되었습니다"라는 메시지가 표시됩니다(디버그를 빌드 중이기 때문에 기본적으로 불가능함). 해결 방법은 모든 솔루션을 정리하고 다시 빌드하는 것입니다(1분 이상 소요).

"...dll"은 릴리스 모드로 빌드되어 이상합니다. 프로젝트 파일이 일관성이 없는지 확인하시겠습니까? 컴파일 시간과 관련하여 네, 그건 약간 성가시지만 ~1분은 여전히 ​​괜찮습니다. WinUI는 약 5-10분이 걸립니다 😅

그리고 예, 충돌합니다. VS는 10-20번 실행될 때마다 충돌합니다.

예, 꽤 성가신 일이지만 이것이 실제로 UWP에 의존한다고 생각하지 않지만 일반적으로 Visual Studio에 의존합니다(여전히 32비트 프로세스인 이유가 있습니다!).

글쎄, 나는 애플 스토어를 비교할 수 있었다면 좋았을 텐데 - 나는 그들의 최고의 앱이 수백만 개의 리뷰를 가지고 있다고 확신한다. 사람들이 UWP/WinRT를 포기하기 때문에 MS 스토어는 절대 따라가지 않습니다. win2d가 필요하지 않았다면 적어도 20번은 포기했을 것입니다.

WPF와 함께 Win2D를 사용할 수 있는 것 같습니다: https://github.com/Microsoft/Win2D/issues/660

생각해 보세요. Windows에 UWP 앱으로 전체 화면으로 전환하도록 요청해야 합니다. 정신 이상입니다. 그리고 더 어리석게 만들기 위해 다음 실행에만 적용됩니다.

시작 시에도 UWP 앱을 전체 화면 모드로 가져오는 것이 가능한 것 같습니다. https://stackoverflow.com/questions/31758775/windows-10-universal-app-run-in-fullscreen-mode-by-default
(나는 그것으로 앱을 제출하려고 시도하지 않았지만)

"화면 캡처" API를 보고 있었는데 그냥 포기했습니다. 소용이 없습니다. 나는 기본적으로 현재 화면을 기반으로 앱을 시작하는 멋진 방법을 원했습니다(일종의 앱으로 전환) -> 사용자 상호 작용이 필요하기 때문에 불가능합니다(즉, 사용자가 - 예 , 전체를 망치는 스크린샷 캡처를 허용하고 싶습니다)

대부분의 사용자는 앱이 허락 없이 임의로 화면을 찍는 것을 원하지 않습니다. 당신은 그것에 대해 문제가 없을 수도 있지만, 나는 확실히 그렇게 하고 다른 많은 사람들도 마찬가지입니다.

앱이 포그라운드에 있을 때만 작동하는 클립보드로 시작하지 않겠습니다. 그리고 더 재미있게 만들기 위해 Microsoft는 "디버그에 있을 때 항상 클립보드에 대한 액세스를 제공할 것"이라고 생각했지만 릴리스에서는 멋진 "액세스 거부" 예외가 발생합니다. 내 앱이 릴리스에서 시작되지 않는 이유를 마침내 알아내는 데 몇 시간이 걸렸는지 아십니까(디버그에서는 모든 것이 멋있었지만)

예, 예외가 발생하지만 포커스가 없을 때 앱이 액세스할 수 없다는 사실은 문서에 언급되어 있습니다.

https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard

하지만 사용자가 앱을 사용하지 않을 때 클립보드에 액세스해야 하는 이유는 무엇입니까? 사용자가 앱을 사용하지 않을 때 클립보드를 설정하려고 하면 복사/붙여넣기를 방해하면 사용자가 짜증을 냅니다. 그리고 사용자가 앱에 작업을 요청하지 않을 때 클립보드를 읽는다면 사용자를 감시하는 것입니다. 그것이 당신의 목표가 아니라면(이 경우 확실히 UWP를 사용해서는 안 됨), 앱에 포커스가 없을 때 클립보드를 읽어야 할 이유는 거의 없습니다(있을 경우).

맞습니다. 제 요점은 사람들이 UWP 앱을 포기한다는 것입니다. 이점은 그에 따른 많은 문제보다 더 큽니다.

어쩌면 모든 플랫폼에 대해 별도의 앱을 작성하는 대신 웹사이트를 작성하고 Electron 내부에 패키징하여 Mac, Linux 및 Windows로 배송하는 것이 더 쉽다는 사실 때문이기도 합니다.

그런 종류의 추가 단계가 있는 파일 탐색기처럼 들립니다(⊙ˍ⊙)

그렇지 않다. 그것과는 거리가 멀다.

따라서 기본적으로 파일이 기밀인지 절대 알 수 없기 때문에 결국 앱에서 지금과 같은 문제가 발생할 수 있습니다. 모든 것을 기밀로 표시하는 사용자는 어떻습니까? 그래서 당신은 당신이 접근할 수 있는 더 많은 변형과 함께 지금과 같은 시스템을 만들었습니다.

내 솔루션이 옳다고 말하는 것이 아닙니다. 분명히 나는 ​​샌드박스에 있지 않는 것을 선호합니다. 단지 현재 구현이 매우 나쁩니다.

때때로 async는 약간 성가시지만, 대부분의 경우 async 메서드는 async여야 하는 이유가 있습니다. 네트워크 또는 파일 작업과 같은 작업에서 UI를 차단하고 싶지 않기 때문입니다. 즉, 다음 메서드를 사용하여 비동기 메서드를 동기적으로 실행할 수 있습니다.

이것은 잘못된 것입니다. 이것은 단순히 내가 항상 UI 스레드에서 호출한다고 가정합니다. 간단한 작업에는 괜찮지만 나만의 스레드를 만들 수 있고 나만의 작업을 만들고 작업을 수행할 수도 있습니다.

모든 것을 비동기화하면 항상 await를 호출하고 함수를 async로 표시해야 합니다.

[...] ConfigureAwait 경우 다음 문서를 볼 수 있습니다. https://devblogs.microsoft.com/dotnet/configureawait-faq/

고마워, 나는 이것에 대해 알고있다. 내가 만난 또 다른 문제는 제안한 대로 비트맵(비동기)을 로드하는 것이었습니다. 때때로 비트맵을 로드하는 데 5-6초와 같은 미친 대기 시간이 발생했습니다.
나는 해결 방법을 끝내었다.

"...dll"은 릴리스 모드로 빌드되어 이상합니다. 프로젝트 파일이 일관성이 없는지 확인하시겠습니까? 컴파일 시간과 관련하여 네, 그건 약간 성가시지만 ~1분은 여전히 ​​괜찮습니다. WinUI는 약 5-10분이 걸립니다 😅

예, 그것에 대해 생각하고 싶지도 않습니다. :) 프로젝트 파일이 일관성이 없다는 것이 무슨 말인지 잘 모르겠습니다.

그리고 예, 충돌합니다. VS는 10-20번 실행될 때마다 충돌합니다.

예, 꽤 성가신 일이지만 이것이 실제로 UWP에 의존한다고 생각하지 않지만 일반적으로 Visual Studio에 의존합니다(여전히 32비트 프로세스인 이유가 있습니다!).

나는 그것이 UWP와 관련이 있다고 믿습니다. 이것은 WPF를 다룰 때 나에게 일어난 적이 없습니다. 나는 28개의 프로젝트를 가지고 있었고 결코 충돌하지 않았습니다. UWP에는 15개의 프로젝트(WPF에서 포팅)가 있는데 충돌합니다. 그리고 이벤트 뷰어를 보면 샌드박스 충돌에 대해 뭔가가 있습니다. 정확히 기억은 나지 않습니다.

WPF와 함께 Win2D를 사용할 수 있는 것 같습니다: microsoft/Win2D#660

그것이 나의 첫 번째 시도였습니다. 절대 금물입니다. 너무 많은 문제에 부딪혀 결국 포기했습니다. win2d를 다루는 코드는 상당히 복잡하기 때문에 UWP를 직접 사용하는 것보다 WPF 위에 작성하는 것이 훨씬 더 오래 걸릴 것이라고 생각했습니다.

UWP 설정 자체가 싫은 만큼 내 말이 맞았다. 제대로 작동하게 만들지 못했을 것입니다. 그리고 나는 당신이 https://github.com/microsoft/Win2D/issues/731을 알고 있다고 가정합니다.

생각해 보세요. Windows에 UWP 앱으로 전체 화면으로 전환하도록 요청해야 합니다. 정신 이상입니다. 그리고 더 어리석게 만들기 위해 다음 실행에만 적용됩니다.

시작 시에도 UWP 앱을 전체 화면 모드로 가져오는 것이 가능한 것 같습니다. https://stackoverflow.com/questions/31758775/windows-10-universal-app-run-in-fullscreen-mode-by-default

죄송합니다. "최대화하려는" 의도였습니다. 죄송합니다.

예, 예외가 발생하지만 포커스가 없을 때 앱이 액세스할 수 없다는 사실은 문서에 언급되어 있습니다.

문제는 디버그에서 릴리스와 다른 동작이 있다는 것입니다. 일관성이 있어야 합니다.

https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard

하지만 사용자가 앱을 사용하지 않을 때 클립보드에 액세스해야 하는 이유는 무엇입니까? [...]

재미있는 점은 이것입니다. 시작할 때 클립보드에 무언가를 복사하고 싶었습니다. 그러나 이것은 MainPage의 생성자에 있었기 때문에 분명히 나는 ​​아직 전경에 있지 않았습니다. 디버그에서 복숭아처럼 작업하고 릴리스에서 충돌했습니다. 즉, 정확히 시작 시, 아무 기록도 남기지 않았습니다.

맞습니다. 제 요점은 사람들이 UWP 앱을 포기한다는 것입니다. 이점은 그에 따른 많은 문제보다 더 큽니다.

어쩌면 모든 플랫폼에 대해 별도의 앱을 작성하는 대신 웹사이트를 작성하고 Electron 내부에 패키징하여 Mac, Linux 및 Windows로 배송하는 것이 더 쉽다는 사실 때문이기도 합니다.

플랫폼 독립성과 관련하여 그것은 완전히 새로운 주제입니다. 제가 언급한 것은 UWP 앱을 개발할 때 사람들이 직면하는 많은 문제가 단순히 존재해서는 안 된다는 사실입니다. WPF에서 UWP로 전환하는 것은 매우 나쁜 경험이었습니다.

@chingucoding

하지만 사용자가 앱을 사용하지 않을 때 클립보드에 액세스해야 하는 이유는 무엇입니까? 사용자가 앱을 사용하지 않을 때 클립보드를 설정하려고 하면 복사/붙여넣기를 방해하면 사용자가 짜증을 냅니다. 그리고 사용자가 앱에 작업을 요청하지 않을 때 클립보드를 읽는다면 사용자를 감시하는 것입니다. 그것이 당신의 목표가 아니라면(이 경우 확실히 UWP를 사용해서는 안 됨), 앱에 포커스가 없을 때 클립보드를 읽어야 할 이유는 거의 없습니다(있을 경우).

제 경우에는 앱이 감시하는 이벤트가 발생하면 앱에 알림이 표시됩니다. 알림 메시지에는 사용자가 추가 처리/다른 컨텍스트에서 사용하려는 정보가 포함될 수 있으므로 표시된 정보 중 일부를 복사하는 [클립보드에 복사] 작업 버튼을 제공합니다. 알림이 언제든지 도착할 수 있고 그 시점에서 앱이 백그라운드에 있을 수 있으므로 이 경우 Win32 도우미 프로세스를 사용해야 합니다.

UWP 샌드박스 외부에서 Win32를 사용하는 것은 개발자가 사용자에게 알리지 않고 무언가를 달성하기를 원하기 때문에 항상 그런 것은 아닙니다. 따라서 일반적으로 말해서 샌드박스는 사용자에게 가치를 제공하지만 사용자를 염탐하는 데 신경 쓰지 않거나 요청할 의도가 없는 악의적인 개발자가 아니더라도 어떤 경우에도 개발자로서 여전히 샌드박스를 처리해야 합니다. 시스템에서 무언가를 변경하기 전에 사용자의 동의.

앱과 함께 Win32 완전 신뢰 프로세스를 사용할 수 있다는 사실은 MS가 이러한 딜레마를 인식하고 있으며 개발자에게 UWP를 사용할 수 있는 도구를 제공하면서도 여전히 Win32의 자유를 충분히 누릴 수 있음을 나타냅니다.

그렇지 않다. 그것과는 거리가 멀다.

지금 앱을 다운로드할 수 있습니까? 그렇다면 어디에서 찾을 수 있습니까? 😂

분명히 나는 ​​샌드박스에 있지 않는 것을 선호합니다. 단지 현재 구현이 매우 나쁩니다.

샌드박스가 마음에 들지 않으면 WPF 대안으로 전환하는 것이 더 나은 선택일 수 있습니다. UWP에서 앱을 개발하려고 하는 것보다 더 나은 선택일 수 있습니다. 를 위한 앱을 개발합니다. 나는 WPF 대안이 Win2D에 비해 그렇게 나쁘다고 생각하지 않습니다. 그것이 당신이 모든 어려움을 겪는 것을 정당화할 것입니다. 그러나 그것은 그것에 대한 나의 관점일 뿐입니다.

또한 현재 구현은 파일에 대한 제한이 없는 데 익숙한 사람들에게 "나쁨"입니다. 웹 개발 배경에서 온 저는 그 점에 매우 만족합니다. 특히 웹에는 사용자 보호를 목적으로 하는 제한이 있기 때문에 그들의 위치를 ​​알 수 있습니다.

프로젝트 파일이 일관성이 없다는 것이 무엇을 의미하는지 잘 모르겠습니다.

디버그용 프로젝트 파일이 잘못되었고 릴리스에서 일부 dll이 생성되고 있을 수 있습니다. 하지만 Visual Studio에서 이를 처리하도록 하면 그런 일이 일어날지 모르겠습니다.

나는 그것이 UWP와 관련이 있다고 믿습니다. 이것은 WPF를 다룰 때 나에게 일어난 적이 없습니다. 나는 28개의 프로젝트를 가지고 있었고 결코 충돌하지 않았습니다. UWP에는 15개의 프로젝트(WPF에서 포팅)가 있는데 충돌합니다. 그리고 이벤트 뷰어를 보면 샌드박스 충돌에 대해 뭔가가 있습니다. 정확히 기억은 나지 않습니다.

Visual Studio의 안정성은 저에게 있어 프로젝트 크기에 크게 좌우됩니다. 중소형 UWP/NetCore/NetFramework는 항상 잘 작동합니다. 대규모 프로젝트로 인해 Visual Studio가 응답하지 않거나 중단되거나 한 번에 충돌합니다. 하지만 그건 제 경험일 뿐입니다.

죄송합니다. "최대화하려는" 의도였습니다. 죄송합니다.

이 경우 앱이 시작된 후에 값을 설정했기 때문에 다음 시작 시에만 변경 사항이 적용됩니다. "Windows에 물어봐야합니다"라는 말이 무슨 말인지 모르겠습니다. 코드로 설정해야 한다는 사실을 말씀하시는 건가요?

또한 선호하는 크기를 설정하는 방법이 있습니다. 그러면 실제 최대화만큼 좋지는 않지만 앱이 화면의 모든 공간을 차지하게 됩니다(최대화와 유사).
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

이것은 잘못된 것입니다. 이것은 단순히 내가 항상 UI 스레드에서 호출한다고 가정합니다. 간단한 작업에는 괜찮지만 나만의 스레드를 만들 수 있고 나만의 작업을 만들고 작업을 수행할 수도 있습니다.

이미 자신의 스레드를 사용하고 있다면 await를 사용하는 것이 문제가 되지 않습니다. 별도의 쓰레드를 사용해도 이벤트 핸들러는 항상 UI 쓰레드에서 실행되기 때문에 거기에서 방대한 연산을 하면 앱이 응답하지 않게 된다.

UWP 설정 자체가 싫은 만큼 내 말이 맞았다. 제대로 작동하게 만들지 못했을 것입니다. 그리고 나는 당신이 microsoft/Win2D#731을 알고 있다고 가정합니다.

저도 몰랐는데 2018년부터 말씀드린 문제이니 지금쯤은 잘 해결되리라 생각했습니다.

문제는 디버그에서 릴리스와 다른 동작이 있다는 것입니다. 일관성이 있어야 합니다.

흠 아주 이상합니다. 행동은 일관성이 있어야 합니다.

재미있는 점은 이것입니다. 시작할 때 클립보드에 무언가를 복사하고 싶었습니다.

또한 설명서에서 해당 사용 사례를 언급하며 CoreWindow.Activated가 복사될 때까지 기다려야 합니다. 사용자가 방금 앱을 시작했을 때 클립보드에 정확히 복사한 이유는 무엇입니까? @Felix-Dev가 달성/달성하고자 하는 것과 유사한 것입니까?

@Felix-Dev 답변해주셔서 감사합니다. 나는 그 시나리오에 대해 생각하지 않았다. 이 경우 클립보드에 액세스해야 하며 이는 사용자의 경험을 확실히 향상시킵니다. 내 추측으로는 당신이 "초점을 가지고" 건배한 이후로 이것이 효과가 있었을 것이라고 생각했을 것입니다. 하지만 그렇지 않은 것 같아요.

따라서 일반적으로 말해서 샌드박스는 사용자에게 가치를 제공하지만 사용자를 염탐하는 데 신경 쓰지 않거나 요청할 의도가 없는 악의적인 개발자가 아니더라도 어떤 경우에도 개발자로서 여전히 샌드박스를 처리해야 합니다. 시스템에서 무언가를 변경하기 전에 사용자의 동의.

예, 우리는 그것을 처리해야 하지만 많은 앱이 해결 방법을 찾기가 매우 어려울 정도로 샌드박스에 의해 제한되지 않습니다. 잊지 말아야 할 한 가지는 UWP가 작동하지 않는 경우에도 여전히 2가지 다른 옵션이 있다는 것입니다.

마지막 요점과 관련하여 예, Win32 프로세스를 사용할 수 있다는 사실은 UWP가 사용자를 제한하는 경우가 있음을 나타냅니다.
이것은 가장 쉽고 빠른 해결 방법이거나 실제로 의도적으로 설계된 것일 수 있습니다.

그렇지 않다. 그것과는 거리가 멀다.

지금 앱을 다운로드할 수 있습니까? 그렇다면 어디에서 찾을 수 있습니까? 😂

여기 -> https://hot-awe.com

샌드박스가 마음에 들지 않으면 WPF 대안으로 전환하는 것이 더 나은 선택일 수 있습니다. UWP에서 앱을 개발하려고 하는 것보다 더 나은 선택일 수 있습니다. 를 위한 앱을 개발합니다. 나는 WPF 대안이 Win2D에 비해 그렇게 나쁘다고 생각하지 않습니다. 그것이 당신이 모든 어려움을 겪는 것을 정당화할 것입니다. 그러나 그것은 그것에 대한 나의 관점일 뿐입니다.

이것은 WPF 응용 프로그램이었습니다. 그러나 비디오 편집의 특성으로 인해 속도면에서 WPF의 한계에 도달한 지 오래입니다(기본적으로 DrawingVisual ). 저를 믿으세요. 선택의 여지가 있었다면 이렇게 하지 않았을 것입니다.

또한 현재 구현은 파일에 대한 제한이 없는 데 익숙한 사람들에게 "나쁨"입니다. 웹 개발 배경에서 온 저는 그 점에 매우 만족합니다. 특히 웹에는 사용자 보호를 목적으로 하는 제한이 있기 때문에 그들의 위치를 ​​알 수 있습니다.

나는 당신이 웹 배경에서 왔다고 맹세할 수 있었습니다 :)

디버그용 프로젝트 파일이 잘못되었고 릴리스에서 일부 dll이 생성되고 있을 수 있습니다. 하지만 Visual Studio에서 이를 처리하도록 하면 그런 일이 일어날지 모르겠습니다.

그것은 사실이 아니지만 나는 다시 한 번 확인했습니다 - 그렇지 않습니다.

Visual Studio의 안정성은 저에게 있어 프로젝트 크기에 크게 좌우됩니다. 중소형 UWP/NetCore/NetFramework는 항상 잘 작동합니다. 대규모 프로젝트로 인해 Visual Studio가 응답하지 않거나 중단되거나 한 번에 충돌합니다. 하지만 그건 제 경험일 뿐입니다.

예, 나는 과거에 그것을 처리했습니다. 최신 버전의 VS(2017,2019)에서는 그렇지 않은 것 같습니다. 어쨌든, 간단히 말해서 이것은 UWP에서 저에게 일어난 일입니다. 그것은 내가 win2d를 사용하고 있다는 사실과 관련이있을 수 있으며, 나는 상당히 복잡한 짐승이라는 느낌을 가지고 있습니다.

이 경우 앱이 시작된 후에 값을 설정했기 때문에 다음 시작 시에만 변경 사항이 적용됩니다. "Windows에 물어봐야합니다"라는 말이 무슨 말인지 모르겠습니다. 코드로 설정해야 한다는 사실을 말씀하시는 건가요?

WPF에서는 창 크기를 원하는 위치로 설정하기만 하면 됩니다. 여기에 호출해야 하는 API가 있습니다 -> ApplicationView.PreferredLaunchViewSize - 문서에 따르면 "시스템이 창 크기를 직접 관리하는 경우를 제외하고는 작동합니다." - 예, 다음 앱 시작에만 작동합니다.

또한 선호하는 크기를 설정하는 방법이 있습니다. 그러면 실제 최대화만큼 좋지는 않지만 앱이 화면의 모든 공간을 차지하게 됩니다(최대화와 유사).
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

실제로 올바르게 작동하는 다른 코드를 사용하고 있습니다.

var view = DisplayInformation.GetForCurrentView();
var resolution = new Size(view.ScreenWidthInRawPixels, view.ScreenHeightInRawPixels);
var scale = view.ResolutionScale == ResolutionScale.Invalid ? 1 : view.RawPixelsPerViewPixel;
var bounds = new Size(resolution.Width / scale, resolution.Height / scale);

ApplicationView.PreferredLaunchViewSize = new Size(bounds.Width, bounds.Height);
ApplicationView.PreferredLaunchWindowingMode = ApplicationViewWindowingMode.PreferredLaunchViewSize;

이미 자신의 스레드를 사용하고 있다면 await를 사용하는 것이 문제가 되지 않습니다. 별도의 쓰레드를 사용해도 이벤트 핸들러는 항상 UI 쓰레드에서 실행되기 때문에 거기에서 방대한 연산을 하면 앱이 응답하지 않게 된다.

분명히 이벤트 핸들러는 UI 스레드에서 실행됩니다. 좀 익숙해졌습니다. 앱을 상당히 수정해야 했습니다. 함수에 async를 추가하기만 하면 됩니다. 여전히 나를 괴롭히는 것은 꽤 많은 API가 이 작업을 수행한 것 같다는 것입니다. 극단적으로 Async() 버전만 있는 경우에는 의미가 없습니다.

저도 몰랐는데 2018년부터 말씀드린 문제이니 지금쯤은 잘 해결되리라 생각했습니다.

그것은 없었습니다 - 적어도 내가 마지막으로 확인했을 때.

문제는 디버그에서 릴리스와 다른 동작이 있다는 것입니다. 일관성이 있어야 합니다.

흠 아주 이상합니다. 행동은 일관성이 있어야 합니다.

네, 그게 저를 정말 화나게 한 것입니다. 그리고 분명히, UWP가 아닌 앱에서 미친 듯이 오랜 시간 동안 클립보드로 작업할 때 이러한 제한이 있을 것이라고 생각하지 않았으므로 예, CoreWindow.Activated를 기다려야 한다는 내용은 읽지 않았습니다. 그렇긴 하지만, 이 모든 세부 사항을 배워야 하는 것은 엄청나게 번거롭습니다. 완전히 새로운 언어를 배워야 하는 것과 같습니다. 매끄럽게 진행되는 대신 매주 마음을 아프게 하는 무언가를 배우는 것 같습니다.

또한 설명서에서 해당 사용 사례를 언급하며 CoreWindow.Activated가 복사될 때까지 기다려야 합니다. 사용자가 방금 앱을 시작했을 때 클립보드에 정확히 복사한 이유는 무엇입니까? @Felix-Dev가 달성/달성하고자 하는 것과 유사한 것입니까?

이것은 내가 초기에 내 앱을 테스트했을 때였으며 더 많은 내부 테스트를 위해 동료에게 제공하고 싶었습니다. 그러나 그는 몇 가지 설정을 조정해야 합니다. 그리고 설정은 응용 프로그램의 LocalFolder에 유지되었습니다. 이것은 모든 사용자마다 다르기 때문에 제 생각은 -- 간단하게 유지하고 클립보드에 복사하겠습니다. 그런 다음 앱을 시작하면 "이 PC"로 이동하여 위치를 붙여넣고 거기에서 설정 파일을 편집합니다(지금은 탐색기에서 앱을 열 수 있었던 방법을 알고 있지만 당시에는 않았다). 결국 충돌이 발생했고 저는 몇 시간 동안 조사하고 저주했습니다.

여기 -> https://hot-awe.com

감사 해요!

이것은 WPF 응용 프로그램이었습니다. 그러나 비디오 편집의 특성으로 인해 나는 속도 면에서(기본적으로 DrawingVisual 다루기) WPF의 한계에 오랫동안 부딪쳤습니다. 저를 믿으세요. 선택의 여지가 있었다면 이렇게 하지 않았을 것입니다.

WPF가 UWP에 비해 그렇게 큰 성능 저하가 있다는 것을 몰랐습니다.

그것은 사실이 아니지만 나는 다시 한 번 확인했습니다 - 그렇지 않습니다.

이상 하네. 뭔가 문제가 있을 거라고 예상했을 것입니다. 디버그를 실행할 때 VS가 릴리스 dll에 대해 이야기하는 이유는 무엇입니까?

WPF에서는 창 크기를 원하는 위치로 설정하기만 하면 됩니다. 여기에 호출해야 하는 API가 있습니다. ApplicationView.PreferredLaunchViewSize - 문서에 따르면 "시스템이 창 크기를 직접 관리하는 경우를 제외하고는 작동합니다."

하지만 사용하고 있는 코드도 창 크기를 설정하는 API가 아닌가요?

• 예, 다음 앱 시작에만 작동합니다.

"PreferredLaunchViewSize"라고 하면 놀랍지 않습니다 😅
다만 런칭 후에는 설정할 수 있는 방법이 없는 것이 조금 불편합니다.

예, 나는 과거에 그것을 처리했습니다. 최신 버전의 VS(2017,2019)에서는 그렇지 않은 것 같습니다. 어쨌든, 간단히 말해서 이것은 UWP에서 저에게 일어난 일입니다.

VS의 이전 버전만큼 나쁘지 않다는 소식을 들으니 기쁩니다.

그것은 내가 win2d를 사용하고 있다는 사실과 관련이있을 수 있으며, 나는 상당히 복잡한 짐승이라는 느낌을 가지고 있습니다.

템플릿 바인딩에 실패하기 시작하기 때문에 디자이너에게 많이 의존하지 않습니다. Visual Studio용 Blend를 사용해 보셨습니까? 디자이너에 대해 더 신뢰할 수 있습니까?

네, 그게 저를 정말 화나게 한 것입니다. 그리고 분명히, UWP가 아닌 앱에서 미친 듯이 오랜 시간 동안 클립보드로 작업할 때 이러한 제한이 있을 것이라고 생각하지 않았으므로 예, CoreWindow.Activated를 기다려야 한다는 내용은 읽지 않았습니다. 그렇긴 하지만, 이 모든 세부 사항을 배워야 하는 것은 엄청나게 번거롭습니다. 완전히 새로운 언어를 배워야 하는 것과 같습니다. 매끄럽게 진행되는 대신 매주 마음을 아프게 하는 무언가를 배우는 것 같습니다.

네, 상상할 수 있습니다. 좋은 점은 WPF에서 UWP로의 전환 가이드입니다. 이것이 존재한다면 새로운 UWP와 이전 WPF 개발자의 시간을 확실히 절약할 수 있습니다. 전환 가이드가 있는 것은 이번이 처음이 아닙니다. Java to C# 가이드가 이미 있으므로 Java 개발자에게 많은 도움이 됩니다.

이것은 내가 초기에 내 앱을 테스트했을 때였으며 더 많은 내부 테스트를 위해 동료에게 제공하고 싶었습니다. 그러나 그는 몇 가지 설정을 조정해야 합니다. 그리고 설정은 응용 프로그램의 LocalFolder에 유지되었습니다. 이것은 모든 사용자마다 다르기 때문에 제 생각은 -- 간단하게 유지하고 클립보드에 복사하겠습니다. 그런 다음 앱을 시작하면 "이 PC"로 이동하여 위치를 붙여넣고 거기에서 설정 파일을 편집합니다(지금은 탐색기에서 앱을 열 수 있었던 방법을 알고 있지만 당시에는 않았다). 결국 충돌이 발생했고 저는 몇 시간 동안 조사하고 저주했습니다.

알 겠어요. 폴더를 열 생각이 없다면 폴더 경로를 클립보드에 복사하는 것이 해결책입니다. 테스트 목적으로 이것은 매우 똑똑합니다.

WPF가 UWP에 비해 그렇게 큰 성능 저하가 있다는 것을 몰랐습니다.

WPF는 DirectX에 최적화되지 않았습니다. 픽셀 셰이더와 마스크가 작동하면 매우 느려집니다. UWP/win2d로 이식하면 앱이 3~4배 빨라졌습니다. 엄청나게 눈에 띕니다.

이상 하네. 뭔가 문제가 있을 거라고 예상했을 것입니다. 디버그를 실행할 때 VS가 릴리스 dll에 대해 이야기하는 이유는 무엇입니까?

네, 정확히 제 요점입니다.

하지만 사용하고 있는 코드도 창 크기를 설정하는 API가 아닌가요?

내 말은, 당신은 Preferred...Size를 사용하지만 그것이 일어날 것이라는 보장은 없습니다. WPF를 사용할 때와 마찬가지로 위치/크기를 설정할 때 실제로 발생합니다.

"PreferredLaunchViewSize"라고 하면 놀랍지 않습니다 😅
다만 런칭 후에는 설정할 수 있는 방법이 없는 것이 조금 불편합니다.

이것은 불편함을 넘어선 것입니다. 그것은 엄청나게 불편합니다. 기본적으로 앱이 시작된 후에는 크기를 조정할 수 없습니다. 그리고 예, 내 앱이 다른 "모드" 작동(예: 기본/고급)을 가지기를 바랍니다. 사용자가 "변경 사항은 다시 시작한 후에만 발생합니다"에 대해 괜찮을 것이라고 생각합니까?

템플릿 바인딩에 실패하기 시작하기 때문에 디자이너에게 많이 의존하지 않습니다. Visual Studio용 Blend를 사용해 보셨습니까? 디자이너에 대해 더 신뢰할 수 있습니까?

더 구체적이어야 했습니다. xaml을 편집할 때 VS가 충돌하지 않습니다. 앱을 시작할 때 충돌이 발생합니다. 기본적으로 배포 시 정확히 발생한다고 가정합니다. (uwp) 앱에서 10초 동안 큰 "x"가 표시되고 그 시점에서 중단된다는 것을 알고 있기 때문입니다. 이 시점에서 45-60초 더 기다리면 VS가 충돌하는 것을 확인하거나 작업 관리자에서 VS를 닫을 수 있습니다.

네, 상상할 수 있습니다. 좋은 점은 WPF에서 UWP로의 전환 가이드입니다.

예, 매우 도움이 될 것입니다.

알 겠어요. 폴더를 열 생각이 없다면 폴더 경로를 클립보드에 복사하는 것이 해결책입니다. 테스트 목적으로 이것은 매우 똑똑합니다.

감사합니다 ;) 실제로 작동했다면 똑똑했을 것입니다 :)

@chingucoding

때때로 async는 약간 성가시지만, 대부분의 경우 async 메서드는 async여야 하는 이유가 있습니다. 네트워크 또는 파일 작업과 같은 작업에서 UI를 차단하고 싶지 않기 때문입니다. 즉, 다음 메서드를 사용하여 비동기 메서드를 동기적으로 실행할 수 있습니다.

내가 비동기를 싫어하는 이유를 한 가지 더 말씀드리겠습니다. 이것은 지금 나에게 일어난 일입니다(기본적으로 사용자의 버그 보고서입니다). 처음에는 평생 알 수가 없었습니다.

간단히 말해서 버튼을 클릭하면 파일 선택기가 열립니다. 짐작하시겠지만 비동기입니다.

따라서 사용자는 두 번 클릭했습니다(클릭 사이에 약 100ms 일시 중지). 확실히, 이것은 2개의 파일 선택기를 열었습니다.

이제 분명히 이 문제를 해결할 수 있지만 초기 기능이 동기식이었다면 이런 일은 절대 일어나지 않을 것입니다(물론 WPF에서는 절대 일어나지 않을 것입니다).

이것은 불편함을 넘어선 것입니다. 그것은 엄청나게 불편합니다. 기본적으로 앱이 시작된 후에는 크기를 조정할 수 없습니다. 그리고 예, 내 앱이 다른 "모드" 작동(예: 기본/고급)을 가지기를 바랍니다. 사용자가 "변경 사항은 다시 시작한 후에만 발생합니다"에 대해 괜찮을 것이라고 생각합니까?

특정 크기를 적용해야 하는 앱의 경우 "매우 불편"할 수 있지만 대부분의 경우 앱은 자체 크기를 조정할 필요가 없습니다. 앱은 현재 사용자 사용 사례에 적합한 크기를 어떻게 선택해야 합니까? 사용자가 더 작게 또는 더 크게 만들 필요가 있는 경우 사용자가 먼저 알아차립니다. 특히 그는 다른 열린 창문이 어디에 있고 다른 창문이 보이지 않도록 차단할 수 있는 공간이 어디에 있는지 가장 잘 알고 있기 때문입니다.

기본 및 고급 모드가 있는 경우 앱이 작을 때 확실히 작동하지 않으면 최소 기본 크기를 변경할 수 있습니다. 그러나 제 생각에는 프로그램이 스스로 크기를 조정하기 시작한다면 매우 짜증날 것입니다.

할 수 없어 사용자가 "변경 사항은 다시 시작한 후에만 발생합니다"에 대해 괜찮을 것이라고 생각합니까?

크기 조정이 그렇게 중요하다면 사용자가 직접 할 수 있습니다. 그러나 이 "변경 사항은 다시 시작한 후에만 발생합니다"는 드문 일이 아니므로 제 생각에는 부분적으로 허용됩니다.

따라서 사용자는 두 번 클릭했습니다(클릭 사이에 약 100ms 일시 중지). 확실히, 이것은 2개의 파일 선택기를 열었습니다.

정확히 파일 선택기를 두 번 연 이유는 무엇입니까? 이벤트 핸들러가 두 번 트리거되었습니까? 이는 비동기로 인한 문제가 아니라 이벤트 핸들러가 UI가 해당 버튼에서 추가 이벤트를 수신하는 것을 차단하지 않았기 때문입니다.

간단히 말해서 버튼을 클릭하면 파일 선택기가 열립니다. 짐작하시겠지만 비동기입니다.

예, 사용자가 드라이브를 탐색하고 폴더를 선택하는 동안 전체 스레드를 차단하고 싶지 않기 때문에 비동기입니다. 사용자가 파일/폴더 선택을 마치면 호출이 완료되고 결과로 선택한 파일이 표시됩니다.

제 생각에는 실제로 얼마나 걸릴지 알 수 없기 때문에 이러한 작업에서 스레드를 차단하지 않는 것이 좋습니다. 그 때문에 UI 스레드를 차단하면 파일 선택기가 열려 있는 동안 앱이 응답하지 않게 되며 IMO는 좋은 UX가 아닙니다.

정중하게 말하면서 시작하겠습니다. 우리는 어떤 것에도 동의하지 않을 것 입니다.

분명히 당신은 웹 관점에서 생각하고 있으며 단순히 "데스크톱"으로 아무것도 보지 않습니다. 나는 당신이 의미하는 바가 좋다는 것을 알고 있지만 데스크톱에 관해서는 복잡한 것을 개발할 때까지 "데스크톱"을 생각하지 않습니다. 그리고 나는 당신이하지 않았다 믿습니다.

특정 크기를 적용해야 하는 앱의 경우 "매우 불편"할 수 있지만 대부분의 경우 앱은 자체 크기를 조정할 필요가 없습니다. 앱은 현재 사용자 사용 사례에 적합한 크기를 어떻게 선택해야 합니까? 사용자가 더 작게 또는 더 크게 만들 필요가 있는 경우 사용자보다

이거 진지하게 묻는거야? 응용 프로그램은 사용자를 도와야 하는 것 아닙니까? 그런 다음 사용자가 앱의 크기에 만족하지 않으면 크기를 조정할 수 있습니다. 그러나 앱은 수행해야 하는 작업에 따라 이것이 내가 실행해야 하는 크기라고 말할 수 있어야 합니다. Photoshop은 사용자에게 표시할 정보가 많기 때문에 항상 전체 화면을 실행하는 것을 선호합니다.

기본 및 고급 모드가 있는 경우 앱이 작을 때 확실히 작동하지 않으면 최소 기본 크기를 변경할 수 있습니다. 그러나 제 생각에는 프로그램이 스스로 크기를 조정하기 시작한다면 매우 짜증날 것입니다.

그들이 그랬다면 당신은 그것에 대해 생각조차하지 않았습니다. 마법사는 때때로 더 작은 크기로 실행되고 마법사가 완료되면 앱이 전체 화면으로 전환될 수 있습니다.

할 수 없어 사용자가 "변경 사항은 다시 시작한 후에만 발생합니다"에 대해 괜찮을 것이라고 생각합니까?

크기 조정이 그렇게 중요하다면 사용자가 직접 할 수 있습니다. 그러나 이 "변경 사항은 다시 시작한 후에만 발생합니다"는 드문 일이 아니므로 제 생각에는 부분적으로 허용됩니다.

특정 크기만 좋아 보이는 창을 표시하기 때문에 시작 경험이 좋지 않습니다. Windows에서는 "오, 하지만 원하는 대로 앱을 표시하겠습니다"라고만 말합니다.

정확히 파일 선택기를 두 번 연 이유는 무엇입니까? 이벤트 핸들러가 두 번 트리거되었습니까? 이는 비동기로 인한 문제가 아니라 이벤트 핸들러가 UI가 해당 버튼에서 추가 이벤트를 수신하는 것을 차단하지 않았기 때문입니다.

솔직히 이러는거야? 의식적으로 수행한 코드가 어떻게 잘렸는지 보여주세요.

제 생각에는 실제로 얼마나 걸릴지 알 수 없기 때문에 이러한 작업에서 스레드를 차단하지 않는 것이 좋습니다. 그 때문에 UI 스레드를 차단하면 파일 선택기가 열려 있는 동안 앱이 응답하지 않게 되며 IMO는 좋은 UX가 아닙니다.

WPF는 이것을 어떻게 처리합니까? 올바르게 처리합니다. UI는 차단되지 않지만 앱은 해당 호출에서 차단됩니다. 따라서 위의 내용은 WPF에서 발생하지 않습니다.

정중하게 말하면서 시작하겠습니다. 우리는 어떤 것에도 동의하지 않을 것입니다.

이것이 이 토론에 대한 귀하의 견해라면 그것에 대해 유감스럽게 생각합니다.

분명히 당신은 웹 관점에서 생각하고 있으며 단순히 "데스크톱"으로 아무것도 보지 않습니다. 나는 당신이 의미하는 바가 좋다는 것을 알고 있지만 데스크톱에 관해서는 복잡한 것을 개발할 때까지 "데스크톱"을 생각하지 않습니다. 그리고 나는 당신이하지 않았다 믿습니다.

더 정확한 설명은 다음과 같습니다. 저는 개발자가 아무 것도 액세스할 수 없는 배경에서 왔고 당신은 개발자가 모든 OS 리소스에 액세스할 수 있는 배경에서 왔습니다.

그들이 그랬다면 당신은 그것에 대해 생각조차하지 않았습니다. 마법사는 때때로 더 작은 크기로 실행되고 마법사가 완료되면 앱이 전체 화면으로 전환될 수 있습니다.

예 마법사는 더 작은 크기로 실행되지만 대부분의 마법사(Visual Studio 2019 Startup "마법사" 포함)는 스스로를 닫은 다음 실제 프로그램을 시작합니다. 실제 응용 프로그램으로 "모핑"하지 않습니다.

일부 마법사는 새 창이 아니라 팝업이며 실제 응용 프로그램이 백그라운드에 있다는 점은 주목할 가치가 있습니다.

특정 크기만 좋아 보이는 창을 표시하기 때문에 시작 경험이 좋지 않습니다. Windows에서는 "오, 하지만 원하는 대로 앱을 표시하겠습니다"라고만 말합니다.

Windows가 항상 코드를 무시하는 것처럼 보이게 하고 언제 이를 무시할지 명확합니다("PreferredLaunchViewSize" 문서에서 가져옴).

이 속성은 태블릿 모드가 아닌 데스크톱 장치에서 앱을 실행할 때만 효과가 있습니다.

따라서 태블릿이 아닌 모드의 데스크톱에서만 작동합니다. 그러나 실제로 크기를 요청하는 것이 다른 장치에서 의미가 있습니까? 앱이 X-Box 또는 Holo Lens에서 실행될 것으로 예상하고 이러한 장치에 최적화되어 있습니까? 그렇지 않은 경우이 제한이 그렇게 많이 귀찮게하지 않아야합니다.

솔직히 이러는거야? 의식적으로 수행한 코드가 어떻게 잘렸는지 보여주세요.

아니요, 저는 당신이 그와 관련이 없는 것에 대해 "비동기"를 비난한다는 사실을 지적하려고 했습니다. 사용자가 버튼을 두 번 클릭하면 clicked 이벤트가 두 번 트리거됩니다.

WPF는 이것을 어떻게 처리합니까? 올바르게 처리합니다. UI는 차단되지 않지만 앱은 해당 호출에서 차단됩니다. 따라서 위의 내용은 WPF에서 발생하지 않습니다.

UI 스레드에서 코드를 실행하고 완료하는 데 시간이 걸리는 경우 WPF에서 UI 스레드를 차단하는 것보다 확실히 확신합니다.

안녕하세요, 저는 Windows OS 팀의 Windows SDK 및 Windows 런타임 인프라의 개발 책임자입니다.

이것은 많은 세부 사항과 대화가 포함된 훌륭한 토론입니다. 며칠 전에 누군가가 이 대화를 가져왔고, 저는 그것을 끝까지 읽고 싶지만, 제가 그것에 도달하기까지 여전히 며칠이 걸릴 수 있습니다. 그러나 나는 전체를 읽고 더 자세한 답변을 제공하거나 최선을 다해 후속 조치를 취하려고 노력할 것입니다.

이것은 아마도 winrt 일반 문제에 가장 적합한 장소가 아닐 것입니다. Microsoft 개발자 포럼에서 문제를 제기하거나 특히 Windows 런타임 문제의 경우 https://github.com/microsoft/xlang 에서 문제를 열 ​​수 있습니다

활발한 토론에 다시 한 번 감사드립니다. 이 문제에 대해서는 곧 다시 게시하겠습니다.

벤 쿤
마이크로소프트

안녕 벤,

안녕하세요, 저는 Windows OS 팀의 Windows SDK 및 Windows 런타임 인프라의 개발 책임자입니다.

이것은 많은 세부 사항과 대화가 포함된 훌륭한 토론입니다. 며칠 전에 누군가가 이 대화를 가져왔고, 저는 그것을 끝까지 읽고 싶지만, 제가 그것에 도달하기까지 여전히 며칠이 걸릴 수 있습니다. 그러나 나는 전체를 읽고 더 자세한 답변을 제공하거나 최선을 다해 후속 조치를 취하려고 노력할 것입니다.

굉장합니다 - 귀하의 회신을 기다리십시오!

저는 원래 포스터이기 때문에 질문이 있거나 명확하지 않은 점이 있으면 알려주시면 최선을 다해 설명하겠습니다.

이것은 아마도 winrt 일반 문제에 가장 적합한 장소가 아닐 것입니다. Microsoft 개발자 포럼에서 문제를 제기하거나 특히 Windows 런타임 문제의 경우 https://github.com/microsoft/xlang 에서 문제를 열 ​​수 있습니다

그것이 최고의 장소가 아니라는 데 동의했지만 문제는 사람들이 어디에 게시할지 모른다는 것입니다.

https://github.com/microsoft/xlang 에 게시해야 한다고 하면 지금부터 거기에 게시하겠습니다.

최상의,
남자

먼저 다루지 않을 몇 가지 사항을 짚고 넘어가겠습니다.

• 스레드 하단 부근에서 Windowing, 창 위치 등에 대해 많은 토론이 있습니다. 그것은 아마도 여전히 WinUI의 주제에서 조금 벗어나 있지만 집에 더 가깝습니다. WinUI 사람들이 창 위치, 전체 화면 등에 대한 피드백을 구문 분석하고 리디렉션을 돕도록 하고 싶습니다. @StephenLPeters , 이것을 도와줄 수 있습니까?

• 나는 VS 피드백을 건드리지 않을 것입니다. VS 품질 및 성능에 대해 논의할 수 있는 건강한 포럼이 있습니다. Visual Studio에서 Windows 앱을 개발하는 이야기가 좀 더 복잡해지고 혼란스러워졌다는 논의에 주목했습니다.

• WPF. 나는 WPF와 사랑의 증오 관계가 있습니다. 유용하고 대부분 좋습니다. 파일 선택기에서 중첩된 클릭에 대한 설명을 읽었을 때 나는 웃었습니다. WPF에는 정말 골치 아픈 문제가 몇 가지 있기 때문입니다. WPF에서 드래그할 때 드래그 메시지가 중첩된 메시지에서 이중 전달되는 경우가 있으므로 실제로 모달 드래그 내에서 모달 드래그를 수행하고 있습니다. 당신은 보통 눈치 채지 못합니다. 대개. 그러나 나는 여전히 WPF를 좋아합니다. 😉

둘째, @verelpode : 저를 웃게 만들었습니다. 내가 이것에 매달리면 괜찮습니까?
"직접적인 진실은 다루지 못하실 것 같아서 두툼한 솜장갑을 끼고 뽁뽁이로 싸서 보내드립니다"

자, 이제 실제 주제로 넘어갑니다.

WinRT vs. UWP vs. .NET – 약간의 배경 지식

Windows 런타임은 실제로 두 가지가 하나로 통합되고 다른 것으로 압축되어 실제로 오해되고 있습니다.

Windows 런타임 유형 시스템은 실제로 어떤 의미에서는 COM V2입니다. 인터럽트 트리거에서 Win32 호출, COM API 호출에 이르는 진행의 영적 다음 단계입니다. 유형 시스템은 COM에서 어떤 면에서 표현력이 약간 떨어지지만 대부분의 경우 상당한 상위 집합입니다. 원래 정확히 하나의 문제를 해결하기 위해 설계되었습니다. VS가 .NET 프레임워크에서 멋진 래퍼를 만들 때까지 기다릴 필요 없이 .NET 또는 다른 언어를 사용하는 개발자가 WinRT API를 더 쉽게 호출할 수 있도록 하는 방법입니다.

그런 다음 API 라이브러리가 있습니다. 우리는 여기서 몇 가지 훌륭한 일을 했고 몇 가지 어리석은 일을 했습니다. 비동기 항목 중 일부에 약간 빠져 들었을 수 있습니다. C++ /WinRT로 프로그래밍하면 이를 크게 완화할 수 있습니다. UI 스레드에 있지 않은 경우 결과를 가져오기만 하면 동기화되어 차단되고 완료됩니다. .NET을 사용하면 이제 이 작업이 더 쉬워질 수도 있지만 요즘에는 .NET 코드를 덜 작성하고 있으며 현재 상황에 대해 확신이 없습니다. 계획대로 작동하지 않는 몇 가지 다른 작업도 수행했습니다. 나는 그것들을 모두 나열하지 않을 것입니다. 하지만 몇 가지 개선 사항이 있습니다.

UWP 애플리케이션 모델은 두 발로 winrt에 뛰어들었습니다. 즉, OS API를 한 번만 작성하면 JS 기반 앱, .NET 앱 및 기본 앱에서 쉽게 액세스할 수 있습니다. 그 자체가 선함이었다. 다른 모든 Win32 API를 제거하는 것은 좋지 않았습니다. 아직 문서 작업이 몇 가지 남아 있지만 지금은 스토어 앱에서 사용할 수 있는 훨씬 더 고전적인 Win32 API가 있습니다. 간단히 말해서, 우리는 새로운 장치에 대한 소규모 사용자 기반으로 완전히 새로운 앱 플랫폼을 만들었으며 기존 코드를 가져오는 것을 허용하지 않았으며 많은 사람들이 나타나지 않았습니다. 우린 알아. 그렇기 때문에 조금씩 수정하고 있습니다. 우리도 많은 것을 얻었고, 두 세계의 최선의 접근 방식을 향해 천천히 그러나 꾸준히 노력하고 있습니다. 선언적 설치 시스템은 대부분의 면에서 훌륭한 것입니다.

UWP 앱과 데스크톱 앱 간의 코드 이식성도 이 스레드에서 다루었습니다. UWP 모델이 너무 다양했기 때문에 여러 가지 고충이 있습니다. 우리는 가능한 한 빨리 문제를 해결하고 있습니다. 일부는 시간이 걸리거나 "주요 휴식"이 필요합니다. 예를 들어, 우리는 CRT DLL에 대해 다른 이름을 사용합니다. 우리는 완화책인 VC 포워더 패키지를 구성했지만 실제 수정은 결국 파일 이름 바꾸기와 주요 변경 사항이 본질적으로 필요한 CRT의 향후 버전에서 구분을 제거하는 것입니다. 방해가 되기 때문에 의도적으로 이 작업을 드물게 수행합니다.

WinRT 자체는 툴링 오픈 소스를 점점 더 많이 옮기고 있으며 잘 알려져 있지는 않지만 대부분의 WinRT는 데스크톱 앱에서 사용할 수 있습니다. XAML은 큰 격차였습니다. XAML Islands는 올바른 방향으로 나아가는 단계였지만 저는 WinUI가 훨씬 더 기대됩니다.

특정 API에 대한 피드백

이 중 많은 경우 이것이 귀하의 문제인 경우 피드백을 제출하도록 요청하겠습니다. 문제를 올바른 팀으로 홍보하는 데 도움을 드리겠습니다. Windows의 다른 팀은 각각 고유한 API를 담당하며 피드백 허브에 제출하는 것이 가장 효과적입니다. 이것은 피드백을 실제 인간 및 이야기와 연결합니다. 또한 피드백을 추적할 수 있습니다. 다른 사람들이 적절하게 제출하는 피드백에 추가하여 서로를 조금 도울 수 있습니다. 적절한 카테고리를 선택하십시오. 명확하지 않은 경우 "개발자 피드백" -> API 피드백을 사용할 수 있습니다.

최신 앱을 위한 파일 시스템 API는 고통스럽고 예기치 않게 느립니다.

https://docs.microsoft.com/answers/questions/608/Please-either-allow-systemio-all-over-hdd-or-dast.html
우리는 고객과 애플리케이션을 구축하는 우리 팀 모두로부터 이 피드백을 들었습니다. 이 시간에 나눌 수 있는 것이 더 많았으면 좋겠습니다. 현재로서는 불행히도 "우리는 알고 있습니다"라고 말할 수 있습니다.

BroadSystemAccess API/기능은 구현된 대로 실용적이지 않습니다.

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
피드백 허브 항목을 제출하고 링크를 보내주세요. 개인적으로 홍보해서 제대로 된 주인에게 건네겠습니다. 80% 감소율은 좋지 않습니다. 사용자들에게도 적신호라는 점을 이해합니다. IF, 파일 API가 충분히 빠르면 향후 액세스 목록이 최소한의 고통을 완화할 것 같지만 지금처럼 '매끄럽지' 않을 수도 있습니다. 그러나 그때, 당신은 바위와 어려운 장소 사이에 있습니다. 당신이 지금 하고 있는 방식이 마법처럼 되기 위해서는 사용자가 모든 것을 볼 수 있도록 해야 합니다. 그들의 비밀번호 스프레드시트, 그들의 메일 폴더, 그들의 브라우저 캐시 등. 당신은 신뢰할 수 있지만, 당신의 앱은 사용자들이 그들의 세계를 넘겨주기 전에 잠시 멈추고 그들이 당신을 얼마나 신뢰하는지 생각하게 해야 합니다.

앱을 닫고 다시 시작하는 아이디어가 어색한 단계라는 것을 이해합니다. 이것은 적어도 첫 출시에서 분류되어야 하는 유형인 것 같습니다. 피드백 항목은 별도로 제출해 주세요. 같은 제안. 홍보 및 전달하겠습니다.

향후 액세스 목록이 하위 폴더에 액세스할 수 있는지 여부와 관련하여 페이지에 대한 문서 문제를 만들었습니다. https://github.com/MicrosoftDocs/windows-uwp/issues/2322. 문서 페이지가 github에 있으므로 문서에 문제를 제기하거나 내용에 대한 변경을 제안할 수도 있습니다.

파일을 앱으로 드래그하면 쓰기 액세스가 허용되지 않습니다. 피드백 허브에 대한 동일한 제안입니다. 제출해 주시면 그에 따라 안내해 드리겠습니다.

MS 스토어 외부에서 사이드로딩을 위한 앱 만들기

여기서 얻은 결론은 문제의 대부분이 문서 문제이지만 또 다른 주요 측면을 다룬다는 것입니다. 일부 도구가 github 프로젝트 및 오픈 소스로 이동함에 따라 설명서도 함께 이동했으며, 이로 인해 Windows 설명서를 모든 것을 원스톱으로 사용하기가 더 어려워졌습니다. .appinstaller 파일과 관련된 특정 문제와 관련하여 내부적으로 이 문제를 제기하고 더 나은 해결 방법에 대해 콘텐츠 팀과 보다 일반적으로 논의하겠습니다.

또한 디버그를 위해 서버를 통해 라우팅해야 하는 특정 문제에 대해서도 언급했습니다. 기존 github 프로젝트에 대한 문제로 제출해야 합니다.

신규인증서 발급 및 사설유통

이것은 제 집에서 조금 더 가깝습니다(제 큰 팀에서도 응용 프로그램 설치 측면을 처리합니다. 저는 여전히 제가 작업할 수 있는 피드백 허브 문제에 감사하고 있습니다.

WinRT 유형 시스템은 훌륭한 API 및 라이브러리를 제공하는 능력에 영향을 미칩니다.

형식 이름에 오버로드할 수 없는 것은 의도적으로 설계된 것입니다. javscript(Node / V8은 어떻습니까? 흥미롭지 않을까요?) 앱이 WinRT API에 액세스하는 방법을 다시 생각할 때까지 우리는 이것을 다시 살펴볼 준비가 되지 않을 것입니다. 속성 및 NaN에 대한 다른 문제는 좋은 논의가 있는 별도의 문제에 있으므로 이 답변에서 자세히 다루지 않겠습니다.

콘텐츠가 실수로 삭제되는 것을 방지하기 위해 포기할 때 피드백 허브에 메시지가 표시되어야 합니다.

네, +1하겠습니다. 파일을 제출하세요. 피드백 허브에 대한 앱 아래 피드백 허브에 범주가 있습니다. 너무 메타입니다.

비동기 API는 여전히 손에 잡히지 않고 비동기가 되어서는 안 되는 것들에 대해 어색해 보입니다.

네. 이는 내부적으로도 논란의 여지가 있는 부분이다. 유모와 좋은 행동을 장려하는 것 사이에는 아직 잘 맞지 않은 균형이 있습니다. 동기식으로 보고 싶은 특정 API에 대한 피드백을 계속 제출하십시오.

WinRT에는 좋은 오디오 API가 없습니다.

저는 오디오 전문가가 아닙니다. 피드백 허브에 자유롭게 파일을 제출할 수 있지만 여기에서 구명줄에 전화를 걸어 몇 가지 물어볼 것입니다.

클립보드 고통

여기서 Mae Culpa로 시작해야 합니다. 우리의 클립보드 액세스 모델은 사용자를 철저히 보호하던 Win8 시대에 설계되었습니다. 대부분 코딩했습니다. 클립보드를 보호해야 하는 이유가 있습니다. 사용자는 모든 종류의 민감한 데이터를 클립보드에 저장하지만 클립보드를 덮어쓸 수 있는 앱은 더 많은 액세스 권한이 있을 수 있는 다른 앱의 약점을 악용하여 해를 끼칠 수 있습니다. Win32 클립보드 API는 또한 남용될 수 있는 몇 가지 매우 강력한 동작을 가능하게 합니다. 따라서 클립보드는 앱이 포그라운드에 있거나 디버거에 연결되어 있지 않는 한 액세스를 제한하고 클립보드에 넣을 수 있는 항목을 약간 강화합니다(실제로 시도하지 않는 한 결코 알아차리지 못하는 방식으로).

즉, 상호 작용하는 알림은 클립보드 액세스를 허용해야 하는 것 같습니다. 이것은 Windows와 전경이 계산되는 방식 때문에 특별한 처리가 필요하다고 생각하지만 합리적이지 않은 것 같습니다. API 피드백으로 제출해 주시면 해당 문제를 버그 데이터베이스에도 홍보하겠습니다.

마무리

도움이 되기를 바랍니다. 스레드를 추적하고 위의 문제를 제기하면 언급한 대로 후속 조치를 취하겠습니다.

이미 많은 것을 손에 넣은 WinUI 팀에 대한 존경의 표시로 이 스레드를 마무리하고 이 스레드에서 제기된 WinUI 및 Windowing 측면에만 집중하십시오. 이 문제는 너무 길고 구불구불하기 때문에 별도의 작은 문제로 분류하는 것이 도움이 될 수 있습니다. 여러분 모두가 피드백을 제출하고 링크가 포함된 의견을 제출할 수 있도록 이 스레드를 며칠 동안 열어 둔 다음 이 스레드를 닫겠습니다.

WinRT 유형 시스템 토론에 대해 더 자세히 알아보려면 xlang 프로젝트를 시작하는 것이 좋습니다. 특정 Windows API 동작의 경우 피드백 허브가 더 나은 선택입니다. 지금은 댓글 시스템도 있으므로 도움이 되길 바랍니다.

많은 주제에 대한 훌륭한 토론과 자세한 피드백에 다시 한 번 감사드립니다.

벤 쿤
마이크로소프트

사용자가 앱에 액세스 권한을 부여할 항목을 선택할 수 있는 파일 선택기를 표시한 경우 앱이 닫히지 않습니다.

이것이 사용자로서 얼마나 중요한지 아무리 강조해도 지나치지 않습니다. 모든 앱에 액세스 권한을 부여하고 싶지는 않지만 이상한 위치를 요청하면 _그것이 말이 되는_ 경우 액세스 권한을 부여하겠습니다.

@BenJKuhn 자세한 답변 감사합니다. 대단히 감사합니다!

• WPF. 나는 WPF와 사랑의 증오 관계가 있습니다. 유용하고 대부분 좋습니다. 파일 선택기에서 중첩된 클릭에 대한 설명을 읽었을 때 나는 웃었습니다. WPF에는 정말 골치 아픈 문제가 몇 가지 있기 때문입니다. WPF에서 드래그할 때 드래그 메시지가 중첩된 메시지에서 이중 전달되는 경우가 있으므로 실제로 모달 드래그 내에서 모달 드래그를 수행하고 있습니다. 당신은 보통 눈치 채지 못합니다. 대개. 그러나 나는 여전히 WPF를 좋아합니다. 😉

전적으로 동의합니다. 저는 WPF를 옹호하는 사람이 아닙니다. 저는 오래전에 WPF의 한계에 부딪혔습니다. 그것이 내가 UWP로 이사한 이유입니다. 안정성 측면에서 WPF는 훨씬 더 안정적입니다.

WinRT vs. UWP vs. .NET – 약간의 배경 지식

그런 다음 API 라이브러리가 있습니다. 우리는 여기서 몇 가지 훌륭한 일을 했고 몇 가지 어리석은 일을 했습니다. 비동기 항목 중 일부에 약간 빠져 들었을 수 있습니다.

다시 말씀 하셔도됩니다 :)

UWP 앱과 데스크톱 앱 간의 코드 이식성도 이 스레드 [...]에서 다루었지만 실제 수정은 결국 CRT의 향후 버전에서 구분을 제거하는 것입니다. .

도착 예정 시간이 있습니까? .넷 5?

최신 앱을 위한 파일 시스템 API는 고통스럽고 예기치 않게 느립니다.

https://docs.microsoft.com/answers/questions/608/Please-either-allow-systemio-all-over-hdd-or-dast.html
우리는 고객과 애플리케이션을 구축하는 우리 팀 모두로부터 이 피드백을 들었습니다. 이 시간에 나눌 수 있는 것이 더 많았으면 좋겠습니다. 현재로서는 불행히도 "우리는 알고 있습니다"라고 말할 수 있습니다.

지금까지 해결 방법이 있습니다 - 이상적이지는 않지만 지금은 괜찮습니다 - https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

BroadSystemAccess API/기능은 구현된 대로 실용적이지 않습니다.

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
피드백 허브 항목을 제출하고 링크를 보내주세요. 개인적으로 홍보해서 제대로 된 주인에게 건네겠습니다. 80% 감소율은 좋지 않습니다. 이해 했어요

할 것입니다. 주말에 도착할 수 있기를 바랍니다.

사용자에게도 위험 신호라는 점입니다. 파일 API가 충분히 빠르면 향후 액세스 목록이

예, StorageFile/Folder API가 System.IO만큼 빠르면(또는 최소한 비슷한 수준) 이를 완화할 수 있습니다. 노력이 부족해서가 아닙니다. 문서에 설명된 모든 작업을 수행했습니다.

통증이 있지만 지금처럼 '매끄럽지' 않을 수도 있습니다. 그러나 그때, 당신은 바위와 어려운 장소 사이에 있습니다. 당신이 지금 하고 있는 방식이 마법처럼 되기 위해서는 사용자가 모든 것을 볼 수 있도록 해야 합니다. 그들의 비밀번호 스프레드시트, 그들의 메일 폴더, 그들의 브라우저 캐시 등. 당신은 신뢰할 수 있지만, 당신의 앱은 사용자들이 그들의 세계를 넘겨주기 전에 잠시 멈추고 그들이 당신을 얼마나 신뢰하는지 생각하게 해야 합니다.

나는 이 모든 것을 완전히 이해합니다. 그리고 나는 당신과 동의합니다. 나의 고충은 이 모든 것의 현재 구현입니다. 나는 이미 이것을 다루는 대부분의 UI를 다시 작성했습니다(여러 번).

개선을 위한 제 아이디어는 다음과 같습니다.

• "폴더 선택"이 조금 더 도움이 될 수 있습니다. 내가 관심 있는 파일을 지정할 수 있으며, 사용자에게 해당 파일이 포함된 폴더를 강조 표시할 수 있습니다.
• 클립보드 - 사용자가 일부 파일/폴더를 클립보드에 넣은 다음 내 앱으로 돌아가면 자동으로 해당 파일/폴더에 액세스할 수 있어야 합니다("ClipboardFilesAndFolders" 기능을 추가할 수 있음).
• 파일/폴더 끌어서 놓기 - 자동으로 해당 파일에 액세스할 수 있어야 합니다(그렇지 않으면 사용자가 내 앱에 파일을 드롭하는 이유는 무엇입니까?)

앱을 닫고 다시 시작하는 아이디어가 어색한 단계라는 것을 이해합니다. 이것은 적어도 첫 출시에서 분류되어야 하는 유형인 것 같습니다. 피드백 항목은 별도로 제출해 주세요. 같은 제안. 홍보 및 전달하겠습니다.

알겠습니다. 감사합니다. 주말 동안입니다.

파일을 앱으로 드래그하면 쓰기 액세스가 허용되지 않습니다. 피드백 허브에 대한 동일한 제안입니다. 제출해 주시면 그에 따라 안내해 드리겠습니다.

알겠습니다. 파일을 앱으로 드래그하는 것입니다. 나는 실제로 그것을 아직 시도하지 않았다:

1. 파일과 폴더 모두에서 작동합니까?
2. .Path에 액세스할 수 있습니까?
3. 지속적입니까(그렇지 않다고 가정)?
4. StorageFile/Folder를 계속 사용해야 합니까, 아니면 나중에 .Path에서 다시 만들어야 합니까(2.에 대한 대답이 YES라고 가정)?

MS 스토어 외부에서 사이드로딩을 위한 앱 만들기

여기서 얻은 결론은 문제의 대부분이 문서 문제이지만 또 다른 주요 측면을 다룬다는 것입니다. 일부 도구가 github 프로젝트 및 오픈 소스로 이동함에 따라 설명서도 함께 이동했으며, 이로 인해 Windows 설명서를 모든 것을 원스톱으로 사용하기가 더 어려워졌습니다. .appinstaller 파일과 관련된 특정 문제와 관련하여 내부적으로 이 문제를 제기하고 더 나은 해결 방법에 대해 콘텐츠 팀과 보다 일반적으로 논의하겠습니다.

예, 굉장할 것입니다!

개인적으로 나는 내 앱을 위해 그것을 알아 냈습니다. 내가 하고 싶은 다른 고급 작업을 수행하지 못하게 하고 있습니다(예: 전체 .appinstaller 파일이 어떻게 변경되어야 하는지 두려워서 win32 앱을 시작해야 함).

그러나 나에게 이것은 Visual Studio "게시" 프로세스의 일부여야 합니다. 저를 위해 .appinstaller를 만들어야 합니다(모든 종속성 이름을 올바르게 가져오는 것은 결코 쉬운 일이 아니며 종속성에 대한 업데이트 -> 여기에서 다시 시작하겠습니다). 또한 readme.txt 파일을 생성해야 합니다. 여기에는 서버에 업로드해야 하는 내용을 설명해야 하고 .appinstaller를 로컬로 사용할 수 없으며 서버에서 다운로드해야 합니다(테스트 시 )

또한 디버그를 위해 서버를 통해 라우팅해야 하는 특정 문제에 대해서도 언급했습니다. 기존 github 프로젝트에 대한 문제로 제출해야 합니다.

무슨 문제였는지 기억이 안나네요 :)

콘텐츠가 실수로 삭제되는 것을 방지하기 위해 포기할 때 피드백 허브에 메시지가 표시되어야 합니다.

네, +1하겠습니다. 파일을 제출하세요. 피드백 허브에 대한 앱 아래 피드백 허브에 범주가 있습니다. 너무 메타입니다.

오른쪽 :)

비동기 API는 여전히 손에 잡히지 않고 비동기가 되어서는 안 되는 것들에 대해 어색해 보입니다.

네. 이는 내부적으로도 논란의 여지가 있는 부분이다. 유모와 좋은 행동을 장려하는 것 사이에는 아직 잘 맞지 않은 균형이 있습니다. 동기식으로 보고 싶은 특정 API에 대한 피드백을 계속 제출하십시오.

헤헤, 긴 목록입니다 ;)

1. StorageFolder/File의 기본 속성으로 시작합니다. StorageFile.GetFileFromPathAsync(+ 폴더와 유사).
2. 썸네일 로드(StorageFile.GetThumbnailAsync
3. 비트맵 로드. 이것은 다른 라이브러리(예: win2d)로 옮겨졌기 때문에 특히 고통스럽습니다. 그리고 5초 정도 지속되는 데 간단한 비트맵(<20ms가 소요되어야 함)을 로드하는 것과 같은 미친 임계값에 도달했습니다. 분명히 배후에는 어떤 잠금 장치가 있지만 아무도 무엇을/왜/언제 알지 못합니다. 그리고 네, 제 노트북은 로켓입니다.

나는 다른 많은 API를 추적하지 않았습니다. 내 프로젝트에 대한 빠른 검색은 326개의 용도를 보여줍니다. 많은 부분이 동기식이어야 하기 때문에 많이 줄였습니다.

위는 내 머리 꼭대기에서 내 주요 최고 통증입니다. 이제부터 문서를 만들어 추가하겠습니다. :)

WinRT에는 좋은 오디오 API가 없습니다.

저는 오디오 전문가가 아닙니다. 피드백 허브에 자유롭게 파일을 제출할 수 있지만 여기에서 구명줄에 전화를 걸어 몇 가지 물어볼 것입니다.

이 문제가 해결될지 여부는 확실하지 않습니다. 가장 쉬운 방법은 요구 사항을 완화하여 naudio(https://github.com/naudio/NAudio)를 UWP에 올바르게 이식할 수 있도록 하는 것입니다. 분명히 말해서, 즉시 UWP로 컴파일할 수 있지만 대부분의 유용한 항목이 #ifdef-ed되어 있기 때문에 쓸모가 없습니다.

분명히 말씀드리자면, 저는 UWP의 사운드 API에 대해 불평하지 않습니다. 이는 완전히 괜찮지만 더 필요합니다. 즉, 음파 등을 해석하는 능력(오디오가 허용하는).

나는 거의 모든 #ifdef를 제거한 naudio 포트를 수행했습니다. 작동하지만 내 앱은 MS 스토어에 들어가지 않습니다. 그리고 저는 괜찮습니다.

클립보드 고통

[...] 즉, 상호 작용하는 알림은 클립보드 액세스를 허용해야 하는 것 같습니다. 이것은 Windows와 전경이 계산되는 방식 때문에 특별한 처리가 필요하다고 생각하지만 합리적이지 않은 것 같습니다. API 피드백으로 제출해 주시면 해당 문제를 버그 데이터베이스에도 홍보하겠습니다.

좋은 소리, 할 것입니다.

감사 해요!

@jtorjo 파일 시스템에 대한 피드백 허브 항목에 문제 #1893(제안: 파일 시스템 액세스: 특정 파일 위치에 대한 액세스 권한을 요청할 수 있는 사용자 친화적인 방법 제공)도 포함 것 같습니다 .) 파일 시스템을 다룰 때 이 항목을 다룰 수 있다면 이미 정리할 다른 항목이 많이 있습니다. :)

물론 피드백 허브에 추가하는 것이 불편하시다면 계속 제출하겠습니다!

@Felix-Dev 최선을 다하겠습니다! 계속 알려드립니다!

파일을 앱으로 드래그하면 쓰기 액세스가 허용되지 않습니다. 피드백 허브에 대한 동일한 제안입니다. 제출해 주시면 그에 따라 안내해 드리겠습니다.

알겠습니다. 파일을 앱으로 드래그하는 것입니다.

이것은 실제로 쉘 컨텍스트 메뉴에서 여는 것에 대한 참고 사항이었습니다. 혼란을 드려 죄송합니다.

@BenJKuhn 이 Github 감안할 때(지난 12개월 동안 이 리포지토리에서 여러 번 표현된 개발자 감정을 기반으로 함): 그냥 게시해도 될까요? 이 리포지토리에 있는 훨씬 더 심층적인 제안에 대한 링크가 있는 Feedback Hub에 대한 빠른 제안 요약(지금은 내가 알고 있는 개발자 커뮤니티의 신뢰를 받는 특정 UWP 앱 모델 피드백 플랫폼이 없기 때문에)? Microsoft의 특정 팀이 개발 중인 제안에 대한 직접 링크를 가질 수 있도록 여기에서 다른 커뮤니티 입력으로 제안이 더욱 구체화되는 것을 보았습니다.

@Felix-Dev 특정 제안의 경우 "개발자 플랫폼 > API 피드백"이라는 태그가 붙은 Feedback Hub에 제출하는 것이 가장 좋습니다.

해당 필터 아래에 제출된 최근 피드백을 살펴보면 그다지 구체적인 피드백이 추가되지 않은 것 같습니다. 나는 그 필터로 분류된 30개 항목(최대)만 보았다. 그러나 최근 엔지니어들이 피드백에 응답했습니다.

위에 태그가 지정된 Feedback Hub를 통해 API 피드백을 제출하도록 커뮤니티에 요청하고 있으며 제안이 개선되면 API 피드백을 제출하는 옵션으로 번성하기 시작할 것입니다.

@BenJKuhn 이 나와 동의할 것이라고 생각합니다.

답변이 상당히 길어 졌으니

@duke7553 커뮤니티가 UWP 플랫폼 피드백을 위해 두 가지 다른 플랫폼을 사용해야 하는 상황이 있습니다. (매개변수 x를 메서드 y에 추가하거나 z를 수행하는 메서드를 추가하세요)와 같은 특정 API 요청은 최소한 피드백 허브에 제출해야 합니다(물론 추가 위치에도 게시되어야 함). 그러나 (UWP의 핵심까지) 플랫폼보다 더 복잡한 문제/제안은 현재 형식의 피드백 허브가 아닌 다른 곳에 게시해야 합니다. 피드백 허브에 짧은 요약을 게시하는 것은 좋지만 다른 무엇보다도 피드백 허브는 현재 플랫폼이 아닙니다. 이유에 대한 자세한 내용은 아래를 읽으십시오.

현재 상태에서 피드백 허브는 바로 이 저장소와 Twitter 와 같은 다른 장소에서

• Windows 개발자 팀의 (인지된) 참여 부족(최근에 제출된 API 피드백도 살펴보았고 현재 현재로서는 특히 2개월 및 더 오래된).
• 특정 문제/제안에 대한 커뮤니티 참여도는 상당히 낮습니다(공동 투표, 댓글).
• 피드백 허브의 전반적인 UI/UX는 팀 및 커뮤니티와 피드백 토론에 참여하는 것을 매우 어렵게 만듭니다. 이에 대해 WinUI 팀의 일부 사람들은 여기 커뮤니티에도 동의한다고 말했습니다 .
• 마지막으로, 지금 Github에서 이미지나 GIF와 같은 지원 미디어 파일을 제안에 추가하여 시각화하는 것이 훨씬 쉽습니다. 문제를 제출할 때 피드백 허브에서 직접 가져온 이 이미지를 여기에 남겨두겠습니다.
  

저는 Feedback Hub를 사용하여 개발 플랫폼별 문제를 제출한 적이 없으며 지금 바로 살펴보고 있습니다. 커뮤니티에서 문제가 어떻게 접수되는지(커뮤니티 참여가 거의 0에 가깝습니다!), Windows 개발 팀 및 전체 구조 는 다음과 같습니다. 이 단일 WinUI 저장소는 기본적으로 모든 측면에서 피드백 허브보다 우수합니다 (제안 작성 용이성/커뮤니티 참여/MS 개발자의 가용성/...).

솔직히 가깝지도 않습니다.

특히 지역 사회 참여와 관련하여. 여기 이 리포지토리에서 커뮤니티 입력이 얼마나 예외적이었고 많은 문제/제안을 대대적으로 추진하고 개선했는지 충분히 강조할 수 없습니다. 현재 피드백 허브에만 제출하면 훌륭한 커뮤니티 입력이 모두 사라질 것입니다.

그리고 여기 만든 내 UWP 응용 프로그램 모델 문제 개발팀에 의해 반응에 대해, 난 그냥이 말을합니다 : 같은 많은 경우에 이것을 내가 작업 항목이 내부적으로 생성 된 것을 메모와 함께 적시에 피드백을 얻었다. 무엇을 더 요청할 수 있습니까? 피드백 허브에 제출하면 문제가 전혀 해결되지 않을 것이라고 느끼는 많은 개발자의 감정과 대조됩니다. 그리고 지금 피드백 허브를 보면 그들이 어디에서 왔는지 알 수 있습니다.

@BenJKuhn
MS 팀은 UWP 피드백 플랫폼을 심각하게 강화해야 하며 이러한 개선 사항을 볼 때까지 WinUI 팀에서 허용하는 한 여기에서도 항상 이 리포지토리를 사용할 것입니다. Feedback Hub는 현재 많은 Windows 개발자의 눈에 가장 낮은 위치에 있으며 하룻밤 사이에 게시해도 상황이 갑자기 바뀌지는 않습니다. 이제 시작이지만 피드백 허브(또는 이전에 UWP용 UserVoice를 종료한 것과 같은 다른 MS 특정 개발자 피드백 플랫폼)에 대해 말할 때 많은 개발자가 받게 될 부정적인 인상을 근본적으로 되돌리려면 훨씬 더 많은 것이 필요합니다. 많은 UWP/Windows 개발자가 Feedback Hub 또는 기타 과거 피드백 플랫폼을 처리할 때 겪었던 많은 실망스러운 경험을 감안할 때, 저는 이 문제에 대해 Windows 개발 및 피드백 팀이 개발자에게 반환 (많은 - 있는 경우 - 표시할 가시적인 개선 사항 없이). 나는 이것이 상당히 가혹한 견해라는 것을 알고 있지만, 이 리포지토리와 수년 동안 다른 많은 피드백 플랫폼에 제공된 개발자의 많은 응답을 실제로 보면 개발 커뮤니티에 진정한 좌절이 있음을 쉽게 알 수 있습니다.

Microsoft와 개발자 커뮤니티 모두에 높은 만족 가치를 제공하는 활기차고 유익한 피드백 플랫폼을 만들기 위해 양측이 서로를 필요로 하기 때문에 여기에서 가혹하게 말하고 싶지 않습니다. 타협으로 위의 게시물에서 커뮤니티와 적극적으로 논의할 수 있는 UWP 문제를 이 리포지토리에 게시하고 피드백 허브에 포함된 github 스레드에 대한 링크가 포함된 짧은 요약을 게시할 것을 제안했습니다. 내가 위에 나열한 커뮤니티에 대한 모든 이점 외에도 추가된 링크는 Windows 개발자 팀이 이 커뮤니티에 존재하는 다양한 관점을 살펴보고 아마도 제출되지 않을 많은 작은 아이디어도 포착할 수 있도록 합니다. 피드백 허브에 있지만 여기의 많은 댓글에서 찾을 수 있습니다 .

Feedback Hub의 개발자 플랫폼 -> API 피드백 섹션에서 가져온 스크린샷으로 이 게시물을 마치겠습니다.

추신: 이 게시물을 사용하여 WinUI 팀이 WinUI 와 전혀 관련이 없지만 대신 개발자가 UWP에서 보고 있는 근본적인 문제를 해결하는 것을 목표로 하는 문제를 호스팅하기 위해 저장소를 열기로 동의 한 WinUI 팀에 다시 한 번 진심으로 감사드립니다. 감사합니다, WinUI 팀!

@BenJKuhn

내가 만든 피드백 허브 문제는 다음과 같습니다.

BroadSystemAccess API/기능은 구현된 대로 실용적이지 않습니다. https://aka.ms/AA804aq

BroadSystemAccess API / 사용자가 광범위한 시스템 액세스를 허용할 때 앱을 다시 시작하면 안 됨 https://aka.ms/AA7zpe3

클립보드는 항상 작동해야 합니다. https://aka.ms/AA804ce

파일 시스템 액세스: 특정 파일 위치 https://aka.ms/AA804cp ( @Felix-Dev 의 경우)에 대한 액세스 권한을 요청하는 사용자 친화적인 방법을 제공합니다.

WinRT https://aka.ms/AA804d0 에는 좋은 오디오 API가 없습니다.

비동기 API는 여전히 손이 안 가고 비동기가 되어서는 안 되는 것들에 대해 어색해 보입니다. https://aka.ms/AA804d3

내가 만든 다른 것들

자세한 내용 - 더 많은 문자를 허용해야 함 https://aka.ms/AA7zws5

카테고리 선택 - 더 쉽게 https://aka.ms/AA804cd

내가 확신하지 못하는 것들

파일/폴더 끌어서 놓기 - 개인적으로 테스트하지 않았습니다. 즉, 구현하기가 그리 어렵지 않은 드래그 앤 드롭 부분이 궁금하지 않습니다. 사용자가 UWP 컨트롤에서 파일/폴더를 삭제할 때 실제로 작동하는지 궁금합니다. 읽기 전용 액세스 권한이 있습니까? 이 파일/폴더를 FutureAccessList에 추가할 수 있습니까?

온라인에 정보가 많지 않기 때문에 누군가 이것을 성공적으로 테스트/사용했는지 궁금합니다.

피드백 허브

피드백 허브는 즐거운 경험이 아닙니다. 우선 내가 추가한 문제가 "내 피드백"에 한동안 표시되지 않습니다. 앱을 닫고 다시 시작해야 합니다. 내 마지막 선택을 기억하지 않습니다. 텍스트를 너무 많이 쓸 수 없고 파일 및/또는 클립보드 이미지를 삭제할 수 없습니다. 그래서 저는 @Felix-Dev에 전적으로 동의합니다. 문제를 게시할 위치를 이해하는 것은 정말 어렵습니다(지금부터 xlang에 게시할 예정임을 제외하고).

@BenJKuhn 사용자와 상호 작용할 때 클립보드에 액세스할 수 있는 특정 알림 문제에 대한 피드백 허브 링크는 다음과 같습니다. https://aka.ms/AA7zx69

훌륭한 토론을 해주신 모든 분들께 감사드립니다. 귀하가 제출한 각 플랫폼 문제를 해당 팀에 전달했습니다. 그에 따라 기대치를 설정하기 위해 구직 활동을 유추해 보겠습니다. 채용 과정에서 심사를 통과하고 곧바로 면접을 보는 것과 비슷합니다. 여기에서 각 문제는 조사하고 우선 순위를 지정할 올바른 팀의 손에 달려 있습니다.

이러한 문제를 보고하기 위해 노력해 주셔서 감사합니다. 팀에서 문제를 검토하는 동안 계속 추적할 것입니다. 귀하가 직면한 문제에 대해 계속해서 우리와 함께 하기를 바랍니다. Windows에서 응용 프로그램 개발자 환경을 개선할 수 있도록 최선을 다해 지원하겠습니다.

감사 해요,

벤 쿤

@jtorjo 당신이 구축한 NAudio의 UWP 포트에 대한 WACK 보고서를 공유할 수 있습니까?

이 데이터는 NAudio가 스토어 인증을 통과할 수 있도록 완화해야 하는 제한 사항을 평가하는 데 도움이 됩니다.

@mikebattista WACK을 첨부했습니다. 오디오 문제만 고려하십시오.

분명히, log4net의 문제도 해결하기에 멋질 것입니다. log4net을 분기하고 해당 호출을 제거한다고 가정하더라도 괜찮을 것입니다. 그러나 우리가 실제로 전화를 받은 적이 없다고 확신하기 때문에 그들이 나타나는 것이 이상합니다. 어쨌든...

FindFirstFileExFromApp - 이것은 있어야 하며(실제로 존재합니다) - 확실히 플래그가 지정되어서는 안 됩니다.

EnumChildWindows/EnumWindows를 무시할 수 있습니다. #ifdef할 수 있습니다.

유효성 검사 결과.zip

감사 해요! 지원되는 API 실패를 평가합니다. 저는 오디오 팀에 연락하여 여기의 모든 제한을 잠재적으로 완화할 수 있는 의견을 얻었습니다.

@mikebattista 굉장합니다, 감사합니다! 이번이 상당히 기대됩니다 :)

끌어서 놓기 시나리오에 관한 @jtorjo :

1. 파일과 폴더 모두에서 작동합니까?
   많은 앱과 테스트에서 작동해야 하며 그렇지 않은 경우 버그를 신고하세요.
2. .Path에 액세스할 수 있습니까?
   가능성 - 스토리지 항목을 백업할 실제 파일 시스템 경로가 있으면 예입니다. (셸 라이브러리와 같은 것은 실제로 실제 파일 시스템 경로가 없습니다)
3. 지속적입니까(그렇지 않다고 가정)?
   아니요, 앱은 향후 액세스 목록에 추가하여 앱을 영구적으로 만들 수 있습니다.
4. StorageFile/Folder를 계속 사용해야 합니까, 아니면 나중에 .Path에서 다시 만들어야 합니까(2.에 대한 대답이 YES라고 가정)?
   향후 액세스 목록 또는 가장 최근에 사용 목록에 추가해야 합니다. 그렇지 않으면 해당 개체 인스턴스를 통해서만 액세스할 수 있습니다. 해당 인스턴스를 해제하면 액세스 권한이 사라집니다.

임의의 위치에서 비디오 파일을 추가하는 것과 관련하여 - 시스템은 의도적으로 임의 액세스를 허용하지 않지만 앱이 대체 위치에 배치된 파일의 일반적인 경우를 처리할 수 있으며 사용자는 이를 포함하도록 라이브러리를 업데이트하지 않았습니다. 인덱서 및 스토리지 감지 서비스에는 드라이브에서 세부 정보(파일 크기 등..)를 주기적으로 스캔하는 코드가 포함되어 있으며 사진 및 비디오 파일을 찾는 데 활용됩니다. 앱은 StorageLibrary API 를 사용하여 이러한 위치가 이미 라이브러리에 없는지 확인하고 발견된 경우 사용자에게 추가하라는 메시지를 표시할 수 있습니다. (이렇게 하면 사용자가 계속해서 책임을 지게 하고 일반적인 경우를 허용합니다.) 파일이 포함된 모든 위치를 자동으로 추가하는 것이 옳은 일인지 판단할 방법이 없기 때문에 아무것도 자동으로 추가되지 않습니다. [여러 3D 모델 구축 및 렌더링 도구를 사용하며, 예를 들어 내 사진 라이브러리에 표시하고 싶지 않은 수천 개의 텍스처 이미지가 있습니다.]

'FindFirstFileExFromApp - 이것은 있어야 합니다(그리고 실제로 존재합니다) - 확실히 플래그가 지정되어서는 안 됩니다.'
모든 *FromApp API가 앱 컨테이너 앱에서 사용하도록 설계되고 의도된 것에 전적으로 동의합니다. 따라서 도구가 그 중 하나에 플래그를 지정하는 경우 해결해야 하는 버그입니다.

@smaillet-ms 여기에 응답해 주셔서 감사합니다. Windows.Storage API의 속도를 개선하기 위한 작업이 수행되고 있습니까? 우리는 아주 오랫동안 답변을 기다리고 있습니다. 내 앱 시나리오에서 개선된 API를 사용하기 위해 NDA에 기꺼이 서명하고 싶습니다.

현재 FindFirstFile의 FromApp 구현을 사용하고 있지만 FromApp API를 사용하여 항목 축소판을 가져오는 것은 불가능합니다.

Windows 런타임을 개선하기 위해 수행 중인 작업에 대한 이 수준의 비밀은 이전에 스레드에서 Microsoft 엔지니어가 공유한 것과 대조됩니다.

관련 무시 피드백 링크: https://aka.ms/AA6dgqz

여기에 추가하기만 하면 특정 세부 정보는 NDA 뒤에 보호될 수 있지만 내부적으로 이 주제에 대한 작업이 진행 중인 경우 MS가 이를 공개적으로 언급하면 ​​많은 UWP 개발자를 안심시킬 수 있습니다(우리가 볼 수 있을 때 일반적인 전망과 함께). /더 많이 들으세요).

여러 OS 릴리스에서 스토리지 API의 성능을 개선하기 위해 많은 작업이 수행되었습니다. 이 시점에서 개발자의 과제는 주로 어떤 API를 언제 사용할지 아는 것입니다.

일을 하는 방법에는 여러 가지가 있으며 그 중 많은 것이 주어진 응용 프로그램에 대해 완전히 잘못되었습니다. 불행히도 "하나의 정답"이란 것은 실제로 응용 프로그램과 파일 시스템에서 얻은 정보로 무엇을 할 것인지에 달려 있기 때문입니다. *FromApp API는 현재 표준 Win32 대응 API에 비해 최고의 성능을 제공합니다. 여기에서 지적한 것처럼 썸네일 등과 같은 추가 셸 데이터가 모두 포함되어 있지는 않습니다(캐시에서 사용할 수 없는 경우 실제로 획득하는 데 비용이 많이 듭니다). 따라서 앱에서 이름/경로 또는 확장자를 기반으로 관심 있는 파일을 찾아야 하는 경우 *FromApp API를 사용하여 검색할 수 있습니다. 그런 다음 이름을 기반으로 StorageFile을 생성하여 자세한 내용을 검색할 수 있습니다. 중복된 오버헤드가 있지만 이 경우 액세스 확인이 두 번 수행되기 때문입니다. 하나의 파일만 찾으려고 하는 경우 문제가 되지 않는 경우가 많지만 대규모의 중복에는 비용이 발생할 수 있습니다. Windows.Storage.Search.IndexerOption .OnlyUseIndexerAndOptimizeForIndexedProperties와 함께 Storage WinRT API를 사용하는 경우 정말 빠른 열거를 얻을 수 있습니다. 이 열거형은 주문형 아래에 완전히 실현된 스토리지 항목으로 대체됩니다. 추가 액세스 검사를 포함해야 하는 경로에서. 단점은 사용자가 해당 위치에 대해 인덱서를 비활성화한 경우 작동하지 않는다는 것입니다.

사진/미디어 유형 앱과 같은 UI를 채우는 경우 BulkAccess 클래스는 가상화 등을 포함하는 UI의 사용 시나리오에 맞춰져 있으므로 아마도 가장 좋은 선택일 것입니다. 따라서 UI에 데이터를 빠르게 제공하고 더 많은 데이터를 공급할 수 있습니다. 사용자가 콘텐츠를 스크롤할 때 필요에 따라

내가 말했듯이, 많은 트레이드 오프가 있습니다. 분명히, 우리는 주어진 앱에 가장 적합한 것이 무엇인지 평가하는 프로세스를 문서화하는 방법을 알아내는 작업을 해야 합니다. 또한 기존 앱을 중단하지 않고 가장 일반적인 개선을 달성할 수 있는 부분을 계속 평가합니다.

WinRT는 큰 표면이며 MS의 단일 팀이 소유하지 않습니다. 각 팀은 각 릴리스에 대한 우선 순위를 평가하고 미리 계획을 게시할 수도 있고 게시하지 않을 수도 있습니다. 개인적으로 저는 앱 컨테이너 내부 또는 외부에서 Win32 API와 관련하여 오버헤드가 없는 상황이 되었으면 합니다. 분명히 우리는 지금 그 시점에 있지 않으며 우리가 거기에 도달할 것이라는 어떤 약속도 할 수 없습니다. 비즈니스 우선 순위 및 우리가 가진 많은 최종 사용자가 있는 Windows와 같은 큰 프로젝트에 대한 계획은 힘들고/힘들어야 하는 복잡한 프로세스입니다. 모든 수준에서 선택. (방해할 수 있는 다양한 기술적 문제는 말할 것도 없고...)

@smaillet-ms

끌어서 놓기 시나리오에 관한 @jtorjo :

1. 파일과 폴더 모두에서 작동합니까?
   많은 앱과 테스트에서 작동해야 하며 그렇지 않은 경우 버그를 신고하세요.
2. .Path에 액세스할 수 있습니까?
   가능성 - 스토리지 항목을 백업할 실제 파일 시스템 경로가 있으면 예입니다. (셸 라이브러리와 같은 것은 실제로 실제 파일 시스템 경로가 없습니다)
3. 지속적입니까(그렇지 않다고 가정)?
   아니요, 앱은 향후 액세스 목록에 추가하여 앱을 영구적으로 만들 수 있습니다.
4. StorageFile/Folder를 계속 사용해야 합니까, 아니면 나중에 .Path에서 다시 만들어야 합니까(2.에 대한 대답이 YES라고 가정)?
   향후 액세스 목록 또는 가장 최근에 사용 목록에 추가해야 합니다. 그렇지 않으면 해당 개체 인스턴스를 통해서만 액세스할 수 있습니다. 해당 인스턴스를 해제하면 액세스 권한이 사라집니다.

잘 들린다. 어느 시점에서 내 앱에서 이것을 구현할 것입니다.

[...] 인덱서 및 스토리지 감지 서비스에는 드라이브에서 세부 정보(파일 크기 등..)를 주기적으로 스캔하는 코드가 포함되어 있으며 사진 및 비디오 파일을 찾는 데 활용됩니다. 앱은 StorageLibrary API 를 사용하여 이러한 위치가 이미 라이브러리에 없는지 확인하고 발견된 경우 사용자에게 추가하라는 메시지를 표시할 수 있습니다.

나는 이것에 반대하는 것이 없지만 이것은 내 앱에 추가 합병증으로 보입니다. 실제로 이것을 사용하는 사람에 대해 들어본 적이 있습니까?

지금 당장은 StorageFolder/File 과 관련하여 모든 종류의 문제를 처리할 수 있는 수천 가지 방법을 찾아야 하며 이것은 추가 방법일 뿐입니다. 개발자인 나에게 다시 한 번 부담을 줍니다.

'FindFirstFileExFromApp - 이것은 있어야 합니다(그리고 실제로 존재합니다) - 확실히 플래그가 지정되어서는 안 됩니다.'
모든 *FromApp API가 앱 컨테이너 앱에서 사용하도록 설계되고 의도된 것에 전적으로 동의합니다. 따라서 도구가 그 중 하나에 플래그를 지정하는 경우 해결해야 하는 버그입니다.

동의.

@smaillet-ms

여러 OS 릴리스에서 스토리지 API의 성능을 개선하기 위해 많은 작업이 수행되었습니다. 이 시점에서 개발자의 과제는 주로 어떤 API를 언제 사용할지 아는 것입니다.

유감스럽게도 이것은 그다지 안심할 수 없을 것 같습니다.

WPF 시대에는 단순히 System.IO를 사용하고 내가 원하는 파일/폴더 쿼리를 미친 듯이 쉬운 방법으로 수행하고 속도에 대해 전혀 걱정하지 않았습니다. 나는 단지 알고 있을 것이다 - 그것은 작동한다. 4000개 파일, 10000개 파일 - 간단하게 작동합니다.

일을 하는 방법에는 여러 가지가 있으며 그 중 많은 것이 주어진 응용 프로그램에 대해 완전히 잘못되었습니다.

API는 애초부터 존재해서는 안 됩니다.

불행히도 "하나의 정답"이란 것은 실제로 응용 프로그램과 파일 시스템에서 얻은 정보로 무엇을 할 것인지에 달려 있기 때문입니다. *FromApp API는 현재 표준 Win32 대응 API에 비해 최고의 성능을 제공합니다.

그것은 확실히 사실입니다. *FromApp API를 사용하기 좋은 클래스(내 시나리오의 경우)로 이미 래핑했지만, 이것은 MS도 수행해야 하는 일입니다. 사용 사례의 98%를 차지할 가능성이 매우 높습니다.

내가 직접 하고 싶지만 시간이 없습니다. 나는 나의 간단한 수업을 행복하게 공유할 수 있고 누군가 거기에서 그것을 가져갈 수 있습니다.

여기에서 지적한 것처럼 썸네일 등과 같은 추가 셸 데이터가 모두 포함되어 있지는 않습니다(캐시에서 사용할 수 없는 경우 실제로 획득하는 데 비용이 많이 듭니다).

동의함 - 이미 별도로 이 작업을 수행하고 있습니다(다른 스레드에서 썸네일 요청) - 이에 대한 쿼리 API는 놀라운 일이 될 것입니다. 기본적으로 썸네일을 대량으로 요청합니다. 그리고 IAsyncEnumerable을 얻을 수 있습니다.

다시 한 번, MS는 이를 위한 간단한 API를 만들 수 있으며, 지금은 각 파일에 대해 .GetThumbnailAsync를 수행하기만 하면 됩니다. 그런 다음 API를 제공하면 나중에 속도를 개선할 수 있습니다.

따라서 앱에서 이름/경로 또는 확장자를 기반으로 관심 있는 파일을 찾아야 하는 경우 *FromApp API를 사용하여 검색할 수 있습니다. 그런 다음 이름을 기반으로 StorageFile을 생성하여 자세한 내용을 검색할 수 있습니다. 중복된 오버헤드가 있지만 이 경우 액세스 확인이 두 번 수행되기 때문입니다.

플러스 측면에서 *FromApp API에는 생성 시간, 마지막 액세스 시간, 마지막 쓰기 시간, 파일 크기와 같은 많은 정보가 이미 있습니다.

하나의 파일만 찾으려고 하는 경우 문제가 되지 않는 경우가 많지만 대규모의 중복에는 비용이 발생할 수 있습니다. Windows.Storage.Search.IndexerOption .OnlyUseIndexerAndOptimizeForIndexedProperties와 함께 Storage WinRT API를 사용하는 경우 정말 빠른 열거를 얻을 수 있습니다. 이 열거형은 주문형 아래에 완전히 실현된 스토리지 항목으로 대체됩니다. 추가 액세스 검사를 포함해야 하는 경로에서. 단점은 사용자가 해당 위치에 대해 인덱서를 비활성화한 경우 작동하지 않는다는 것입니다.

여기에는 몇 가지 단점이 있습니다. 우선 제 테스트에서는 색인이 생성되지 않은 파일보다 빠르지만 그렇게 빠르지는 않았습니다. 나는 그것이 3x-5x 더 빠르다고 생각하지만 여전히 *FromApp보다 약 10x-50x 느립니다. 그것은 미친 듯이 느립니다. 게다가 사용자에게 "모든 파일에 파일 속성 외에 컨텍스트 인덱싱이 포함됨"을 확인하라고 말할 수는 없습니다. 이는 단순히 그의 옵션입니다. 그리고 아마도 많은 사용자가 이를 선택하지 않은 채로 둡니다.

실제로 Windows는 사용된 파일을 자동으로 파악하고 해당 폴더를 색인화해야 합니다. 이는 미디어 파일(비디오/사진/음악)과 문서에 매우 중요할 것입니다.

사진/미디어 유형 앱과 같은 UI를 채우는 경우 BulkAccess 클래스는 가상화 등을 포함하는 UI의 사용 시나리오에 맞춰져 있으므로 아마도 가장 좋은 선택일 것입니다. 따라서 UI에 데이터를 빠르게 제공하고 더 많은 데이터를 공급할 수 있습니다. 사용자가 콘텐츠를 스크롤할 때 필요에 따라

솔직히, 나는 이것이 있는지조차 몰랐습니다. 우리가 이야기하면서 그것을보고 있습니다.
그러나 이것을 올바르게 이해하면 IStorageQuery와 동일한 성능 문제를 겪을 수 있으므로 이것은 약간의 구문상의 설탕에 불과합니다.

그리고 그 성능 문제는 엄청납니다. 파일이 너무 커서 기본적으로 대략 1000개의 파일에 대해 9-10초 후에 첫 번째 파일이 검색됩니다. 즉, 결과를 열거하기 시작하면 아무 것도 하기 전에 9-10초 동안 차단됩니다. FileInformationFactory를 사용하는 것과 동일하다고 가정하고 그 시간 동안 UI가 응답할 것이라고 가정합니다.

WinRT는 큰 표면이며 MS의 단일 팀이 소유하지 않습니다. 각 팀은 각 릴리스에 대한 우선 순위를 평가하고 미리 계획을 게시할 수도 있고 게시하지 않을 수도 있습니다. 개인적으로 저는 앱 컨테이너 내부 또는 외부에서 Win32 API와 관련하여 오버헤드가 없는 상황이 되었으면 합니다.

글쎄요, 우리 중 많은 사람들도 ;) WinRT가 Windows의 큰 부분이고 다른 부분이 다른 팀에 흩어져 있다는 것을 이해합니다.

MS가 WinRT에 대해 가지고 있는 비전을 공개적으로 보지 못하는 것은 우리에게 그다지 위안이 되지 않습니다. 무슨 일이/언제/발생한다면 타임라인이 없는 것.

나에게 파일/폴더를 처리하는 속도는 단순히 가장 중요합니다. 폴더에 있는 파일을 열거하는 것과 같이 간단한 작업을 수행하는 데 시간이 오래 걸릴 수 있는데 어떻게 WinRT/UWP를 신뢰할 수 있습니까? 그리고 "내 Google 검색이 *FromApp API로 실행될 만큼 운이 좋을까?"라는 문제를 개선하는 방법을 알아내십시오.

나는 배은망덕한 사람처럼 보이고 싶지 않습니다. 시간을 내어 이 모든 것을 설명해주셔서 정말 감사합니다. 감사합니다!

@BenJKuhn 누군가(https://docs.microsoft.com/answers/questions/6112/updating-existing-app-with-new-certificate-uwp.html?childToView=25297#comment-25297)가 The 여기에서 "새 인증서" 발행 --> https://aka.ms/AA8bw9v

정말 나쁜 측면에서 -- 나는 이것을 액세스하려고 했고 이 티켓을 볼 수 있는 액세스 권한이 없다고 알려줍니다. 이것은 "피드백 허브"의 신뢰성에 실제로 도움이 되지 않습니다.

MS 스토어 외부에서 사이드로드를 허용하지만 실제로는 불가능에 가까운 이유는 무엇입니까?

사실이 아닙니다. MS Store에 애플리케이션을 업로드할 수 없으며 앱을 설치하는 대체 방법으로 appinstaller를 사용할 수 없습니다. 인증하는 동안 내 앱이 금지되었습니다.
MS 스토어 정책:
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies?redirectedfrom=MSDN#101 -distinct-function--value-accurate-representation

10.1.5
귀하의 앱은 Microsoft Store를 통해서만 소프트웨어를 홍보하거나 배포할 수 있습니다.

내 서버에서 appinstaller 파일을 제거한 후 사용자는 MS Store를 다시 사용하여 내 앱을 설치할 수 있습니다. 나는 규칙을 이해합니다. 심지어 규칙에 대한 이유를 알 수 없습니다. 하지만 스토어와 앱인스톨러(유니그램)나 초콜릿(새로운 MS 터미널)을 통해 배포되는 많은 응용 프로그램을 알고 있을 때 정말 실망스럽습니다.

MS 스토어 외부에서 사이드로드를 허용하지만 실제로는 불가능에 가까운 이유는 무엇입니까?

사실이 아닙니다. MS Store에 애플리케이션을 업로드할 수 없으며 앱을 설치하는 대체 방법으로 appinstaller를 사용할 수 없습니다. 인증하는 동안 내 앱이 금지되었습니다.
MS 스토어 정책:
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies?redirectedfrom=MSDN#101 -distinct-function--value-accurate-representation

나는 우리가 여기서 같은 것에 대해 이야기하고 있는지 확신할 수 없습니다. 이 시대에 저는 MS Store가 필요하거나 원하는 단 하나의 이유를 생각해낼 수 없습니다. 내 문제는 앱을 개발한 다음 MS 스토어 외부에 배포하는 것이 엄청나게 어렵다는 것입니다.