Obrigado por ouvir o feedback da comunidade. Estou muito animado para WinUI 3.0 (Win32 + WinUI + C ++). Parece a estrutura que estávamos esperando! RIP GDI 😉

(Modelo de aplicativo Win32) + (WinUI 3.0 UI) + (linguagem .NET ou C ++)

Portanto, essa seria basicamente a IU UWP, mas sem o ciclo de vida semelhante ao do telefone e a sandbox? Isso parece interessante para aplicativos de desktop, então - vou fazer experiências com isso.

Obrigado pela atualização, e esperançosamente mais atualizações virão conforme o conjunto de recursos inicial do WinUI 3.0 está bloqueado, e quaisquer novos controles ou recursos de controle que foram propostos, que podem torná-lo no WinUI 3.0.

Ah, e a documentação sobre como o WinUI no Desktop funcionará, e será diferente do UWP, WPF e Win32, seria muito útil para evitar a quantidade de perguntas que virão.

Talvez uma boa matriz do que está incluído com qual combinação de frameworks e APIs, junto com os diagramas de arquitetura que obtivemos no Build!

Vocês são incríveis, obrigado por tudo!
A seção xplat fez meu dia, especialmente porque Uno está no radar.

Nosso foco ainda é o Windows 10 e 8.1, mas ouvimos o feedback de que alguns de vocês ainda têm usuários e clientes no Win7 e estaremos avaliando o mercado e as opções ao longo do tempo.

Supondo que esta implantação da estrutura de IU seja projetada com a ideia de portabilidade, pelo menos o suficiente para que seu núcleo de IU (renderização / entrada) possa funcionar em qualquer sistema operacional Windows que suporte .NET Core 3+, quais limitações no Windows 7 haveria ser? Parece que a maioria dos recursos que as pessoas usam na área de trabalho funcionariam apenas e para aqueles especiais / específicos da plataforma que não funcionam, talvez os impeçam de fazer parte do sistema de interface do usuário central e os mantenha em pacotes específicos da plataforma, como (Win10, Win8.1, Win7 Nugets etc).

Além disso, se houvesse um XAML de plataforma cruzada que tivesse a mesma aparência em todos os dispositivos (Win32, Android, iOS e WASM), como você pode fazer com HTML (mas não Xamarin, infelizmente), minha empresa teria entrado nele anos atrás.

Fico feliz que vocês considerem isso uma "maratona (ótimo jogo da Bungie também)". Quanto menos fragmentação no espaço XAML, melhor para todos, e seguir muitos atalhos apenas levará você de volta ao ponto de partida;)

documentação sobre como o WinUI no Desktop funcionará e difere do UWP, WPF e Win32 seria muito útil

Estamos trabalhando nisso e compartilharemos mais conforme isso se desenvolva!

Supondo que esta implantação da estrutura de IU seja projetada com a ideia de portabilidade, pelo menos o suficiente para que seu núcleo de IU (renderização / entrada) possa funcionar em qualquer sistema operacional Windows que suporte .NET Core 3+, quais limitações no Windows 7 haveria ser?

@ zezba9000 WinUI não usa .NET e você não precisa necessariamente usar .NET Core com WinUI: é uma estrutura nativa construída em APIs do sistema operacional e depende de uma nova funcionalidade no Win8 / Win10 que não estava presente no Win7 - em alguns casos, para recursos básicos, não apenas recursos complementares de nível superior, como controles específicos.

documentação sobre como o WinUI no Desktop funcionará e difere do UWP, WPF e Win32 seria muito útil

Estamos trabalhando nisso e compartilharemos mais conforme isso se desenvolva!

Supondo que esta implantação da estrutura de IU seja projetada com a ideia de portabilidade, pelo menos o suficiente para que seu núcleo de IU (renderização / entrada) possa funcionar em qualquer sistema operacional Windows que suporte .NET Core 3+, quais limitações no Windows 7 haveria ser?

@ zezba9000 WinUI não usa .NET e você não precisa necessariamente usar .NET Core com WinUI: é uma estrutura nativa construída em APIs do sistema operacional e depende de uma nova funcionalidade no Win8 / Win10 que não estava presente no Win7 - em alguns casos, para recursos básicos, não apenas recursos complementares de nível superior, como controles específicos.

Para compatibilidade com o Windows 7 - seria necessário que terceiros criassem seu próprio renderizador compatível para o XAML, bem como algum tipo de Shim alternativo para qualquer API de nível de sistema operacional necessária.

No momento, não há ideia se isso é possível - a esperança é que, quando os bits do WinUI forem removidos do sistema operacional, eles sejam colocados no projeto de código aberto de uma forma que permitirá que outras plataformas forneçam algum tipo de componente de compatibilidade. Pense em Xamarin, Uno ou .Net Core com um renderizador personalizado.

é uma estrutura nativa construída em APIs do sistema operacional e depende de novas funcionalidades no Win8 / Win10 que não estavam presentes no Win7 - em alguns casos, para recursos principais

Na minha opinião, o que constitui um "recurso central" não seria algo que depende das especificações do sistema operacional além da renderização e entrada do curso. O que, nesses casos, seriam camadas de abstração que qualquer um pode estender. Em um nível básico, em teoria, um deve ser capaz de renderizar a IU com um renderizador de software personalizado e fazer a entrada com um back-end XInput personalizado com um cursor virtual, se desejado. Se você pode fazer esse tipo de modularidade, você pode fazer praticamente qualquer coisa e estender o suporte da plataforma se torna extremamente fácil (como é feito nos jogos). Você passa um pouco mais de tempo nesta área e, no caminho, tudo exige muito menos esforço. Se o WPF XAML foi projetado dessa forma, ele poderia simplesmente ter sido obtido e usado em aplicativos UWP. Caso contrário, a dívida técnica se tornará um ciclo sem fim.

Coisas como suporte a ícones de bandeja etc podem estar em um pacote "WinUI Windows basic features (Win7-Win10)". Coisas como notificações push podem estar em um pacote "WinUI Windows extended features (Win8-Win10)".

Espero que faça sentido.

@mdtauk , @ zezba9000 é tudo teoricamente possível, e temos muita experiência em abstração de plataforma na equipe. Como com qualquer coisa, tudo se resume a custo, cronograma e benefício esperado 😊

Além dos custos de desenvolvimento e teste (que se estenderiam a áreas potencialmente não óbvias, por exemplo, garantir que tudo funcione com tecnologias assistivas antigas), também temos que considerar o custo de suporte em longos períodos de tempo.

Você espera ter novos clientes no Win7 em 2020+? O feedback e os casos de uso definidos nos ajudam a priorizar.

Além dos custos de desenvolvimento e teste (que se estenderiam a áreas potencialmente não óbvias, por exemplo, garantir que tudo funcione com tecnologias assistivas antigas), também temos que considerar o custo de suporte em longos períodos de tempo.

Você espera ter novos clientes no Win7 em 2020+? O feedback e os casos de uso definidos nos ajudam a priorizar.

@jesbis Não vejo muitos benefícios em adicionar compatibilidade ao Win7 para WinUI 3.0 - Linux, Android, iOS, iPadOS e MacOS, no entanto, pode ser benéfico para fornecer uma solução de plataforma cruzada, que não depende de estruturas de IU nativas.

@mdtauk
@jesbis Não vejo muitos benefícios em adicionar compatibilidade ao Win7 para WinUI 3.0 - Linux, Android, iOS, iPadOS e MacOS, no entanto, pode ser benéfico para fornecer uma solução de plataforma cruzada.

Concorde com isso. Eu apenas adicionaria web-assembly, para mim é ainda mais essencial do que o Linux.

Você espera ter novos clientes no Win7 em 2020+? O feedback e os casos de uso definidos nos ajudam a priorizar.

Não, minha empresa não. Eu estava dando mais um argumento de design em uma área com a qual vi XAML lutar em todas as suas iterações (da minha perspectiva), mas eu entendo perfeitamente por que a MS não gostaria de passar tempo lá. No entanto, seria legal se o WinUI fosse capaz o suficiente para que outras pessoas fizessem esse trabalho se precisassem (o que tende a acontecer, eu percebi) sem entrar na toca do coelho das dependências do Windows, como é o caso do WPF agora.

Para deixar claro o que minha empresa adoraria ver se o suporte ao Android e WASM fosse um pouco mais oficial do que o UNO (e 3 anos atrás). Fazemos software de gerenciamento que rege o estado de uma coleção de computadores locais e configurações de sistema geralmente envolvendo uma grande necessidade de APIs Win32 (UWP nunca funcionaria para nós, mas gostamos da interface do usuário por causa de erros de tempo de compilação, ao contrário dos sistemas de compilação de HTML) e nosso clientes + nós precisam de experiências de interface do usuário Win32 + Android + navegador que tenham uma experiência e sensação uniformes. HTML é apenas um grande problema, pois adiciona abstração e complexidade desnecessárias que, de outra forma, não precisariam estar presentes, já que nossa base de código principal está em C #.

Espero que esse seja um feedback melhor para você.

Além disso, sim, o WASM é o maior alvo que gostaríamos em comparação com qualquer outra plataforma. DE LONGE!!
Uma vez que resolve o nosso problema Android / iOS / móvel, bem como coisas do portal da web.

Obrigado por ouvir o feedback!

Desktop + WASM valerá ouro!

Nossa, obrigado pelo grito, @jesbis! Totalmente inesperado e muito apreciado e respeitado. 👍

A discussão em torno do Windows 7 distrai um pouco, pois a quantidade de esforço (para não mencionar o custo) causaria um atraso significativo no WinUI 3.0. O Windows 7 é o fim da vida útil em janeiro e estamos incentivando todos os clientes a atualizar para o Windows 10. Meus clientes podem não se alinhar com outros aqui, mas mesmo o Windows 8.1 não é uma plataforma de interesse para nós.

Muito feliz com a atualização. Os próximos alvos para WinUI parecem muito brilhantes e promissores! Mesmo a seção Xplat era algo que eu não esperava, mas é muito bem-vindo. Teremos prazer em usar as melhorias, bem como as guloseimas reservadas para o WinUI.

Obrigado à equipe pela transparência.

Gostaria de mencionar a importância do software de linha de negócios para ajudar as pessoas na solução de vários problemas.

Trabalhei um pouco com a ferramenta Lightswitch e tive um ganho significativo no tempo de construção. O desenvolvimento rápido de aplicativos tem sido muito promissor para aplicativos LOB. Mas com a guerra de patentes nos EUA que é levada muito a sério, demorou o produto até ser encerrado.

Sabemos que temos INotifyDataErrorInfo para a próxima entrega. Mas seria maravilhoso se o WinUI tivesse o recurso RAD para entregas futuras como 3.x em diante.

obrigado equipe, não posso esperar pelo dia em que você lápis na webassembly. fará meu dia, ano e década e colocará MS no topo da pilha de tecnologia. WinUI + Xamarin + WASM + .NET => maravilha pura !!

@jesbis Obrigado por esta atualização. Bom trabalho equipe: +1 :. Entendendo que ainda é cedo, quando você acha que veremos o marco do WinUI 3.0 criado e os problemas marcados contra ele?

quando você acha que veremos o marco WinUI 3.0 criado e os problemas marcados contra ele?

@shaggygi Boa pergunta! Eu acabei de criar:

Marco WinUI 3.0

Isso é incrível, pessoal!

Pergunta rápida: Movendo Windows.UI.Composition para Microsoft.UI.Composition, isso está mais perto de 2.2 ou 3.0?
E no prazo para esperar isso, isso levaria 2-3 meses ou mais, quando o 3.0 estiver disponível?

No futuro, ao falar sobre anos (como em "até o final do ano"), você pode ser claro sobre os anos civis e os anos financeiros [da Microsoft].
É fácil ter confusão quando isso não é explicitamente declarado e conheci ocasiões em que isso levou as pessoas a acreditarem que as coisas estão chegando 6 meses antes do planejado.

Movendo Windows.UI.Composition para Microsoft.UI.Composition, isso está mais perto de 2.2 ou 3.0?

@jtorjo será 3,0 (no mínimo). Esperamos incluir uma versão inicial na primeira amostra do 3.0, mas ainda não é 100% garantido.

No futuro, ao falar sobre anos (como em "até o final do ano"), você pode ser claro sobre os anos civis e os anos financeiros [da Microsoft].

@mrlacey obrigado, vou manter isso em mente! Todas as datas que usamos geralmente correspondem ao calendário.

@jesbis Isso é meio triste. Então você está dizendo que é possível que não tenhamos Microsoft.UI.Composition no 3.0?

@jtorjo

Esperamos incluir uma versão inicial na primeira visualização do 3.0 , mas ainda não é 100% garantido

Freqüentemente, há muitos lançamentos de pré-visualização. O .NET Core 3 está no Preview 6, por exemplo.

Nosso plano é incluir as APIs de composição no 3.0.

A parte do framework Xaml será open source antes da parte da composição.

@jesbis Obrigado, parece bom!

Roteiro fantástico, ótimo trabalho!

Como todos aqui, adoro a transparência e estou realmente ansioso para o WinUI 3.0. Para mim, o WinUI 3.0 é a coisa mais emocionante desde o lançamento do WPF em 2006.

Eu também ainda tenho clientes executando o Windows 7, mas acho que o suporte do Windows 10 é o mais importante e eu não gastaria tempo e recursos para suporte ao Win7. A maioria das empresas em que trabalho está mudando para 10. E acho que no final de 2020 a única empresa que conheço que ainda usa o Windows 7 provavelmente será meu dentista. E se ele me pedir para escrever um aplicativo do Windows para ele, vou migrar seus PCs para o Windows 10. :-)

O suporte WASM no futuro seria incrível.

Ontem em uma conferência:

Uma pequena história para mostrar a @jesbis e à equipe que nós, que escrevemos e participamos aqui, somos apenas a ponta do iceberg animado. :-)

Ainda ontem, conversei em uma conferência de desenvolvedores na Alemanha com alguns desenvolvedores .NET e contei a eles sobre o WinUI 3.0, mas eles não sabiam. Eu contei a eles sobre o roteiro e eles disseram:

"Wow isso é incrível".

Uma garota do grupo me perguntou:

"Mas você tem permissão para nos contar tudo isso?"

Eu olhei para ela e os outros, e então aproveitei a chance para uma pausa retórica de

await Task.Delay(3000);

antes de eu dizer

"Claro que sim! Você pode ler tudo isso no GitHub".

Obrigado @jesbis e todos os envolvidos. Ótimos momentos para ser um desenvolvedor Windows ❤️

Espero que os aplicativos originais (como o Word?) Possam fazer uso das camadas do WinUI, e os desenvolvedores ficarão felizes em ver que, "Ei, o WinUI é uma coisa real que pode executar negócios, em vez de um brinquedo".
Se eles já estiverem usando, diga em voz alta.

Acrílico para WPF, Win32 e WinUI Desktop.

Ah, e talvez reconsidere o acrílico apenas na política de janelas ativas.

Sim, se você tiver mais de 1 monitor, ele apenas renderizará em uma janela. Pelo menos em vários monitores ele deve funcionar corretamente ....

Eu estava pensando sobre as implicações da experiência de desenvolvimento de ter dois conjuntos de controles de IU disponíveis em aplicativos UWP - quando teremos acesso aos controles WinUI e controles de IU legados, quando em C # code-behind, IntelliSense, pois ele sempre exigirá que o façamos corretamente escolha de qual namespace o controle deve vir ao invés de Alt + Enter para apenas adicionar using e continuar. Será possível evitar isso de alguma forma?

Assim que o WinUI3 for lançado para os desenvolvedores, os SDKs do Windows 10 devem sugerir a alteração do namespace para projetos que são abertos com um SDK compatível instalado. Tente afastar as pessoas dos namspaces do SO.

Acrílico para WPF, Win32 e WinUI Desktop.

O que eu gostaria de ver primeiro é o MS amadurecendo nas Ilhas Xaml o suficiente para que, por exemplo, o acrílico na barra de título possa ser usado para projetos não UWP baseando sua IU no WinUI (consulte o último parágrafo deste post ). @ marb2000 é provavelmente a pessoa a quem perguntar sobre isso.

@MartinZikmund Queremos evitar esse cenário. Ao usar o WinUI 3, você só deve ter acesso aos controles do pacote. A ideia é que temos tudo o que você precisa com as maiores e mais recentes mudanças.

@MartinZikmund
@LucasHaines

Uma correção deve ser que você pode excluir referências Windows.UI.Xaml.* WinMD da compilação. Agora, os alvos de construção fazem referência apenas ao Unified WinMD aka. Windows.winmd , adicione uma opção nos destinos para também referir WinMDs individuais, dessa forma, podemos incluir ou excluir as referências com base no aplicativo que estamos construindo.

Se for assim, não há necessidade de alterar os namespaces, pois ele se comporta como um .NET dll e pode funcionar com redirecionamentos de assembly para uma versão local dentro do pacote, em vez das fornecidas pelo sistema.

Eu sei que esse método é especificamente para .NET Framework, mas para UAP, deve haver solução para esse tipo de cenário. Eu sei que existe FrameworkDependency no manifesto msix/appx . Podemos usar isso para fornecer ao novo WinUI Windows.* namespaces em vez de Microsoft.* ones.

No lado do desenvolvedor, teríamos menos problemas para atualizar nossos aplicativos, já que estamos apenas alterando a referência e não o código !

Eu prefiro não alterar o namespace de forma alguma!

Benefícios:

1. Não precisa mudar o código para frente e para trás.

2. Uma vez que o código WinUI local tenha sido estabilizado, você pode fundir de volta na plataforma do Windows, para que os aplicativos do sistema e aplicativos LOB possam tirar proveito das novas melhorias, a cada nova versão do Windows.

3. Por um lado, é uma estrutura de sistema altamente estável com alta compatibilidade, como o .NET Framework. E o outro lado é como o .NET Core, com mudanças em um ritmo mais rápido, com todos os benefícios de ambos e nenhum dos problemas.

Acabei de assistir a uma apresentação incrível de Steve Sanderson na IU Blazor + (não html) envolta em um aplicativo nativo de plataforma cruzada. Cerca de 52 minutos de vídeo. Uma visualização obrigatória para os fãs de UWP, WinUI e c #. Estou seriamente impressionado com o blazor !!!

https://youtu.be/uW-Kk7Qpv5U

Uma coisa que esqueci de dizer nessas discussões, que acho importante, é ...
O WinUI 3.0 propriamente dito apresenta melhorias de desempenho? É o mecanismo de renderização XAML sendo apenas desacoplado ou está tendo alterações? Os controles XAML usarão a composição principalmente e, portanto, fora do thread e orientados por dwm como o DirectUI?

O desempenho de alguns controles e o uso de RAM poderiam ser muito melhores, como ListView / GridView = ItemsControl.

Você vê isso no próprio Windows. O Menu Iniciar do Windows 8 (DirectUI) é muito mais fluido do que o Menu Iniciar XAML do Windows 10.
Tente carregar um GridView com informações suficientes, como a página de álbuns do Groove, e as coisas não vão tão bem. Isso é algo que iOS e Android se comportam muito melhor, assim como o winforms, QT.
(WPF é ainda pior do que UWP XAML na minha opinião).

O WinUI 3.0 propriamente dito apresenta melhorias de desempenho? É o mecanismo de renderização XAML sendo apenas desacoplado ou está tendo alterações? Os controles XAML usarão a composição principalmente e, portanto, fora do thread e orientados por dwm como o DirectUI?

O desempenho é definitivamente algo em que queremos continuar investindo, mas eu não esperaria nenhuma melhoria para o 3.0. O esforço inicial do 3.0 concentra-se principalmente em desvincular o Xaml para ser enviado como um pacote NuGet e abrir o código-fonte.

WinUI 3.0 (como UWP Xaml hoje) é construído na camada de composição e executa grande parte de sua renderização e animação off-thread por meio do DWM.

Isso é algo que iOS e Android se comportam muito melhor, assim como o winforms, QT.
(WPF é ainda pior do que UWP XAML na minha opinião).

Geralmente, há uma compensação entre desempenho e flexibilidade / riqueza ao considerar esses cenários. As plataformas baseadas em Xaml (incluindo UWP e WPF) tendem a ter árvores de objetos de IU maiores e mais ricas para cada controle: isso fornece muita flexibilidade para alterar o estilo e UX de qualquer controle, enquanto algumas outras plataformas tendem a ter árvores de objetos muito mais planas que não são tão flexíveis, mas às vezes podem ser carregados mais rápido.

Essa compensação é definitivamente algo em que pensamos e teremos em mente para possíveis mudanças futuras. A flexibilidade extra de modelos de controle Xaml complexos não é necessária na maior parte do tempo, portanto, poderíamos potencialmente simplificar os controles para carregar mais rápido nos casos em que você não precisa de flexibilidade extra.

Espero que a Microsoft possa fornecer um novo comctl32.dll e comdlg32.dll baseado no WinUI 3.0.

Porque a maioria dos aplicativos Win32 terá a experiência de IU moderna e isso ajudará os desenvolvedores a adaptar seus aplicativos à IU moderna.

Muitos desenvolvedores Win32 precisam adaptar várias versões do Windows. Portanto, eles não podem usar o WinUI diretamente hoje. É excelente se a Microsoft puder fornecer um método para ajudá-los a reduzir a carga de trabalho para modernizar a interface do usuário de seus aplicativos.

Além disso, espero que a Microsoft possa fornecer o designer XAML para aplicativos C ++ Win32 que usam WinUI.

Kenji Mouri

@MouriNaruto você pode usar o FileOpenPicker hoje (do Win32).

@MouriNaruto você pode usar o FileOpenPicker hoje (do Win32).

Eu sei, mas espero que todos os controles e caixas de diálogo comuns modernos tragam para o Win32.

@MouriNaruto

Tecnicamente é possível. Mas os desenvolvedores do Windows precisam recriar não apenas os comportamentos exatos das implementações COMCTL e COMDLG mas também os bugs conhecidos e desconhecidos que existem na base de código.

Compatibilidade é nossa inimiga !

Mesmo se eles fizerem isso, no momento em que concluírem, todo software usando essas bibliotecas terá tempo suficiente para migrar para o WinUI! A ironia!! 🤨🤣

@MarkIngramUK

Para sua informação : FileOpenPicker não é um diálogo / controle WinRT nativo. É essencialmente um invólucro de ExplorerFrame que está escrito em DirectUI (desenvolvido pela equipe ATG e baseado em DirectX ) e COM !

Tecnicamente é possível. Mas os desenvolvedores do Windows precisam recriar não apenas os comportamentos exatos das implementações COMCTL e COMDLG, mas também os bugs conhecidos e desconhecidos que existem na base de código.
Compatibilidade é nossa inimiga!
Mesmo se eles fizerem isso, no momento em que concluírem, todo software usando essas bibliotecas terá tempo suficiente para migrar para o WinUI! A ironia!! 🤨🤣

Não acho que seja fácil para muitos projetos migrar para o WinUI sem isso por causa da realidade.

Você disse: "Compatibilidade é nossa inimiga!". Sim, é também um dos motivos das minhas sugestões. A ironia!! 🤨🤣

Eu simplesmente ficaria feliz por uma versão XAML WinUI das caixas de diálogo comuns, mesmo que o WPF e o WinForms tivessem que optar por usar as novas versões.

O destino WinUI 3 parece muito emocionante e estou ansioso por ele. Tenho algumas dúvidas sobre distribuição / implantação, no contexto de um aplicativo Win32 clássico usando WinUI 3

1. Todo aplicativo precisa trazer sua biblioteca WinUI com ele ou o compartilhamento entre aplicativos é possível, talvez até automaticamente por meio de mecanismos do Windows?
2. Será possível vincular estaticamente o WinUI?
3. Digamos que eu tenha que redistribuí-lo, qual o tamanho aproximado do WinUI em MB?

Todo aplicativo precisa trazer sua biblioteca WinUI com ele ou o compartilhamento entre aplicativos é possível, talvez até automaticamente por meio de mecanismos do Windows?

Estamos planejando distribuir principalmente o WinUI 3 por meio do NuGet, que tem mecanismos para armazenar e compartilhar pacotes automaticamente - há mais informações disponíveis aqui:

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

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

Será possível vincular estaticamente o WinUI?

Isso não é algo que estávamos planejando atualmente - você tem em mente um cenário em que isso seria um benefício?

Digamos que eu tenha que redistribuí-lo, qual o tamanho aproximado do WinUI em MB?

Ainda estamos trabalhando em como será o gráfico de dependência final, mas para as partes da IU provavelmente será semelhante aos tamanhos de dll de system32 existentes relevantes (10 de MBs).

Estamos planejando distribuir principalmente o WinUI 3 por meio do NuGet, que tem mecanismos para armazenar em cache e compartilhar pacotes automaticamente

Achei que o nuget é apenas para desenvolvimento ou estou faltando alguma coisa? Pelo que eu sei, os pacotes baseados em nuget devem ser implantados por cada aplicativo individualmente e não podem ser compartilhados. É por isso que existem instaladores dedicados para um tempo de execução dotnet core compartilhado, caso contrário não seria necessário, considerando que os pacotes dotnet core já estão no nuget ...

Você não deve ter que instalar nenhuma ferramenta de desenvolvimento ou SDKs apenas para compartilhar os pacotes de estrutura de IU. WPF e WinForms para .NET Core estavam tendo o mesmo problema e investiram na construção de um pacote compartilhado para que as pessoas não precisem

Em particular, já existem opções de construção no VS para implantação dependente da estrutura e o WinUI deve aproveitá-las para garantir que os pacotes sejam compartilhados. Claro, eles precisam fornecer um pacote compartilhável primeiro.

Para aplicativos fornecidos pela Microsoft Store, o conteúdo do pacote de lançamento também deve ser compartilhado automaticamente na implantação.

Para aplicativos win32 implantados por outros meios, está em nossa lista de tarefas para investigar opções como as que você mencionou 😊

Será possível vincular estaticamente o WinUI?

Isso não é algo que estávamos planejando atualmente - você tem em mente um cenário em que isso seria um benefício?

Acho que preciso esclarecer: será possível usar o WinUI em um EXE vinculado estaticamente (que vincula estaticamente o VC-Runtime)? Suponho que isso não seja um problema por causa do C ++ / WinRT, mas eu só queria ter certeza ...

Digamos que eu tenha que redistribuí-lo, qual o tamanho aproximado do WinUI em MB?

Ainda estamos trabalhando em como será o gráfico de dependência final, mas para as partes da IU provavelmente será semelhante aos tamanhos de dll de system32 existentes relevantes (10 de MBs).

Obrigado pela informação.

Transparência incrível para um empreendimento tão grande, eu gosto muito.

Acho que preciso esclarecer: será possível usar o WinUI em um EXE vinculado estaticamente (que vincula estaticamente o VC-Runtime)? Suponho que isso não seja um problema por causa do C ++ / WinRT, mas eu só queria ter certeza

Isso deveria ser possível (em teoria), mas como @jesbis disse, ainda estamos elaborando a história de como os aplicativos descompactados chegarão à estrutura compartilhada. Podemos ter que ter um instalador redist, como o que o .NET Core está fazendo.

A discussão em torno do Windows 7 distrai um pouco, pois a quantidade de esforço (para não mencionar o custo) causaria um atraso significativo no WinUI 3.0. O Windows 7 é o fim da vida útil em janeiro e estamos incentivando todos os clientes a atualizar para o Windows 10. Meus clientes podem não se alinhar com outros aqui, mas mesmo o Windows 8.1 não é uma plataforma de interesse para nós.

Você está certo. Mas não podemos controlar meu cliente e há mais de 60% do sistema win7 na China. E não podemos abrir mão desse mercado, por isso não podemos usar nenhuma tecnologia que não suporte win7.

Os dados são da baidu, consulte https://tongji.baidu.com/data/os

Mas não podemos controlar meu cliente e há mais de 60% do sistema win7 na China

TBH: Eu ficaria apenas com o .NET Framework 4.8 + WPF se você estiver preso no Win7.

Mas não podemos controlar meu cliente e há mais de 60% do sistema win7 na China

TBH: Eu ficaria apenas com o .NET Framework 4.8 + WPF se você estiver preso no Win7.

Mas o Win7 Sp1 pode instalar o .NET Framework 4.8 e o win7 sem o sp1 não pode instalá-lo.

Requisitos de sistema do .NET Framework |

Se você nem tem o SP1, já passou 6 anos do fim de sua vida.

O suporte para Windows 7 RTM sem service packs terminou em 9 de abril de 2013.

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

Se você deseja suporte ao Windows 7, deve usar uma tecnologia que já suporte o Windows 7 e não esperar que a Microsoft resolva esse problema para você.

@MarkIngramUK Não é que a Microsoft tenha resolvido esse problema para mim, mas não posso oferecer suporte a meus clientes que usam win7 sem sp1. Não consigo controlar nossos clientes para usarem qualquer sistema, mas eles que usarem win7 sem sp1 vão abandonar nosso aplicativo e isso significa que perdemos esse mercado. Mas meus concorrentes que não usam a nova tecnologia podem suportar win7 sem sp1 e meus concorrentes ganharão esse mercado.

É triste, mas é verdade, muitos clientes não se importam com a tecnologia que usamos, mas eles se preocupam com o aplicativo pode ser executado bem em todos os seus dispositivos.

Este é o status quo do meu setor e as conclusões acima podem não ser adequadas para outros setores.

@lindexi, como eu digo, você não pode esperar que uma nova tecnologia seja portada para um sistema operacional que já passou 6 anos do fim de sua vida útil. Se você deseja ter como alvo o sistema operacional antigo, você precisa de tecnologia antiga.

@lindexi Eu acho que se o cliente não quiser usar a tecnologia suportada e preferir algo desatualizado, então ele não pode esperar ter uma IU moderna. Esses dois requisitos são puramente mutuamente exclusivos ...

@MarkIngramUK Sad. Acho que quando posso usar a nova tecnologia de hoje, essa nova tecnologia se tornou uma tecnologia velha.

@lindexi é literalmente o oposto do que está acontecendo. Você não pode chamar a nova tecnologia de “tecnologia antiga” apenas porque ela não está sendo portada para um sistema operacional antigo. Se você quiser suporte para Win7 (sem SP1), use WinForms ou MFC ou algo assim.

@MartinZikmund Você está certo. Na verdade, quase nenhum dos nossos usuários entende a tecnologia de computador, mesmo win7 e win10 não podem dizer. Eles não se importam com a tecnologia que usamos.

@jesbis Eu adoraria sujar as mãos com o novo WinUI usando C ++. Eu tentei o meu melhor usando UWP e C ++ / Cx no passado, mas além do aplicativo PhotoEditor e alguns exemplos, você sempre acabou coçando a cabeça e tentando encontrar uma boa documentação, por exemplo, para vincular XAML a Platform :: Collections e coisas do tipo naquela. Esse foi um dos motivos pelos quais voltei para C # para UWP e Qt para desenvolvimento C ++ no Windows. Por favor, mostre mais amor por C ++.

Em meus clientes, usei um stick USB (PenDrive) com o Windows 10 Media e simplesmente atualizei-o do Windows 7 para o Windows 10 mais recente gratuitamente. Eles obtiveram o benefício de um sistema operacional moderno, com antivírus, atualizações do Windows, Edge WebBrowser e tecnologias de interface de usuário mais antigas, como WinForms, WPF, até as mais recentes, incluindo UWP e além (WinUI). Além disso, em vez de Desligar, configurei o Windows para Hibernar e ensinei os usuários a simplesmente apertar o botão liga / desliga para começar a trabalhar com o PC e pressionar o botão Liga / Desliga ao terminar de usar o PC.
Também coloquei um ISO na Rede, para facilitar a instalação / atualização das máquinas.

E eles têm a vantagem de ter o Candy Crush pré-instalado em seus computadores também!

Opinião

Eu pensei que as implementações de controles do WPF podem ser mescladas no WinUI para suporte a versões antigas do Windows. (Por exemplo, Windows 7.) Mas é muito difícil para a Microsoft tornar isso realidade por causa da política do escritório, lol.

Respostas

@lindexi
Eu sei que existem muitos usuários de versões desatualizadas do Windows na China hoje. Mas acho que é necessário abandonar os usuários do Windows NT 5.x hoje e sei que é difícil.

@MartinZikmund

Acho que se o cliente não quiser usar tecnologia compatível e preferir algo desatualizado, ele não pode esperar ter uma interface de usuário moderna. Esses dois requisitos são puramente mutuamente exclusivos ...

Tanto a interface do usuário moderna quanto o suporte à plataforma antiga são necessários na China se você não quiser que seu trabalho seja servido por uma minoria. Então, um dos meus amigos, um desenvolvedor chinês, portou o Blink e o V8 para o Windows XP sem nenhuma atualização instalada , muitos desenvolvedores o usam para implementar suas experiências de aplicativos modernos. Na China, o requisito mínimo de versão do sistema operacional é igual a uma versão sem nenhuma atualização instalada . Por exemplo, se você sabe que o requisito de versão do sistema operacional de um aplicativo da China é o Windows 7, ele informa que pode usar o aplicativo em "Windows 7 RTM" ou "6.1.7600.16385 (win7_rtm.090713-1255)". Mesmo no mundo Android, muitos aplicativos ainda suportam o Android 4.4 hoje.

É por isso que a maioria dos aplicativos feitos por desenvolvedores não chineses não pode ser a escolha da maioria na China.

PS Podemos usar o Visual Studio 2019 sem nenhuma atualização instalada , com o Windows 10 SDK e o padrão C ++ 17

Nota sobre mim

Na maior parte do tempo, uso a versão estável mais recente do Windows. (Eu uso 10.0.18362 hoje. Estou usando 19H1 e 19H2.) Mas meus projetos Win32 projetados para Windows Vista RTM sem nenhuma atualização instalada e meus projetos UWP projetados para Windows 10, versão 1703 sem nenhuma atualização instalada ou posterior porque o condicional O suporte XAML é introduzido no RS2. (Eu adoro XAML condicional. Por que ele não existe no Windows 10 Build 14393?)

Kenji Mouri

Por favor, considere remover o lacre de todas as classes de controle do WinUI 3.0!

Pelo que entendi, a Microsoft decidiu lacrar todas as classes de controle UWP, porque JavaScript (que não conhece herança) causava problemas quando usado com classes herdadas. Agora que JS / HTML está obsoleto, não há mais necessidade da nova estrutura de IU ainda selar todas as classes. O cancelamento da reserva tornaria muito mais fácil personalizar os controles UWP, como sempre foi possível no WPF. Também ajudaria muito ao escrever controles de lista de virtualização personalizados ou painéis, ter uma classe base de virtualização não lacrada para herdar. Nem C #, nem C ++ / CX ou C ++ / WinRT têm problemas com herança. Foi apenas a falha chamada JS / HTML que nos obrigou a isso.

Portanto, remova essa restrição desnecessária ao criar o WinUI 3.0.

@gisfromscratch obrigado pelo feedback! Definitivamente, queremos oferecer suporte ao desenvolvimento C ++ (especificamente com C ++ / WinRT).

O que tornaria mais fácil usar C ++? Você tentou C ++ / WinRT em vez de CX?

Mais aplicativos de amostra ajudariam?

Você mencionou que era difícil encontrar documentação sobre vinculação: havia algum outro recurso específico que precisa de melhor documentação?

Por favor, considere remover o lacre de todas as classes de controle do WinUI 3.0!

@lukasf, isso é algo que provavelmente faremos 🙂 Há alguma discussão relacionada em andamento no # 780

@jesbis Tenho que sujar muito mais as mãos usando o C ++ / WinRT. Acabei de seguir o aplicativo de exemplo Photo Editor C ++ / WinRT . Mas quando você lê os links fornecidos, como Data binding em profundidade, você acaba em muitos fragmentos de C # e apenas algumas notas colaterais como "Para C ++ / WinRT, qualquer classe de tempo de execução que você declara em seu aplicativo que deriva de uma classe base é conhecido como uma classe combinável. E há restrições em torno das classes combináveis… ". Esta página tem como alvo 95% C # e apenas 5% C ++.

@gisfromscratch obrigado! Manteremos isso em mente enquanto trabalhamos na atualização dos documentos do WinUI 3.

Se ajudar, a página de ligação de dados que você mencionou também tem links para algumas páginas separadas especificamente sobre ligação de dados com C ++ / WinRT, por exemplo:

Controles XAML;

Controles de itens XAML;

Há vários outros tópicos específicos de C ++ / WinRT nessa seção também.

Obrigado por seus excelentes trabalhos! Estou muito feliz em ver que a Ilha Xaml foi removida do WinUi 3.0.
Btw: Eu só me pergunto se a implementação de baixo nível de projeção de componente WinRT parece ter grande impacto no desempenho do projeto .NET UWP tanto em tempo de compilação quanto em tempo de execução. Como o WinUi 3.0 está completamente desacoplado do UWP, espero que possa haver alguma melhoria na implementação de interoperabilidade de linguagem.

@zenjia XAML Islands não foi removido do WinUI 3. WinUI 3 conterá as APIs que permitem que aplicativos WPF / WinForms / MFC hospedem controles WinUI 3.

Tenho tentado acompanhar o progresso no WinUI. Eu tentei escrever aplicativos UWP no passado com C #, mas descobri que era uma batalha difícil. Mas estou ansioso para tentar novamente após o winui 3.0.

Eu tenho dúvidas sobre o roteiro winui. Aqui estão quatro. Desculpe se eles foram cobertos em outro lugar. Não encontrei as respostas, apesar de muita pesquisa ... deixe-me saber se existe um fórum melhor para fazer esse tipo de pergunta.

• Os wrappers .net para os controles nativos também serão de código aberto? Não está claro se este é o github repro responsável pelo lado .Net do winui, considerando que o único código c # que pareço encontrar é para testes automatizados. Estou procurando coisas como Microsoft.UI.Xaml.UIElement, mas não consigo encontrar esse código em qualquer lugar.

• Quando chegarmos ao lançamento do winui 3.0, o appmodel UWP e o appmodel win32 estarão executando o mesmo tempo de execução .Net Core? Eu nunca descobri qual versão do núcleo .Net é usada por aplicativos UWP. Imagino que seja algo integrado ao próprio Windows e que os SDKs do Windows 10 estejam permitindo que o VS 2019 direcione a versão correta do núcleo .Net que está disponível em UWP.

• Uma pergunta sobre as ilhas Xaml. Existe alguma chance de que WPF e UWP possam compartilhar o mesmo espaço aéreo? Não estou ansioso para ter que lidar com problemas de espaço aéreo como fizemos entre winforms e WPF. Dado que o WPF e o UWP são ambos construídos no Direct-X, seria incrível se eles pudessem compartilhar pixels um com o outro. Por exemplo, se eu tivesse um menu de bastidores em uma faixa de opções (em WPF) que precisaria se sobrepor a uma ilha xaml UWP, seria maravilhoso se isso pudesse acontecer perfeitamente. Não parece que eu deveria ter que pular toneladas de aros para algo assim. ... Lembro que nos primeiros dias do WPF, eles tentaram resolver problemas de espaço aéreo para aplicativos clientes que queriam usar o controle de winforms "WebBrowser". Eles fizeram um teste de um recurso do navegador da web chamado "WebBrowser.CompositionMode" e era para permitir que o WebBrowser funcionasse bem com o WPF. ... Mas acho que essa estratégia acabou sendo abandonada. Talvez a interoperabilidade entre UWP e WPF possa ser tão perfeita que eles possam até mesmo compartilhar pixels entre si (ao contrário de WinForms e WPF). Uma vantagem potencial disso seria permitir que o WPF aprimorasse a funcionalidade de um controle UWP. Por exemplo, o WPF poderia sobrepor uma ilha xaml com visuais adicionais de uma forma análoga a uma camada de adorno. Isso pode ser útil em caso de aperto.

• Alguma chance de um aplicativo WPF com ilhas xaml (digamos, 50% WPF e 50% WINUI) ser compilado nativamente para ARM64 algum dia? A segmentação de ARM é possível com aplicativos que são 100% UWP, e seria bom se as dependências do WPF não nos obrigassem a abandonar nossa segmentação ARM64 nativa. (A alternativa seria executar o aplicativo em emulação x86 - mas isso é mais lento e limita a memória disponível que pode ser usada).

Esperançosamente, todas essas questões são relevantes para o roteiro da winui. Qualquer conselho seria apreciado.

Os wrappers .net para os controles nativos também serão de código aberto? Não está claro se este é o github repro responsável pelo lado .Net do winui, considerando que o único código c # que pareço encontrar é para testes automatizados. Estou procurando coisas como Microsoft.UI.Xaml.UIElement, mas não consigo encontrar esse código em qualquer lugar.

UIElement não está no WinUI 2, portanto, não está atualmente no repo. Estará no WinUI 3, que ainda não foi lançado ou de código aberto, mas estamos trabalhando nisso!

Você pode ver exemplos no repositório de outros controles nativos expostos ao .NET por meio de projeções WinRT, por exemplo, os controles WinUI 2.2 documentados aqui . Eles geralmente não requerem arquivos de wrapper por idioma preexistentes, e é por isso que você não está encontrando arquivos .cs no repo.

@ marb2000 poderia comentar melhor as questões sobre ilhas / desktop.

P: _O WinUI 3 UWP e Desktop usarão o mesmo tempo de execução .NET? _
R: Sim, este é o plano. UWP e Desktop usarão .NET Core 3. Bibliotecas WinRT gerenciadas usarão .NET Core 3 em vez de .NET Native.

P: _WPF e UWP compartilharão o mesmo espaço aéreo? _
R: Embora WPF e WinUI (e XAML UWP) pareçam semelhantes, eles não são. WPF usa DirectX9 e WinUI / XAML UWP usa Windows.UI.Composition para as necessidades de composição, renderização e animação do XAML (além de uma versão moderna do DirectX11). Infelizmente, isso faz com que a interoperabilidade seja muito complicada. Sua proposta sobre adornos WPF é interessante. Em teoria, o adotante pode criar um pop-up para colocar o conteúdo WinUI / XAML sobre o conteúdo WPF. Ou pode informar para a árvore visual do WPF que um re-layout é necessário, mas tudo baseado em HWnds.
@dbeavon Esta é uma boa proposta, você pode criar uma solicitação de recurso para isso?

P: _Um aplicativo WPF com ilhas Xaml compilará para ARM64? _
R: Se o .NET Core 3 para Windows for compatível com ARM64, com certeza. Hoje ele suporta ARM32 no Windows. No entanto, no Linux suporta ARM64. Acho que também está no roteiro do .NET Core dar suporte ao ARM64 no Windows. Apesar de AFAIN, ainda não há data. @richlander , alguma novidade?

@ marb2000

P: O WPF e o UWP compartilharão o mesmo espaço aéreo?

A UWP pode usar Windows.UI.Composition para criar uma camada que pode obter a renderização de um bitmap DirectX? E então o WPF renderiza as janelas nesta camada como win2d. Talvez ele possa compartilhar o mesmo espaço aéreo. Mas é difícil fazer o WPF renderizar em uma camada.

@lindexi Acho que pode ser o paraíso: D

A UWP pode usar Windows.UI.Composition para criar uma camada que pode obter a renderização de um bitmap DirectX?

UWP Xaml tem várias maneiras de renderizar bitmaps DirectX ou cadeias de troca em Xaml e combiná-los com Windows.UI.Composition para que eles compartilhem o mesmo espaço aéreo, incluindo SurfaceImageSource , VirtualSurfaceImageSource e SwapChainPanel - mais informações estão disponíveis aqui:

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

Você também pode inserir um visual Windows.UI.Composition em uma árvore de IU UWP Xaml e desenhar conteúdo DirectX nela, por exemplo, usando ICompositorInterop , ICompositionDrawingSurfaceInterop e ICompositionGraphicsDeviceInterop conforme descrito aqui:

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

Essas abordagens devem funcionar da mesma forma com o WinUI.

Um aplicativo de área de trabalho UWP será capaz de fazer referência a uma DLL WPF / WinForm e abrir uma janela WPF / WinFrom? Isso me permitiria migrar gradualmente.

@ marb2000 - .NET Core para Windows ARM64 está em nosso roadmap. Estou trabalhando em um plano para isso agora.

Com o WinUI 3.0, será possível compilar o win2d em cima dele?
(assim, desacoplando-o do UWP)
Se sim, isso seria incrivelmente incrível!

Ainda estamos trabalhando em detalhes sobre a integração do DirectX, mas esperamos que seja possível atualizar o Win2D para usar classes base WinUI em vez de classes base UWP Xaml.

dedos cruzados: D

desculpe se isso está fora do tópico: relatórios de bug no UWP - devo adicionar um problema em https://github.com/microsoft/microsoft-ui-xaml/ ou em outro lugar?

desculpe se isso está fora do tópico: relatórios de bug no UWP - devo adicionar um problema em https://github.com/microsoft/microsoft-ui-xaml/ ou em outro lugar?

@jtorjo ótima pergunta! Este repo é o melhor local para registrar qualquer problema relacionado a:

• as APIs da estrutura de IU UWP (por exemplo, Windows.UI.Xaml)
• Design fluente
• WinUI

Em geral, deve haver um link "Enviar comentários sobre este produto" na parte inferior da maioria das páginas de documentação em docs.microsoft.com que informará a melhor maneira de fornecer comentários sobre um recurso específico ou API.

Para a maioria dos aspectos da UWP além do acima, isso será para registrar bugs na categoria Developer Platform no Feedback Hub, que tem várias subcategorias relevantes.

O WinUI 3 incluirá o controle SemanticZoom UWP? Acho que é o controle mais legal de todos eles.

@jesbis Obrigado! Acabei de postar uma discussão sobre System.IO

Mesmo a Microsoft não abandona o suporte do Windows 7 para o Office, por que o WinUI 3 faria? Quer dizer, quase todos os softwares sérios têm suporte para Windows 7 (Photoshop, Office, Visual Studio 2019, VSCode, ...) Se WinUI não oferece suporte para Windows 7 ...

Mesmo a Microsoft não abandona o suporte do Windows 7 para o Office, por que o WinUI 3 faria? Quer dizer, quase todos os softwares sérios têm suporte para Windows 7 (Photoshop, Office, Visual Studio 2019, VSCode, ...) Se WinUI não oferece suporte para Windows 7 ...

O Office provavelmente deixará de oferecer suporte em breve, já que o suporte da Microsoft para o Windows 7 terminará muito em breve. Mas é construído sobre uma base de código que já oferece suporte ao Windows 7.

O WinUI foi desenvolvido com base no Windows 10 e, portanto, precisaria ser retransportado para o Windows 7. O esforço para fazer isso não faz sentido com o sistema operacional entrando no fim da vida e, portanto, as pessoas terão que atualizar para o Windows 10.

P: O WinUI 3 UWP e Desktop usarão o mesmo tempo de execução .NET?
R: Sim, este é o plano. UWP e Desktop usarão .NET Core 3. Bibliotecas WinRT gerenciadas usarão .NET Core 3 em vez de .NET Native.
P: O WPF e o UWP compartilharão o mesmo espaço aéreo?
R: Embora WPF e WinUI (e XAML UWP) pareçam semelhantes, eles não são. WPF usa DirectX9 e WinUI / XAML UWP usa Windows.UI.Composition para as necessidades de composição, renderização e animação do XAML (além de uma versão moderna do DirectX11). Infelizmente, isso faz com que a interoperabilidade seja muito complicada. Sua proposta sobre adornos WPF é interessante. Em teoria, o adotante pode criar um pop-up para colocar o conteúdo WinUI / XAML sobre o conteúdo WPF. Ou pode informar para a árvore visual do WPF que um re-layout é necessário, mas tudo baseado em HWnds.
@dbeavon Esta é uma boa proposta, você pode criar uma solicitação de recurso para isso?
P: Um aplicativo WPF com Ilhas Xaml compilará para ARM64?
R: Se o .NET Core 3 para Windows for compatível com ARM64, com certeza. Hoje ele suporta ARM32 no Windows. No entanto, no Linux suporta ARM64. Acho que também está no roteiro do .NET Core dar suporte ao ARM64 no Windows. Apesar de AFAIN, ainda não há data. @richlander , alguma novidade?

Então, estamos nos livrando da sandbox UWP? O que, por sua vez, implica que o UWP em sua forma atual também vai desaparecer e, com ele, a caixa de areia protegida da App Store como a conhecemos?

Então, estamos nos livrando da sandbox UWP? O que, por sua vez, implica que o UWP em sua forma atual também vai desaparecer e, com ele, a caixa de areia protegida da App Store como a conhecemos?

livrar-se da sandbox UWP seria incrivelmente incrível!

Isso definitivamente não significa que a UWP será desativada. A Plataforma Universal do Windows é a única maneira de construir nativamente para todo o espectro de dispositivos Windows (PC, Xbox, HoloLens, etc.) e é onde o Windows está concentrando seus investimentos em plataforma nativa. RE: sandboxing em particular: o isolamento do appcontainer continua a fornecer muitos benefícios importantes para aplicativos e usuários de aplicativos UWP e de desktop.

As principais mudanças são:

• estamos aumentando o escopo da plataforma UX (ou seja, WinUI) para que também possa ser usada com um modelo de aplicativo de desktop (win32)
• estamos separando o WinUI do Windows para que possamos atualizá-lo com mais frequência, tornar novos recursos compatíveis com versões anteriores e abri-lo mais facilmente

Isso significa que, para novos aplicativos, você poderá escolher entre UWP e modelos de aplicativos de desktop, dependendo do que fizer sentido para o seu aplicativo, e se você tiver aplicativos de desktop existentes (por exemplo, WPF, WinForms, MFC), poderá atualizá-los incrementalmente com Funcionalidade WinUI usando ilhas Xaml.

Então, estamos nos livrando da sandbox UWP? O que, por sua vez, implica que o UWP em sua forma atual também vai desaparecer e, com ele, a caixa de areia protegida da App Store como a conhecemos?

UWP será uma das opções para construir um aplicativo WinUI 3.0. Usar o UWP permitirá que seu aplicativo seja executado no Xbox, Hololens, etc.

Mas você também pode construir um aplicativo Win32 com WinUI 3.0 e acessar APIs UWP - mas onde seu aplicativo pode ser executado será mais limitado.

@mdtauk @jesbis Sou totalmente a favor da UWP, mas no momento:

1. os tempos de compilação são incrivelmente lentos! (basicamente, 6 vezes mais lento que o WPF - estou usando a versão alvo build 1809 - build 17783)
2. Eu sei que a API de enumeração de arquivo StorageFolder não faz parte da UWP, mas é incrivelmente lenta. A sandbox UWP (pelo menos no Windows Desktop) está mais prejudicando do que ajudando.
3. Claro, a programação assíncrona é divertida, mas em UWP, quando ocorre uma exceção, ela é de alguma forma devorada pelo código UWP e, posteriormente, é interrompida no depurador, com todo o contexto da pilha perdido. Às vezes, tenho o contexto da pilha dentro da própria exceção lançada, mas nem sempre.
4. A criação de perfil do código UWP é quase impossível. O dotTrace do evento é interrompido instantaneamente ao tentar fazê-lo.

(Levei mais de um mês para portar meu código de WPF para UWP, já que eu preciso insanamente do win2d, então não há como evitar UWP.)

@mdtauk @jesbis Sou totalmente a favor da UWP, mas no momento:

1. os tempos de compilação são incrivelmente lentos! (basicamente, 6 vezes mais lento que o WPF - estou usando a versão alvo build 1809 - build 17783)
2. Eu sei que a API de enumeração de arquivo StorageFolder não faz parte da UWP, mas é incrivelmente lenta. A sandbox UWP (pelo menos no Windows Desktop) está mais prejudicando do que ajudando.
3. Claro, a programação assíncrona é divertida, mas em UWP, quando ocorre uma exceção, ela é de alguma forma devorada pelo código UWP e, posteriormente, é interrompida no depurador, com todo o contexto da pilha perdido. Às vezes, tenho o contexto da pilha dentro da própria exceção lançada, mas nem sempre.
4. A criação de perfil do código UWP é quase impossível. O dotTrace do evento é interrompido instantaneamente ao tentar fazê-lo.

(Levei mais de um mês para portar meu código de WPF para UWP, já que eu preciso insanamente do win2d, então não há como evitar UWP.)

Seria útil postar neste tópico # 1517 e espero que você possa incluir o nome de alguém da equipe do SDK

@jtorjo

os tempos de compilação são incrivelmente lentos! (basicamente, 6 vezes mais lento que o WPF

Você está usando C ++ / WinRT? Se sim, você está usando cabeçalhos pré-compilados?

@mdtauk acabou de postar lá

@MarkIngramUK É código c #

Encerramento - direcione o roteiro e o feedback alfa para: # 1531

No momento, não há ideia se isso é possível - a esperança é que, quando os bits do WinUI forem removidos do sistema operacional, eles sejam colocados no projeto de código aberto de uma forma que permitirá que outras plataformas forneçam algum tipo de componente de compatibilidade. Pense em Xamarin, Uno ou .Net Core com um renderizador personalizado.

Isso está realmente no roteiro ou foi apenas uma suposição?

@mdtauk , @ zezba9000 é tudo teoricamente possível, e temos muita experiência em abstração de plataforma na equipe. Como com qualquer coisa, tudo se resume a custo, cronograma e benefício esperado 😊

Apenas talvez abstraí-lo de uma forma que tornasse possível para um terceiro fazê-lo funcionar no Android ou iOS seria enorme. Tenho certeza que a comunidade pode fazer isso. Eu definitivamente contribuiria para isso.

@andreinitescu Desculpe pelo discurso e reclamações, mas apenas meus pensamentos pelo que entendi: Embora eu use o WinUI 3 para substituir o WPF para Windows / Win32 apenas coisas ... Porque o WinUI no Windows usa uma API de renderização do Windows apenas e não um agnóstico primeiro, WinUI parece depender de terceiros para reimplementar / fragmentar (ugg) WinUI em outras plataformas (como o UNO proj, que é legal, mas como Mono para .NET é uma fragmentação desnecessária e que desperdiça tempo se as coisas fossem apenas projetado da maneira certa para começar). Em vez de usar um portátil como o Skia, ou criar um MS. Também não entendo a necessidade de oferecer suporte a 1% das pessoas que não usarão C # com WinUI, tornando o C # um alvo de segunda classe em certo sentido e, mais importante, fazendo com que o tempo de desenvolvimento demore muito mais. Assim como o Android usa Java + pós-AOT para muitos aplicativos principais, o Windows deve usar C # + pré-AOT. Porque economiza tempo. Afinal, 70% dos bugs que usam C ++ estão usando ptrs desalocados.

A falta de comunicação entre os grupos em uma empresa para os casos de uso de longo prazo, quando se tornará cada vez mais um problema quando eles lançarem seu tipo de sistema operacional Android para plataformas móveis (que pretendo usar) e mais pessoas quiserem utilizá-lo com as ferramentas do MS ... sinto que, de certa forma, só vai ser outra situação parecida com o WinPhone7. Windows, como um termo, não deveria mais estar tão ligado ao kernel WinNT. Um ecossistema é mais do que uma única plataforma ou estrutura de uma empresa.

A má MS não pode / não vai fazer o que a Apple fez quase 20 anos atrás com a mudança do OS9 para o OSX. Com isso, você remove o band-aid mudando para um kernel UNIX / LINUX, MAS tendo um emulador / simulador embutido no sistema operacional para software legado pelos próximos 5-10 anos enquanto as pessoas migram software e ferramentas de desenvolvimento para rodar nativamente. (Pense o que quiser com isso, mas eu posso sonhar)