Provavelmente algo distante, mas o Blend precisa ser revisado e precisa de um fluxo de trabalho focado no design.

O designer XAML precisa ser robusto e poderoso.

Alguma maneira de visualizar a estrutura em camadas da página / janela, especialmente importante com controles elevados.

Maneiras de visualizar os elementos da IU fora de uma página, como um controle / modelo individual.

Exibir personalizações de controle feitas para CoreOS, "Surface Phone", Surface Hub, Xbox, HoloLens, tudo dentro do designer.

Designers combinados para XAML misturados com WinForms, WPF, MFC e todos os outros Frameworks com os quais o WinUI Desktop funcionará.

Boas maneiras de importar e exportar XAML, para que os designers possam trabalhar no Blend isolados do aplicativo principal e, em seguida, entregá-los às equipes de desenvolvimento para trazerem para o aplicativo.

Melhor visualização e listagem dos recursos do sistema, bem como ótimas maneiras de extrair esses recursos globais que podem ter um estilo leve para substituir os padrões, e a superfície de design reflete essas alterações em tempo real.

Melhores maneiras de testar diferentes escalas de DPI com aplicativos envolvendo WinForms, MFC etc.

Modelos para novos controles, dicionários de recursos de tema personalizados, integre o Fluent Theme Editor, modelos para combinações de aplicativos compatíveis (Win32 MFC com Xaml UI, etc).

Modelos para pontos de integração de shell, como seletores de arquivos, menus desdobráveis ​​da bandeja de tarefas.

Esses são apenas alguns pensamentos ...

Meus pensamentos são os seguintes:

1. MSIX é muito bom, mas eu ainda uso o bom e velho MSI para instalar aplicativos mais complexos que requerem recursos que o MSIX não suporta. Também estou desconfiado de usar o MSIX por causa do alto custo dos certificados Authenticode necessários. (Posso facilmente assinar meu código com um certificado autoassinado, que acredito ser tão seguro quanto um que comprei de uma empresa, mas o Windows não o carrega. O Windows aceitará de bom grado um arquivo MSI autoassinado, no entanto .) Contanto que eu possa usar o WinUI 3 a partir de um aplicativo baseado em MSI, estou feliz.
2. Um designer XAML melhor seria muito apreciado, mas não preciso da complexidade adicional de integrar os designers WinUI XAML e WinForms / WPF em um. Estou perfeitamente bem em alternar entre as diferentes guias no VS.
3. Como comentei anteriormente , desacoplar o compilador XBF dos sistemas de projeto C # e Visual Basic seria muito útil. (Seria ainda melhor se o código-fonte do compilador XBF, ou documentação suficiente para recriá-lo, fosse lançado, mas não sei a probabilidade de isso acontecer.)
4. Melhor suporte para C ++ / WinRT e MIDL 3 no sistema de projetos C ++. Atualmente, o suporte do projeto para usar C ++ / WinRT é frágil e desajeitado. (Por exemplo, se você alterar o namespace no arquivo IDL - o que geralmente é necessário se houver um ponto no nome do projeto que você deseja usar em namespaces, já que o modelo os converte em sublinhados automaticamente - seu projeto não conseguirá compilar , e corrigir o problema em minha experiência requer mover os arquivos *.h e *.cpp lado, regenerando-os do zero, copiando o código e, em seguida, descarregando e editando o arquivo vcxproj para corrigir o aninhamento.) Por mais que eu queira usar algo mais moderno e flexível do que o vcxproj, não posso fazer isso devido à forte dependência que o compilador XBF tem dele.

Se algo mais surgir, com certeza postarei aqui. Obrigado!

1. O que estou me perguntando aqui é ... Bem, vou precisar usar o prefixo de namespace como < winui: Listview ou < controls: listview ou o que quer que os desenvolvedores decidam? Acho que seria muito melhor, se possível, usar a mesma experiência de agora, apenas Prefixo é bom e incrível para apenas alguns controles. Mas quando você começa a usar em todos os lugares, isso torna a leitura de XAML um pesadelo e muito.
   Não faz sentido usar um prefixo de namespace, pois não será possível usar Windows.UI.Xaml.Controls e como WinUI será a escolha padrão.

2. No momento, nem mesmo uso o designer XAML. Eu literalmente desabilito nas configurações. XAML Designer é lento e precisa de um suporte melhor. Era bom para WPF, mas não UWP, especialmente se você quiser fazer design responsivo, lidar com páginas, mostrar dados, etc.
   Este é provavelmente um feedback para um futuro distante, mas acho que é um bom feedback para olhar. O designer WPF é muito mais rápido.
   Isso é por causa da sandbox ou o quê?

3. Seria interessante uma ferramenta para fazer uma migração. Especialmente porque pode ter alguns problemas de compatibilidade com controles atualizados do WinUI 3.0, como ScrollViewer. Portanto, se houver uma ferramenta, ela precisará mostrar pelo menos possíveis avisos sobre esses controles atualizados / reescritos.

1. Precisamos de um editor de código xaml robusto com IntelliSense separado do designer.
   Na maioria das vezes, estou apenas escrevendo código xaml como C #. Atualmente, o editor de código é lento e frágil, explicado em meu comentário anterior . A experiência do IntelliSense também é bastante simples. Nenhuma informação rápida de documentação, nenhuma renomeação de membro.
2. O suporte de dados de design para x:Bind pode ser bem difícil, pois estou escrevendo auxiliares complexos em associações de função. Mas as coisas podem ser melhores se os funcionais integrados do xaml puderem substituir alguns auxiliares.
3. Quero combinações muito mais gratuitas de modelo de embalagem para minhas aplicações. Pode estar fora do assunto, mas não consigo encontrar nenhum lugar para enviar um feedback para a equipe de modelos de aplicativos.

TL; DR Eu quero um modelo de aplicativo que suporte a coexistência de instâncias arbitrárias . Mesmo a mesma versão pode ser executada com dados de diferença / conjunto de opções, como colmeias do Visual Studio. Atualmente, a única solução parece ser xcopy.

Alguém pode me dizer como desmontar isso?

Primeiro, também estou usando o aplicativo que estou desenvolvendo diariamente (e uso >> debug na maioria dos dias). Portanto, fazer o dev build coexistir com o estável vai me ajudar muito. Atualmente tenho que aumentar o número da versão, empacotar um msix de depuração, atualizar a versão do pacote instalado para depurar.
Durante as diferentes fases de depuração, desejarei recursos diferentes. Para dados complexos do mundo real, quero que a instância de depuração compartilhe os dados com uma instância estável. No entanto, para dados falsos arbitrários, quero isolamento. Teoricamente, isso é resolvido acessando os dados usando o seletor de pasta, mas é uma pena que o SQLite em UWP não ofereça suporte a isso e não haja nenhum outro mecanismo ACID embutido que eu conheça.

Ah, e outra coisa. Eu realmente, _realmente_ apreciaria se algo pudesse ser feito sobre como vcxproj requer o uso de packages.config para referências de pacotes NuGet. WinUI é distribuído como um pacote NuGet, assim como C ++ / WinRT e outros componentes principais. Eu realmente não gosto de usar packages.config. PackageReference é muito mais eficiente (e não resulta em uma compilação interrompida se você mover o vcxproj para um diretório diferente). Ele realmente funciona quando usado a partir de um vcxproj, desde que o destino Restore seja executado no momento apropriado. (Isso ocorre porque os destinos vcxproj importam indiretamente o mecanismo de restauração PackageReference para projetos C # não SDK.) Eu escrevi um conjunto de destinos que executam automaticamente o destino Restore quando o conjunto de itens PackageReference mudou, pois o VS não fará isso em si (ainda). Infelizmente, o sistema NuGet não sabe nada sobre isso e, como tal, tenta adicionar um arquivo packages.config quando adiciono um modelo de arquivo C ++ / WinRT. Isso causa todos os tipos de confusão, resultando em uma exceção sendo lançada e um arquivo de projeto corrompido. Não tenho certeza da melhor forma de resolver isso, mas eu realmente apreciaria se pudesse pelo menos ser examinado antes do WinUI 3 ser lançado. Obrigado!

Seria bom se o WinUI suportasse o novo SDK do projeto - Microsoft.NET.Sdk ou MSBuild.Sdk.Extras .
Arquivos csproj de estilo antigo são difíceis de manter. E não podemos usar vários TargetFrameworks com ele, o que pode ser útil para a migração para WinUI.

Por que não há suporte para F #?

A funcionalidade do Azure DevOps e do Visual Studio App Center deve ser discutida aqui?

Como @vitorgrs , prefiro controles nativos sem prefixo de namespace, pois adiciona "ruído" ao código. E ajuda ver quais são controles nativos e quais são de terceiros.

Uma ferramenta de migração seria legal, é claro. Se funcionar com os grandes fornecedores terceirizados (Telerik, DevExpress, ...), isso já seria uma grande coisa.

Modelos

Há interesse / necessidade de que as versões anteriores dos modelos UWP XAML permaneçam no novo fluxo de projeto do VS?

Da minha parte, não há necessidade de manter os modelos. Mas será que o UWP tem um controle que não está no WinUI? Se isso pudesse acontecer, então esse poderia ser um motivo válido para construir um aplicativo UWP tradicional e migrá-lo para WinUI quando o controle necessário estiver lá. Então, o modelo pode ser necessário.

Talvez também seja confuso para os desenvolvedores se você construiu um aplicativo e não pode mais criá-lo com a versão mais recente do Visual Studio.

Mas, pessoalmente, não tenho interesse em manter os modelos

Como podemos ajudá-lo a ser mais eficiente ou bem-sucedido em relação aos modelos e componentes do Visual Studio?

Para mim, isso parece ótimo para UWP. Agora eu quero ver o mesmo para Win32. :)

Este passo a passo é útil e você gostaria de ver mais disso à medida que os cenários tomam forma?

Sim definitivamente. Este passo a passo é muito útil para entender como o futuro pode e deve ser. Eu gostaria de ver mais disso.

Migração

Seria benéfico se fornecêssemos uma ferramenta de migração que automatizasse as etapas 1-3?

Com certeza. Talvez uma pequena extensão do Visual Studio seja uma ótima opção para essa migração. Também posso pensar em algo como um "Analisador de compatibilidade WinUI" que mostra o que pode ser migrado e o que não pode. Algo semelhante ao analisador de portabilidade .NET.

Quais bibliotecas você está usando fora do conjunto de controle nativo do Windows 10?

Normalmente Telerik DataGrid e Community Toolkit

De que maneiras podemos ajudar na migração que não estamos pensando no momento?

Se você abrir um aplicativo UWP no Visual Studio que tenha uma versão anterior ao Win SDK que você instalou, o Visual Studio o migrará para você. Talvez você deva pensar em algo assim para a migração do WinUI também. Não tenho certeza, mas é algo para se manter em mente. Especialmente quando o Visual Studio não tem mais os modelos UWP normais, pode ser confuso para os desenvolvedores ter um aplicativo que você não pode criar com um modelo.

Outros

Como já mencionado em outros comentários, acho que é hora de mudar para os arquivos .csproj no estilo SDK.

adicionar modelos winui 3.0 ao estúdio de modelos do Windows.

WinUI em aplicativos de desktop

WinUI na área de trabalho permitirá que os desenvolvedores usem a biblioteca de interface do usuário do Windows em um modelo de aplicativo de área de trabalho. @ marb2000 está trabalhando em uma postagem de discussão mais detalhada nas próximas semanas. Sinta-se à vontade para usar este tópico até então para sugestões.

Como um desenvolvedor .net, esta é a parte em que estou mais interessado.

Modelos

• Há interesse / necessidade de que as versões anteriores dos modelos UWP XAML permaneçam no novo fluxo de projeto do VS?

Dependendo do número de modelos. Se o número for baixo (por exemplo, apenas o "Aplicativo em branco (Windows universal)" por idioma, portanto, 1 no caso de c #), o ruído é baixo e pode ser suportado. Mas se envolver mais do que alguns modelos, não os inclua por padrão e adicione um componente de instalação opcional do VS para adicioná-los.

• Como podemos ajudá-lo a ser mais eficiente ou bem-sucedido em relação aos modelos e componentes do Visual Studio?

Mantenha um modelo em branco real sem estrutura (melhor para tutoriais). Dê uma olhada no que o asp.net core está fazendo, há muitas mudanças que eles fizeram em sua nova experiência de projeto. Basicamente, você escolhe um modelo genérico "App (UWP WinUI)" e, em seguida, uma segunda tela, específica para o modelo do seu aplicativo, permite escolher entre diferentes modelos. Use esta etapa para escolher também a versão mínima e a de destino da plataforma (portanto, nenhuma etapa adicional). Você pode adicionar uma opção para criar o projeto de empacotamento do aplicativo diretamente, por exemplo.

Também fornece um bom suporte para componentes na caixa de ferramentas entre projetos. Novos controles devem ser exibidos imediatamente na caixa de ferramentas, agrupados por projetos. Talvez suporte para ícones de designer para ajudar a distingui-los.

• Este passo a passo é útil e você gostaria de ver mais disso à medida que os cenários tomam forma?

sim

Suporte de linguas

• Seria benéfico se fornecêssemos uma ferramenta de migração que automatizasse as etapas 1-3?

Uma boa documentação (uma página com etapas claras) deve ser suficiente. Se tudo pode ser feito de dentro do VS sem editar o csproj manualmente, sugiro adicionar apenas uma página de documentação descrevendo as etapas.

Se você decidir (e espero que faça), mudar para o novo formato csproj, então uma ferramenta de migração certamente será necessária, pois a migração exigirá a edição do arquivo csproj.

Embalagem

MSIX é o método de empacotamento moderno para todos os aplicativos. Para WinUI no Win32, devemos oferecer suporte ao ClickOnce? Para quais outros métodos de embalagem devemos incluir suporte? Especialmente para WinUI no Win32

Compare as diferenças entre clickonce e implantação msix:

1. o recurso App Installer não oferece a mesma experiência em versões mais antigas do Windows
2. MSIX requer um pacote assinado válido (interno ou público). Clickonce oferece suporte a pacotes autoassinados.
3. o modelo de pacote tem algumas limitações, principalmente causadas pelo ambiente isolado (nenhum acesso local de appdata por exemplo, nenhuma operação elevada).

Para mim, o problema mais irritante é o 2. Normalmente, temos aplicativos clickonce que são implantados internamente com computadores não registrados com um domínio. Portanto, para esse tipo de aplicativo, será necessário assinar o pacote com um certificado de assinatura público válido.

É difícil prever todas as diferenças entre essas duas estruturas, já que o formato de empacotamento do Appx geralmente é anunciado apenas para aplicativos voltados para a Loja e, quando vemos limitações, nem sempre sabemos se elas se aplicam também ao formato de distribuição na web.

• Experiência de Designer

Performances, performances, performances e suporte para grandes soluções com muitos projetos.

A versão WinUI do SDK do Windows 10 e do designer WinUI Xaml se tornará o código-fonte aberto?

Seremos capazes de postar solicitações para o fluxo de trabalho do tempo de design e experiência?

O SDK seguirá uma cadência de lançamento semelhante ao lançamento do nuget do WinUI?

Algumas dores adicionais:
melhorar a experiência de depuração de mixagem gerenciada e não gerenciada.
Atualmente, quando ocorre uma exceção no código não gerenciado, COMException é mostrado no site de depuração gerenciado. As coisas podem ser piores se a pilha de chamadas cruzar o limite gerenciado / não gerenciado mais de 1 vez.
Comparando com o WPF, a pilha de chamadas gerenciadas está sempre disponível e a exceção lançada carrega uma string que é útil para depuração.
Eu sei que o mundo não gerenciado e o modelo COM não são tão convenientes quanto gerenciados. Mas, pelo menos, quando uma exceção (HResult errôneo) é lançada pela estrutura, eu quero as informações necessárias para localizar a linha de código do repositório

Dependemos muito do ClickOnce, então seria bom dar suporte a curto prazo. Estaríamos dispostos a migrar para o MSIX, mas depois que recursos semelhantes forem oferecidos.

Quanto aos modelos, seria bom ter um que fornecesse IU padrão e código para NavigationView e navegação.

Valeu

Dependemos muito do ClickOnce, então seria bom dar suporte a curto prazo. Estaríamos dispostos a migrar para o MSIX, mas depois que recursos semelhantes forem oferecidos.

Quanto aos modelos, seria bom ter um que fornecesse IU padrão e código para NavigationView e navegação.

Valeu

A estrutura e os padrões de "shell" mais comuns do aplicativo - devem estar disponíveis como modelos para que os desenvolvedores possam começar a trabalhar rapidamente. Os aplicativos originais da Microsoft devem ser exemplares nesses layouts e atuar como prática recomendada em termos de comportamento, consistência e cumprimento das normas de design de interface do usuário para Fluent Design e WinUI.

@shaggygi @mdtauk
Para a "estrutura e padrões do shell do aplicativo mais comum" e "Quanto aos modelos, seria bom ter um que fornecesse uma IU padrão e código para um NavigationView e navegação." existe o Windows Template Studio que é mantido e desenvolvido pela Microsoft e pela Comunidade. Para citar sua introdução:

O Windows Template Studio (WTS) é uma extensão do Visual Studio 2017 e 2019 que acelera a criação de novos aplicativos da Plataforma Universal do Windows (UWP) usando uma experiência baseada em assistente. O projeto UWP resultante é um código bem formado e legível que incorpora os recursos mais recentes do Windows 10 enquanto implementa padrões comprovados e práticas recomendadas.

@ Felix-Dev eventualmente haverá modelos WPF além do UWP?

@shaggygi Pode haver boas notícias para você! Veja este tópico : Embora aparentemente nada seja garantido neste ponto, a ideia de fornecer modelos especificamente para projetos WPF está aparentemente sendo explorada. Conforme observado no tópico vinculado, houve uma sessão não pública chamada "Windows Template Studio - WPF Edition" hospedada no Build 2019.

Estamos usando C ++ / WinRT. Não usamos o designer ou vinculação xaml no momento. Mas estaremos criando controles em tempo de execução e estilizando-os possivelmente via UWP xaml. Também precisaremos de diálogos e janelas filho sem janela restrita com ilhas xaml, incluindo janelas de encaixe / flutuantes, etc.

Tentei escrever XAML para meu aplicativo C ++ e, cara, foi uma experiência dolorosa.

Tive que adicionar muitas propriedades do projeto que não estão documentadas e alguns outros hacks para gerar tudo e empacotá-lo corretamente.

Por exemplo:

• Ao criar um projeto para armazenar minhas páginas XAML, tive que adicionar <_NoWinAPIFamilyApp>true</_NoWinAPIFamilyApp> e <_VC_Target_Library_Platform>Desktop</_VC_Target_Library_Platform> , duas propriedades de projeto que são completamente não documentadas e descobertas apenas pela inspeção do código-fonte do novo Terminal.
• Eu tinha um enigmático "Não foi possível criar uma nova visualização porque a janela principal ainda não foi criada" até que criei e usei uma classe App, que não há como fazer no VS, exceto criar uma página normal e entrar nas propriedades do Arquivo XAML no VS e alterá-lo para uma definição de aplicativo e, em seguida, ajustar o MIDL, o código-fonte e o arquivo XAML.
• Eu adicionei o pacote Microsoft.Toolkit.Win32.UI.XamlApplication NuGet para criar minha classe de aplicativo e não pude carregá-lo até que também adicionei Microsoft.VCRTForwarders , novamente encontrei isso ao inspecionar a fonte do Terminal, não há nenhuma indicação sobre nenhum dos pacotes em qualquer lugar.
• Os PRIs não estavam sendo mesclados em um até que eu adicionasse algo no arquivo .wapproj, portanto, ele não conseguiu encontrar meu recurso XAML.
• O XBF não estava funcionando até que eu adicionei <DisableEmbeddedXbf>false</DisableEmbeddedXbf> que surpreendentemente desabilita o XBF incorporado em vez de habilitá-lo. O único erro que tive foi um erro de análise XAML sem nada indicando que os arquivos XBF não estavam funcionando.
• maxVersionTested no manifesto do meu aplicativo foi totalmente ignorado até que eu mudei tudo para minúsculas, embora as instruções dissessem para usar a versão camel case: https://github.com/MicrosoftDocs/windows-uwp/issues/1781 #issuecomment -511173811

Além disso, C ++ / WinRT também estava sendo um pé no saco:

• Cada vez que executei uma compilação incremental, eu tinha um [msg]redefinition [context]: MyClass para minhas classes personalizadas que me impediu de compilar e não foi embora até que executei uma compilação limpa que, devido aos cabeçalhos C ++ / WinRT, leva séculos. Esse problema de alguma forma desapareceu magicamente no meio do caminho.
• Agora, quando executo compilações limpas, recebo um erro sobre cabeçalhos ausentes. Apertar o botão construir uma segunda vez faz com que funcione novamente.
• Eu tive que escrever minha própria classe AppT<> por causa do codegen incorreto de C ++ / WinRT. O aplicativo Terminal e o exemplo de ilhas XAML fazem o mesmo, como se fosse algo que os usuários precisassem fazer, em vez de corrigir o problema raiz.
• Alterar qualquer coisa nos arquivos MIDL resulta em erros de compilação até que eu faça uma compilação limpa.

Mesmo assim, ele ainda não funciona descompactado, mesmo ao adicionar activatableClass coisas ao manifesto do meu aplicativo (algo sobre não ser capaz de encontrar o recurso XAML, como quando eu não havia mesclado os PRIs), o que é importante para meu aplicativo apoiar.

Migração

A automação para as etapas 1-3 é definitivamente útil, especialmente porque renomear namespaces em centenas de arquivos consome muito tempo e está sujeito a erros. Além disso, um analisador de compatibilidade seria bom, assim como o .net framework> .net core one, que cria um relatório sobre o quão compatível é a base de código atual e anota todas as possíveis alterações necessárias.

Ferramental

Como outros já disseram, um editor mais rico em recursos seria bom. Na maior parte do tempo aqui no trabalho, o XAML é feito à mão e geralmente usa o designer como um guia sobre o esqueleto básico sobre a aparência do aplicativo. IntelliSense e refatorações inteligentes seriam realmente úteis, coisas de QoL como CTRL + R + R para renomear coisas (por exemplo, propriedades de dependência ou mesmo a tag), por exemplo, especialmente quando você tende a ter muitos UserControls e também Implementação GoTo e referências. O suporte do analisador Roslyn também seria muito bom.

Para expandir as melhorias de namespacing. Seria bom se de alguma forma fosse possível ter controles personalizados sem prefixo mais fáceis de fazer sem adicionar um novo XmlnsDefinition s ao namespace padrão, ele organiza a marcação imo e só precisa de prefixos quando há controles ambíguos encontrados como como as classes funcionam, isso se encaixaria perfeitamente com a implementação GoTo também. Normalmente, o nome do controle e talvez passar o mouse sobre ele para mostrar o namespace completo seria suficiente para saber de onde ele vem, você normalmente não usaria aliases de namespace no código C # a menos que seja necessário.

Principalmente em ferramentas, seria bom se ele se comportasse como o Editor C # para tornar as refatorações menos frágeis ou um aborrecimento e navegar pela marcação mais fácil. Além disso, para a própria linguagem XAML, diminuir o detalhamento também seria um bom exemplo, sendo o estilo conforme discutido nos números 62 e 279.

Para expandir as melhorias de namespacing. Seria bom se de alguma forma fosse possível ter controles personalizados sem prefixo mais fáceis de fazer sem adicionar um novo XmlnsDefinition s ao namespace padrão, ele organiza a marcação imo e só precisa de prefixos quando há controles ambíguos encontrados como como as classes funcionam, isso se encaixaria perfeitamente com a implementação GoTo também. Normalmente, o nome do controle e talvez passar o mouse sobre ele para mostrar o namespace completo seria suficiente para saber de onde ele vem, você normalmente não usaria aliases de namespace no código C # a menos que seja necessário.

Eu gostaria de pensar que a versão WinUI 3.0 do controle Page eliminaria a necessidade de usar um prefixo para esses controles. Eu acho que isso seria uma coisa do nível do SDK.

É possível não alterar os namespaces ao usar o WinUI?

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 !

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. De 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.

Não creio que fosse necessário fornecer uma ferramenta de portabilidade. É uma mudança única, razoavelmente fácil com Localizar e Substituir, e o número de instâncias será bastante baixo.

Também encontrou mais problemas:

• Depois de adicionar recursos à classe App , meu XAML não conseguiu encontrá-lo até que eu adicionei isso, novamente encontrado no aplicativo Terminal e sem muita ideia sobre o que ele realmente faz:
  xml <Target Name="PlaceAppXbfAtRootOfResourceTree" DependsOnTargets="GetPackagingOutputs"> <ItemGroup> <_RelocatedAppXamlData Include="@(PackagingOutputs)" Condition="'%(Filename)' == 'App' and ('%(Extension)' == '.xaml' or '%(Extension)' == '.xbf')" /> <PackagingOutputs Remove="@(_RelocatedAppXamlData)" /> <PackagingOutputs Include="@(_RelocatedAppXamlData)"> <TargetPath>%(Filename)%(Extension)</TargetPath> </PackagingOutputs> </ItemGroup> </Target>
• A compilação será completamente interrompida aleatoriamente com um erro semelhante a cannot find type Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication e a única maneira de obter a construção do projeto novamente é fazer uma compilação limpa
• Não consigo executar o aplicativo definindo diretamente o vcxproj para o exe principal como projeto de inicialização, tenho que iniciar manualmente a saída do appx descompactado em bin\x64\Debug\AppX e, em seguida, injetar um depurador de dentro do VS ou definir o pacote do aplicativo como processo de inicialização.

Coisas relacionadas no Windows Desktop: .NET Community Standup - 25 de julho de 2019 se estiver interessado.

Há muito tempo WinForms, desenvolvedor WPF aqui com alguma experiência UWP. Aqui estão meus 2 centavos:

Migração

• Uma ferramenta para migrar aplicativos UWP existentes para WinUI é obrigatória.
• Uma ferramenta para converter controles WinForms ou WPF em controles WinUI em um aplicativo existente seria além de incrível. Por converter os controles, quero dizer alterar as referências no contêiner para os controles individuais.
• Uma ferramenta para migrar Xamarin Forms para WinUI para permitir o back-port de um aplicativo móvel para Windows.

Ferramental

• O editor XAML atual é horrível! Ele precisa usar a tela normal do editor de texto e fornecer recursos do Roslyn a serem aplicados ao modelo de objeto XAML para melhor intellisense e refatorações.
• Até que o Visual Studio seja de 64 bits, o Editor XAML precisa ser um aplicativo autônomo de 64 bits nos bastidores. Estou constantemente tendo que reiniciar o VS 2017 e o VS 2019 para impedir o erro de falta de memória ao trabalhar com muito XAML.

Modelos

• Precisamos desses modelos de projeto

  • NavigationView WinUI
  • NavigationView WPF
  • Ribbon WinUI
  • Ribbon WPF
  • WinForms de fita

• Precisamos desses modelos de página / janela

  • Página do controlador de mídia
  • Página do navegador
  • Janela de diálogo
  • Janela sem borda
  • Janela Flutuante

• Precisamos de modelos de controle

  • Visualização da grade de dados encapsulada
  • Visualização de dados filhos encapsulados

Esses dois últimos trabalhariam juntos para criar janelas de detalhes-mestre fáceis.

todos esses modelos e páginas etc já estão sendo feitos no projeto Windows Template Studio, por que não seguir o mesmo caminho em vez de recriar tudo isso?

Arquivo de projeto de estilo SDK
Uma das partes mais importantes que eu gostaria de ver - como muitos outros também mencionaram - é o suporte para o novo formato de arquivo de projeto SDK Style para aplicativos UWP e "Desktop XAML".

Migração entre modelos de aplicativos UWP e Desktop XAML
Se começarmos a construir um aplicativo "Desktop XAML", a que distância ele estará de um aplicativo UWP? Será trivial transformá-lo em um aplicativo UWP mais tarde se percebermos que permanecemos dentro das restrições do sandbox UWP? Ou se começarmos a construir um aplicativo UWP e percebermos que precisamos de mais, será fácil transformá-lo em um aplicativo "Desktop XAML"?

Estou com o suporte do Template Studio.

Estou com o suporte do Template Studio.

O Template Studio oferece suporte a projetos XAML C ++?

O que o Template Studio está fazendo deve ser parte do WinUI SDK IMO

O que o Template Studio está fazendo deve ser parte do WinUI SDK IMO

Deve ser uma parte Visual Studio IDE IMO! 😎

pessoal, o ponto é que o windows template studio está fazendo tudo em um para a criação de projetos UWP, então tendo isso em mente se algo estiver faltando como o suporte a xaml c ++, devemos considerar adicioná-lo ao windows template studio, acho que será mais rápido e mais eficiente se todas as inovações em projetos uwp permanecerem em um projeto.

Que haja algum método para usar a camada inferior da pilha do WinUI 3 diretamente sem XAML ou mesmo MVVM. Isso é especialmente útil para o software C ++ big-iron existente que já tem algum tipo de arquitetura MV-qualquer em sua base de código. Eles apenas querem algo melhor do que HWND + GDI.

E, por favor, faça as pessoas pensarem que WinUI 3 não é um brinquedo, ele pode realmente suportar softwares sérios .

@ be5invis Concordo totalmente. A única solução agora é o XamlDirect, mas é mais voltado para desenvolvedores de middleware.

Você já pode construir conteúdo manualmente com as Ilhas Xaml. Basta fazer com que um DesktopWindowXamlSource funcione e anexado a uma janela e, em seguida, crie e organize / faça o layout dos controles no código.

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

@MarkIngramUK Eles podem precisar de algo mais “completo”, como substituir CreateWindow por funções WinUI.

Para fins de design, eu realmente gostaria que os futuros modelos WinUI WPF tivessem suporte para expandir o conteúdo de uma página na barra de título, como os aplicativos UWP atuais. No momento, com a solução de ilhas XAML existente, estamos meramente hospedando controles dentro de uma janela WPF / WinForms em vez de uma exibição moderna.

@LucasHaines A lista das linguagens que planejamos oferecer suporte com WinUI 3.0: C #, C ++ / WinRT, Visual Basic. Estamos explorando o suporte do F #.

Isso mostra que você está fazendo errado, não apenas para F #, mas para todos os idiomas .Net. Você está começando pensando em modelos e arquivos .xaml, que é como construir uma casa e colocar tapetes e cortinas no lugar sem ter terminado a estrutura.

Você deve ser capaz de instalar o WinUI em qualquer projeto .Net Standard 2.0 / .Net Core 3.0 / .Net 5 como um pacote Nuget. Então você tem acesso a todas as classes definidas dentro. Você pode então fazer referência a esses projetos de um projeto WinUI (que pode ser apenas C #). Isso permite que as visualizações WinUI sejam criadas em qualquer idioma .Net. Veja como o Xamarin.Forms faz isso .

As classes já estão disponíveis para uso em F # (uma vez que são componentes do Windows Runtime, que podem ser usados ​​por todas as linguagens .NET)

Você poderá criar manualmente um layout. Você pode até fazer isso via Python usando Py / WinRT para todos os cuidados do WinUI.

@sylveon Quais classes especificamente? Eu estaria interessado ...

Todos eles. A API pública do WinUI é composta apenas por componentes do Windows Runtime.

@LucasHaines A lista das linguagens que planejamos oferecer suporte com WinUI 3.0: C #, C ++ / WinRT, Visual Basic. Estamos explorando o suporte do F #.

Isso mostra que você está fazendo errado, não apenas para F #, mas para todos os idiomas .Net. Você está começando pensando em modelos e arquivos .xaml, que é como construir uma casa e colocar tapetes e cortinas no lugar sem ter terminado a estrutura.

Você deve ser capaz de instalar o WinUI em qualquer projeto .Net Standard 2.0 / .Net Core 3.0 / .Net 5 como um pacote Nuget. Então você tem acesso a todas as classes definidas dentro. Você pode então fazer referência a esses projetos de um projeto WinUI (que pode ser apenas C #). Isso permite que as visualizações WinUI sejam criadas em qualquer idioma .Net. Veja como o Xamarin.Forms faz isso .

Este tópico / pergunta é sobre ferramentas. Sim, as bibliotecas podem ser referenciadas diretamente a partir de qualquer linguagem capaz de consumi-las, mas há uma confusão de definições entre ferramentas e suporte a linguagem.
Tomando Xamarin.Forms como exemplo. Isso só fornece ferramentas para C # e, em menor medida, F #. É possível construir aplicativos com VB.Net e Xamarin.Forms, mas não é _oficialmente suportado_, pois não há ferramentas e apenas documentação limitada para fazer isso.

Além disso, como WinUI é específico do Windows, não pode ser referenciado em qualquer projeto .Net Standard 2.0 / .Net Core 3.0 / .Net 5.
Também há necessidade de suporte a nível de projeto / compilador / empacotamento para alguns cenários.

Grande equipe de trabalho na versão v2.2 . Alguma chance de obtermos uma breve atualização sobre o status da v3.0?

Eu vejo isso mencionado várias vezes, mas nenhuma direção clara de um jeito ou de outro. Como o WinUI 3.0 terá todos os controles agora, o requisito de namespace para fazer referência aos controles da biblioteca WinUI DEVE ser removido. Isso confunde muito o XAML, dificulta muito a migração e quebra a compatibilidade simples com coisas como plataforma UNO e Avalonia.

Remova a necessidade de xmlns:mux="using:Microsoft.UI.Xaml.Controls" do XAML. Eu entendo que o código por trás ainda precisa ser alterado. Também pode haver uma configuração para isso em algum lugar do projeto.

Remova a necessidade de xmlns:mux="using:Microsoft.UI.Xaml.Controls" do XAML.

Não será necessário no XAML _markup_, mas a alteração de namespaces no code-behind ainda seria necessária.

Se você quiser usar os controles do Windows (se eles não forem removidos do sistema operacional) - você deve declarar o namespace em XAML

Se você quiser usar os controles do Windows (se eles não forem removidos do sistema operacional) - você deve declarar o namespace em XAML

Com o WinUI 3.0 isso não é um cenário - você não pode misturar e combinar os controles do sistema operacional com os controles do WinUI 3.0. Isso só funciona com WinUI 2.x agora porque esses controles são complementos para o sistema operacional (e temos muitos casos estranhos em que enviamos o tipo em ambos os lugares, como NavigationView e TreeView, causando ambiguidade).

Se você quiser usar os controles do Windows (se eles não forem removidos do sistema operacional) - você deve declarar o namespace em XAML

Com o WinUI 3.0 isso não é um cenário - você não pode misturar e combinar os controles do sistema operacional com os controles do WinUI 3.0. Isso só funciona com WinUI 2.x agora porque esses controles são complementos para o sistema operacional (e temos muitos casos estranhos em que enviamos o tipo em ambos os lugares, como NavigationView e TreeView, causando ambiguidade).

Bom de se ouvir. Tornará mais fácil descontinuar isso do sistema operacional. Espero que o aplicativo Settings, o Shell e outras partes do sistema operacional também migrem para o WinUI 3.0.

E vamos torcer para que as portas das Ferramentas do administrador, Wordpad, etc. para XAML reutilizem o mesmo código tanto quanto possível!

@jevansaks Ok, entendido, obrigado pelo feedback!

@mdtauk Não haverá necessidade de distinguir entre os controles herdados do 'SO' e os novos controles da plataforma 'WinUI 3.0' em XAML. Tudo está mudando para WinUI 3.0 e os controles do sistema operacional não estão recebendo mais atualizações de recursos, como você sabe. Após o WinUI 3.0, se um desenvolvedor ainda quiser direcionar os controles herdados, ele deve desenvolver com SDKs mais antigos e versões do Visual Studio. Manter a capacidade de fazer referência a duas bibliotecas de controle de interface do usuário do Microsoft / Windows a partir do XAML seria apenas um obstáculo pelos motivos mencionados anteriormente. Além disso, com a dissociação do WinUI, o desenvolvimento pode finalmente mudar para um caminho sustentável de 'permitir' mudanças como essa - o que nem é uma quebra.

Edit: Esqueci de atualizar antes de responder, a maior parte disso é redundante agora.

@robloo Fico feliz que isso realmente substitua as versões anteriores do UWP Xaml. Eu também espero que o sistema operacional possa migrar para ele para os aplicativos da caixa de entrada e Shell.

Também espero que haja muitos vídeos de desenvolvedores detalhando o processo de migração para o WinUI 3.0 - e como trabalhar com o WinUI 3.0 com o mesmo ciclo de vida dos aplicativos Win32. Chega de reidratação, melhores maneiras de salvar o estado da página e a navegação etc.

Pode ser útil (dependendo de quais aplicativos planejam mudar para WinUI 3.0) fornecer exemplos de, digamos, pegar o Wordpad e mover o código para uma nova IU construída em WinUI - bem como pegar um aplicativo de caixa de entrada como o Groove Music e movê-lo para WinUI 3.0

Para WinUI 3, deve haver alguma consistência em relação ao posicionamento das funções do aplicativo na Linguagem de Design.

A este respeito, Configurações de aplicativos.

Onde encontro as configurações do aplicativo? Eu clico na engrenagem no canto superior direito? Canto inferior esquerdo? Clico no avatar do perfil no canto superior direito e clico nas configurações? Eu clico no canto superior esquerdo? Inferior esquerdo? Devo ir para Editar> Preferências?

Realmente depende se você usa NavigationView ...

De: shaheedmalik [email protected]
Enviado: quinta-feira, 12 de setembro de 2019 15:48:12
Para: microsoft / microsoft-ui-xaml [email protected]
Cc: The Sharp Ninja [email protected] ; Comentário [email protected]
Assunto: Re: [microsoft / microsoft-ui-xaml] Ferramentas e experiência do desenvolvedor WinUI 3.0 - entrada necessária (# 1045)

Para WinUI 3, deve haver alguma consistência em relação ao posicionamento das funções do aplicativo na Linguagem de Design.

A este respeito, Configurações de aplicativos.

Onde encontro as configurações do aplicativo? Eu clico na engrenagem no canto superior direito? Canto inferior esquerdo? Clico no avatar do perfil no canto superior direito e clico nas configurações? Eu clico no canto superior esquerdo? Inferior esquerdo? Devo ir para Editar> Preferências?

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLB5VXXUOYIA2NIEZATQJKTIZA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TGV4I#issuecomment-531000049 , ou silenciar o fio https: // github. com / notificações / unsubscribe-auth / AD3GCLCQQ6L7H3LEJAHUDMLQJKTIZANCNFSM4ICOLUJQ .

Como podemos ajudá-lo a ser mais eficiente ou bem-sucedido em relação aos modelos e componentes do Visual Studio?

Não devem ser necessários esforços significativos e atributos de configuração de projeto não documentados para fazer as ilhas WinUI / XAML funcionarem com C ++ / WinRT no Visual Studio.

Não posso enfatizar isso o suficiente, mas o mais importante para mim é que o WinUI renderiza para mais do que apenas Windows.

Assim que vi o Surface Duo me perguntei como será a história do desenvolvimento de plataforma cruzada agora que a Microsoft está lançando um dispositivo com Android. O Xamarin.Forms não funciona por uma série de razões óbvias. É hora da Microsoft adotar totalmente um kit de ferramentas de plataforma cruzada (como a plataforma UNO, mas acabado e estável) que todos sabemos que foi solicitado em várias formas por anos. Espero que a Microsoft tenha alguns planos não revelados para os desenvolvedores aqui.

Satya afirmou "Não queríamos apenas construir experiência e um dispositivo, mas que abrangesse todos os dispositivos em nossas vidas." Se você quiser que os desenvolvedores venham nessa jornada como Panos espera, esta é a melhor maneira de fazê-lo. Caso contrário, você está pedindo aos desenvolvedores que escrevam duas interfaces de usuário separadas para abranger a 'experiência' entre o Surface Duo e o resto da família. Não acho que seja um pedido justo para os desenvolvedores dentro de uma 'família' de dispositivos.

Renderiza de forma diferente em cada plataforma, também conhecida como "aparência e comportamento nativos".

Eu não entendo isso. Por favor, não, a última coisa que quero que o Fluent Design faça é causar mais inconsistência, não menos.

EDIT: comentário original removido

Satya afirmou "Não queríamos apenas construir experiência e um dispositivo, mas que abrangesse todos os dispositivos em nossas vidas." Se você quiser que os desenvolvedores venham nessa jornada como Panos espera, esta é a melhor maneira de fazê-lo. Caso contrário, você está pedindo aos desenvolvedores que escrevam duas interfaces de usuário separadas para abranger a 'experiência' entre o Surface Duo e o resto da família. Não acho que seja um pedido justo para os desenvolvedores dentro de uma 'família' de dispositivos.

É EXATAMENTE por isso que fiquei abatido com o fato de o Duo ser Android.

Os modelos precisam ser de código aberto para remover quaisquer áreas problemáticas que surjam neles.

Quando vou usar o WinUI com WPF e quando vou criar um novo controle com código como:
c# public class MyControl : UserControl { ... }
Ele usará WinUI.UserControl ou WPF.UserControl?
Teremos necessidade de escolher e como lidar com isso?

E interessante, se as ferramentas XAML forem unificadas, teremos a capacidade de criar algum tipo de arquivo xaml compartilhado?
Algo como:

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

Deve ser algum tipo de dialeto compartilhado com um namespace raiz especial? (como projetos compartilhados no Visual Studio). Pode ser semelhante a xaml condicional.

Ele usará WinUI.UserControl ou WPF.UserControl?
Teremos necessidade de escolher e como lidar com isso?

Isso deve acontecer automaticamente no XAML onde você define

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

Isso diz ao compilador que é UWP.

public class MyControl : UserControl { ... }

Na verdade, isso está incorreto. Você deveria estar declarando assim

public partial class MyControl { }

Nenhuma herança é necessária porque é tratada pelo arquivo .g.cs que especifica a herança e também a estrutura que está sendo usada.

Sobre os modelos, eu ficaria mais feliz se houvesse mais do que um modelo Hello World. O que quero dizer é que a Microsoft deve fazer backup de alguns frameworks periféricos reconhecidos necessários para trabalhar com aplicativos cliente

@weitzhandler Eu adoraria ver isso também !!

Projetos de estilo SDK para projetos C # e Cpp / WinRT também devem ser obrigatórios

Acho que deveria haver modelos para todos os padrões de aplicativos Win32 e Inbox comuns. Uma pequena lista na minha cabeça:

• Fita
• Menu principal
• Interface de documento com guias
• Vista de navegação
• Comando / Barra de Ferramentas
• Vista de navegação superior
• Hub / Gallery (sei que está um pouco obsoleto)
• Treeview / MasterDetails (explorador de arquivos, RegEdit, aplicativo de administração)

Mas também deve haver modelos de itens para diálogos, páginas, páginas de configurações comuns, etc.

Como podemos ajudá-lo a ser mais eficiente ou bem-sucedido em relação aos modelos e componentes do Visual Studio?

Trabalhe com a extensão C ++ para VSCode / Visual Studio. Eu quero ver o VS Code como um editor com suporte também que fornece uma experiência semelhante ao Visual Studio. Supõe-se que o WinUI seja o OSS e o VS Code, então acho que isso é possível.

Ferramentas como Template10 e Windows Template Studio são sinais de falta de funcionalidade básica. Com o WinUI3, deve haver funcionalidade para o que essas ferramentas fazem. Aposto que muitos desenvolvedores estão fazendo essa estrutura básica repetidamente ... ela deve fazer parte da estrutura. Nenhuma ferramenta extra deve ser necessária. Talvez você devesse até desligar o scaffolding MVVM para aqueles raros casos em que você gostaria de ficar sem ele.

Depois de trabalhar um pouco com ASPNET Core, estou perdendo a injeção de dependência. Esse recurso existe nativamente no ASPNET Core. Ele simplesmente funciona, sem você fazer nada extra. E você pode adicionar ou modificar serviços facilmente se quiser. Mas para UWP hoje, você precisa construir isso sozinho ou usar algo como WTS para começar, mas ainda parece que está colado depois. WinUI3 com injeção de dependência nativa adequada seria muito útil.

Não acho que a presença de sistemas de modelo mostre uma falta de funcionalidade básica, acho que destaca a qualidade das comunidades de suporte que criariam esses sistemas de modelo.

Ferramentas como Template10 e Windows Template Studio são sinais de falta de funcionalidade básica.

Eu vejo coisas assim como uma extensão da funcionalidade básica. É claro que coisas como essa podem ser implementadas internamente, mas cabe mais à equipe principal manter e apoiar. À medida que a equipe principal faz mais, isso tende a significar que eles ficam mais dispersos e tudo leva mais tempo. Se Msft achar que tem orçamento para trazer coisas como essa para a equipe principal, eu adoraria conversar com alguém sobre isso;)

Apenas algumas ideias sobre estilos e modelos de controle simplificados, como tornar mais fácil adicionar comportamento personalizado para estilos e controles integrados. Um exemplo perfeito aqui é o estilo de Button , quando precisamos substituir todo o modelo de controle para alterar a cor do foco ou usar o raio da borda. Definir alguns deles diretamente, como em css , evitará a criação de quilômetros de código XAML

@AntiPasha Você já ouviu falar do estilo Ligthweight ? Com ele, você pode alterar facilmente a cor do foco sem ter que recriar todo o estilo:

Alterar a cor de foco de um botão seria apenas:

            <Button Content="MyButton">  
                <Button.Resources>
                    <ResourceDictionary>
                        <ResourceDictionary.ThemeDictionaries>
                            <ResourceDictionary x:Key="Dark">
                                <SolidColorBrush x:Key="ButtonForegroundPointerOver" Color="Blue"/>
                                <SolidColorBrush x:Key="ButtonBackgroundPointerOver" Color="Transparent" />
                            </ResourceDictionary>
                        </ResourceDictionary.ThemeDictionaries>
                    </ResourceDictionary>
                </Button.Resources>
            </Button>

Uma propriedade Control.CornerRadius também foi adicionada ao 17763 SDK e a equipe WinUI também está introduzindo recursos substituíveis para adicionar facilmente o aplicativo ou a personalização de toda a página sem ter que redefinir o estilo dos controles: https://github.com/microsoft/microsoft-ui- xaml-specs / blob / user / chigy / roundedcorner / active / RoundedCorner / roundedcorner.md # customization -options

E interessante, se as ferramentas XAML forem unificadas, teremos a capacidade de criar algum tipo de arquivo xaml compartilhado?
Algo como:

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

Deve ser algum tipo de dialeto compartilhado com um namespace raiz especial? (como projetos compartilhados no Visual Studio). Pode ser semelhante a xaml condicional.

@Tirraon, este é um exemplo realmente interessante, mas acho que quando falamos sobre unificação de ferramentas, é melhor começar com a mentalidade de que as plataformas existirão como existem hoje, e não estamos tentando criar outro padrão Xaml equivalente.

Podemos usar o namespace padrão para diferenciar a plataforma de "nível superior" à qual o arquivo xaml pertence, então, por exemplo, poderíamos ter os seguintes namespaces padrão para cada plataforma XAML (eles são principalmente hipotéticos, então considere-os com cautela 😄):

wpf: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
uwp: xmlns="http://github.com/microsoft/microsoft-ui-xaml"
avalônia: xmlns="https://github.com/AvaloniaUI/AvaloniaUI"
uno: xmlns="https://github.com/unoplatform/uno"
xamarin.forms: xmlns="https://github.com/xamarin/Xamarin.Forms"

Portanto, para misturar WinUI com WPF usando ilhas Xaml, você tem uma marcação semelhante a esta:

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

</UserControl>

O que você acha?

@stevenbrix
No seu exemplo para UWP, ele renderizará os dois botões, não é?
Quero dizer, para o caso, quando xmlns = "... / xaml / presentation" é o namespace de nível superior e UserControl wutg StackPanel estão disponíveis em uwp e wpf, então o segundo botão não estaria disponível também em ambas as plataformas?

quando falamos em unificar ferramentas, é melhor começar com a mentalidade de que as plataformas existirão como existem hoje

Sim, concordo totalmente com isso.

No seu exemplo para UWP, ele renderizará os dois botões, não é?
Quero dizer, para o caso, quando xmlns = "... / xaml / presentation" é o namespace de nível superior e UserControl wutg StackPanel estão disponíveis em uwp e wpf, então o segundo botão não estaria disponível também em ambas as plataformas?

@Tirraon , o exemplo que dei é puramente para o aplicativo WPF que usa as ilhas Xaml para modernizar incrementalmente seu aplicativo. Não se destina a uma marcação "padrão" usada entre aplicativos WPF e WinUI, isso faz sentido?

Atualmente, os autores de aplicativos que desejam usar as ilhas Xaml precisam criar controles de usuário para cada ilha. Em seguida, eles fazem referência ao tipo por meio de uma string em sua marcação WPF, em vez de incorporar naturalmente elementos WinUI na marcação WPF.

Estou no telefone agora, mas posso ter um antes e depois mais concreto do que estou propondo quando estiver perto do meu PC.

@stevenbrix
Oh, agora te peguei, obrigado.

@stevenbrix
Oh, agora te peguei, obrigado.

@Tirraon ótimo! Que bom que estamos na mesma página ☺️

Desculpe se minha ideia pareceu sair do campo esquerdo, estivemos nas primeiras discussões sobre como poderíamos potencialmente unificar o ferramental, com o objetivo de melhorar o cenário da Ilha Xaml. Você acha que há valor em algo assim?

FWIW, eu definitivamente acho que há mérito em algo como o que você estava propondo. Mas estou tentando me concentrar em algo que podemos fazer no período de tempo WinUI3 / .NET5.

Descubra como renderizar WinUI Xaml para algum pipeline que traduz a saída para uma tela nativa e recebe entrada de um sistema de mensagem nativo. Como WinUi.Adapters.DirectX, WinUI.Adapters.WASM, WinUi.Adapters.X, WinUi.Adapters.Android.

A implementação de todos os adaptadores não é necessária na inicialização, apenas aqueles que são necessários para oferecer suporte ao Windows 10.

De: Steven Kirbach [email protected]
Enviado: quinta-feira, 7 de novembro de 2019 9:13:46
Para: microsoft / microsoft-ui-xaml [email protected]
Cc: The Sharp Ninja [email protected] ; Comentário [email protected]
Assunto: Re: [microsoft / microsoft-ui-xaml] Ferramentas e experiência do desenvolvedor WinUI 3.0 - entrada necessária (# 1045)

@stevenbrix https://github.com/stevenbrix
Oh, agora te peguei, obrigado.

@Tirraon https://github.com/Tirraon ótimo! Que bom que estamos na mesma página ☺️

Desculpe se minha ideia pareceu sair do campo esquerdo, estivemos nas primeiras discussões sobre como poderíamos potencialmente unificar o ferramental, com o objetivo de melhorar o cenário da Ilha Xaml. Você acha que há valor em algo assim?

FWIW, eu definitivamente acho que há mérito em algo como o que você estava propondo. Mas estou tentando me concentrar em algo que podemos fazer no período de tempo WinUI3 / .NET5.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLBHRGZTDFHFWQTAFK3QSQWCVA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMXFLY#issuecomment-551121583 , ou unsubscribe https://github.com/ notificações / unsubscribe-auth / AD3GCLF2BUTXQFPSVNULZODQSQWCVANCNFSM4ICOLUJQ .

Sim, por favor, o cenário da Ilha XAML é horrível no momento

@sharpninja
Você deveria dar uma olhada no Uno
https://platform.uno/
Também vai suportar WinUI 3.0 para todas as plataformas
https://platform.uno/winui-on-windows7-via-unoplatform/

@stevenbrix
Não tenho muita experiência com as ilhas Xaml e trabalho geralmente com UWP simples. Mas eu definitivamente preciso olhar mais de perto.
Minha proposta não era relacionada ao Xaml Islands em si, mas sim ao WinUI em geral, já que funcionaria em mais de uma plataforma.

Minha proposta não era relacionada ao Xaml Islands em si, mas sim ao WinUI em geral, já que funcionaria em mais de uma plataforma.

@Tirraon , entendi perfeitamente , e absolutamente amo onde sua cabeça está 🙌

Falei brevemente com @jeromelaban e empresa sobre exatamente o que você está propondo, e há definitivamente interesse. Ainda não há um plano ou compromisso concreto, pois ainda estamos nos estágios iniciais de discussão. Esse tipo de contribuição é excelente e nos ajuda a entender melhor o valor que agrega aos nossos clientes 😄

Por cenário de ilha XAML, quero dizer C ++. Veja minhas mensagens anteriores neste tópico para a lista de problemas que enfrentei.

Sim, por favor, o cenário da Ilha XAML é horrível no momento

Por cenário de ilha XAML, quero dizer C ++. Veja minhas mensagens anteriores neste tópico para a lista de problemas que enfrentei.

@sylveon Eu vejo seus comentários (links abaixo), e sim, isso soa muito terrível. Lamento que você esteja passando por isso, tenho certeza de que vamos melhorar.
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -512945553
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -513505038

Muita dor que você está sentindo é relacionada ao sistema de projetos, e eu sei que é algo que está nos radares de muitas pessoas (embora eu esteja bastante distante). Você já viu este vídeo que alguns membros da nossa equipe fizeram sobre as ferramentas XAML? Esse link deve iniciar o vídeo do YouTube no ponto em que @ michael-hawker e @ marb2000 começam a entrar na nova experiência da Ilha Xaml. Definitivamente, nos preocupamos com o C ++, mas não sei se abordamos apenas a experiência do .NET até agora ou se também houve melhorias no C ++. Eles provavelmente poderiam comentar mais sobre isso.

Muitas coisas farão com que a experiência da Ilha Xaml seja fácil e natural de usar. O aspecto a que me refiro é que, atualmente, a maneira como você inclui um conteúdo Island of UWP no WPF é assim (do vídeo acima):

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

Acho que podemos fazer melhor do que isso e fornecer algo assim:

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

@stevenbrix

Falei brevemente com @jeromelaban e empresa sobre exatamente o que você está propondo, e há definitivamente interesse. Ainda não há um plano ou compromisso concreto, pois ainda estamos nos estágios iniciais de discussão. Esse tipo de contribuição é excelente e nos ajuda a entender melhor o valor que agrega aos nossos clientes

Há tanto interesse! (Essa conversa surge em todos os lugares) Se o WinUI pós 3.0 mudasse para implementações de plataforma cruzada, você teria muito suporte de desenvolvedor. Basta olhar para a discussão no # 1461. Em curto prazo, usar a tecnologia da plataforma Uno para converter XAML / C # em HTML / WASM para fazer os aplicativos UWP rodarem em todas as plataformas seria incrível. A longo prazo, estou preocupado com o impacto no desempenho da execução no Electron ou em um navegador e há espaço para uma arquitetura mais eficiente.

Resumindo, eu sei que todos estão ocupados no WinUI 3.0 no momento. Mas quando terminar, seria ótimo se conectássemos @jeromelaban , @ marb2000 , @jevansaks e outros para descobrir a melhor maneira de fazer UWP renderizar em todos os lugares. Essa também seria uma discussão da comunidade muito interessante para uma chamada futura.

WinUi é o único caminho sensato que leva à sobrevivência de Neo e Duo

De: robloo [email protected]
Enviado: quinta-feira, 7 de novembro de 2019 12:00:07
Para: microsoft / microsoft-ui-xaml [email protected]
Cc: The Sharp Ninja [email protected] ; Mencione a mençã[email protected]
Assunto: Re: [microsoft / microsoft-ui-xaml] Ferramentas e experiência do desenvolvedor WinUI 3.0 - entrada necessária (# 1045)

@stevenbrix https://github.com/stevenbrix

Falei brevemente com @jeromelaban https://github.com/jeromelaban e empresa sobre exatamente o que você está propondo, e há definitivamente interesse. Ainda não há um plano ou compromisso concreto, pois ainda estamos nos estágios iniciais de discussão. Esse tipo de contribuição é excelente e nos ajuda a entender melhor o valor que agrega aos nossos clientes

Há tanto interesse! (Essa conversa surge em todos os lugares) Se o WinUI pós 3.0 mudasse para implementações de plataforma cruzada, você teria muito suporte de desenvolvedor. Basta olhar para a discussão em # 1461 https://github.com/microsoft/microsoft-ui-xaml/issues/1461 . Em curto prazo, usar a tecnologia da plataforma Uno para converter XAML / C # em HTML / WASM para fazer os aplicativos UWP rodarem em todas as plataformas seria incrível. A longo prazo, estou preocupado com o impacto no desempenho da execução no Electron ou em um navegador e há espaço para uma arquitetura mais eficiente.

Resumindo, eu sei que todos estão ocupados no WinUI 3.0 no momento. Mas quando terminar, seria ótimo se conectássemos @jeromelaban https://github.com/jeromelaban , @ marb2000 https://github.com/marb2000 , @jevansaks https://github.com/jevansaks e outros para descobrir a melhor maneira de fazer UWP renderizar em todos os lugares. Essa também seria uma discussão da comunidade muito interessante para uma chamada futura.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLCHIRMGIIB4EEMXQATQSRJSPA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDNI2QA#issuecomment-551193920 , ou unsubscribe https://github.com/ notificações / unsubscribe-auth / AD3GCLCAZIOGVET6CJKLKLTQSRJSPANCNFSM4ICOLUJQ .

WinUi é o único caminho sensato que leva à sobrevivência de Neo e Duo

Eu tendo a concordar, mas obtendo a mesma IU de um aplicativo do Windows, rodando no Android e no Surface Duo. Com intervenção mínima do desenvolvedor - esse é o Santo Graal.

Se o WinUI tiver alguma chance de ser uma plataforma de desenvolvimento primária e dar ao Windows a chance de se tornar apenas um receptáculo de aplicativos de outra plataforma a longo prazo. (Nem sempre é uma coisa ruim, quando se trata de grandes aplicativos estabelecidos, mas para LoB e os próximos grandes aplicativos ...)

Estou criando minha própria linguagem orientada a aplicativos e desejo oferecer suporte ao uso de WinUI com XAML e minha linguagem para code-behind. Seria bom se o conjunto de ferramentas oferecesse a capacidade de uma linguagem fornecer geração de código para o XAML. O que seria ainda melhor é se o gerador de código XAML construísse IL como uma classe parcial que poderia ser concluída usando qualquer linguagem. Isso significaria que o gerador de código geraria um assembly IL compilável.

Estou criando minha própria linguagem orientada a aplicativos e desejo oferecer suporte ao uso de WinUI com XAML e minha linguagem para code-behind. Seria bom se o conjunto de ferramentas oferecesse a capacidade de uma linguagem fornecer geração de código para o XAML. O que seria ainda melhor é se o gerador de código XAML construísse IL como uma classe parcial que poderia ser concluída usando qualquer linguagem. Isso significaria que o gerador de código geraria um assembly IL compilável.

Existe o XAML Direct, mas é compatível com C # e C ++ no momento.
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

Não é isso que quero dizer. Quero dizer que a saída da ferramenta de geração de código é IL, não C # ou C ++. Dessa forma, meu compilador pode transformar o XAML em IL e, em seguida, herdar essa classe.

@sharpninja Também seria benéfico se também pudesse gerar Bytecode LLVM em vez de apenas código C ++.

Dessa forma, podemos combiná-lo com MIDL e XLang para gerar a biblioteca COM e arquivos WinMD para usar em todos os cenários suportados por XLang.

Com o meu chapéu C ++ colocado, o que eu gostaria de ver em relação às ferramentas WinUI para C ++, seria que a Microsoft finalmente acompanhasse o que o C ++ Builder tem feito desde meados dos anos 90.

Fornece ferramentas RAD reais para desenvolvimento baseado em C ++.

C ++ / CLI falhou perto disso, embora com os formulários houvesse algumas soluções alternativas.

C ++ / CX parecia que sim, mas exigia um pouco mais de esforço do que o C ++ Builder é capaz.

Agora, C ++ / WinRT pode ser o padrão C ++ 17, mas a experiência geral para desenvolvedores de desktop parece um downgrade, com o aumento do clichê que é preciso escrever manualmente, cuidado adicional como os tipos COM ultrapassam o limite ABI e falta de designer Apoio, suporte.

Portanto, ainda estou usando C ++ / CX por enquanto, pois não quero lidar com todos os clichês exigidos pelo compilador MIDL e pelo suporte COM ABI.

Por outro lado, com meu chapéu .NET ativado, gostaria de ver apenas bibliotecas C ++ como DirectX serem finalmente expostas como componentes WinUI, um pouco de amor do Blend, e lembrando que F # supostamente também é uma linguagem .NET da Microsoft.

Tive muita dificuldade tentando mudar para WinUI. Existem várias bibliotecas de 1ª e 3ª partes que não estão usando o WinUI no momento e as dependências delas se tornam problemáticas. Por exemplo, o SDK do Behaviors.

Esta é uma ideia que tive enquanto falava sobre o StatusBar no UWP Community Discord.

No Visual Studio, faça com que a caixa de ferramentas inclua entradas para controles WPF que estão faltando no UWP e, quando essas entradas forem selecionadas, mostre um pop-up explicando como simular o controle tradicional.

Essa ideia vem do desejo de facilitar a transição para pessoas que vêm do WPF (ou outras estruturas), onde esperam ver determinados controles, e não encontrá-los pode ser uma experiência chocante. Como saber se o CommandBar pode ser usado como o StatusBar? Acho que precisamos tornar o mais simples possível para as pessoas migrarem para o WinUI. Isso pode servir para preencher algumas lacunas sem ter que realmente desenvolver todos os controles ausentes.

EDITAR:
E para completar, aqui está outra coisa que eu disse sobre a barra de status .. apenas mostrando como alguém pode abordar UWP (ou WinUI) se não estiver familiarizado com ela ..

Re: StatusBar - Eu estava pensando da perspectiva dos usuários de frameworks tradicionais tentando UWP - e vendo que ele não tem StatusBar - ainda é um grampo em muitos aplicativos. Sim, CommandBar pode ser ainda melhor. Mas as pessoas não sabem o que é um CommandBar ou podem imaginar que seja outra coisa. Alguém acima até sugeriu que eu adicionasse uma grade, colocasse na parte inferior, aumentasse uma linha e adicionasse vários controles para exibir as coisas. Portanto, parece que mesmo os designers Xaml existentes não sabem sobre CommandBar. De qualquer forma, talvez você esteja certo, talvez CommandBar seja melhor, mas Paul Thurrot não o usou em seu aplicativo de bloco de notas UWP, ele usou uma grade. Portanto, parece que o CommandBar não está sendo comunicado como o substituto do StatusBar. Desenvolvedores casuais (ou novos) ainda estão procurando pelo StatusBar e não o encontram. Eu sei que Paul Thurrot não é desenvolvedor, mas você entendeu.

Seria ótimo se snippets também fossem injetados no xaml com um caso de uso normal.

De: Gavin-Williams [email protected]
Enviado: terça-feira, 18 de fevereiro de 2020 19:05:39
Para: microsoft / microsoft-ui-xaml [email protected]
Cc: The Sharp Ninja [email protected] ; Mencione a mençã[email protected]
Assunto: Re: [microsoft / microsoft-ui-xaml] Ferramentas e experiência do desenvolvedor WinUI 3.0 - entrada necessária (# 1045)

Esta é uma ideia que tive enquanto falava sobre o StatusBar no UWP Community Discord.

No Visual Studio, faça com que a caixa de ferramentas inclua entradas para controles WPF que estão faltando no UWP e, quando essas entradas forem selecionadas, mostre um pop-up explicando como simular o controle tradicional.

Essa ideia vem do desejo de facilitar a transição para pessoas que vêm do WPF (ou outras estruturas), onde esperam ver determinados controles, e não encontrá-los pode ser uma experiência chocante. Como saber se o CommandBar pode ser usado como o StatusBar? Acho que precisamos tornar o mais simples possível para as pessoas migrarem para o WinUI. Isso pode servir para preencher algumas lacunas sem ter que realmente desenvolver todos os controles ausentes.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLGYERSFO7LBXKWBBRDRDSAWHA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMF6O3Y#issuecomment-587982703 , ou unsubscribe https://github.com/ notificações / unsubscribe-auth / AD3GCLFLGA773XOS5OSG5ULRDSAWHANCNFSM4ICOLUJQ .

A história do desenvolvedor deve incluir uma espécie de lista de comparação.

Conceitos que são intrínsecos aos aplicativos Win32, então Barras de status, barras de ferramentas, menus, garras, guias, etc. em uma lista e os equivalentes WinUI na outra.

A própria página, incluindo exemplos de código de ambos, para mostrar como a IU de um aplicativo existente pode ser movida para o WinUI.

Pergunta (s) Aberta (s)
Seria benéfico se fornecêssemos uma ferramenta de migração que automatizasse as etapas 1-3?

sim. Eu suporte 1 aplicativo Windows Forms "legado" (legado significa nenhum orçamento para reescrever) e 2 ou 3 aplicativos WPF legados. O aplicativo WinForms pode estar bloqueado, mas uma ferramenta para ajudar a portar os aplicativos WPF rapidamente para o WinUI 3 seria ótimo!

MSIX é o método de empacotamento moderno para todos os aplicativos. Para WinUI no Win32, devemos oferecer suporte ao ClickOnce? Para quais outros métodos de embalagem devemos incluir suporte? Especialmente para WinUI no Win32

Atualmente, usamos ClickOnce para publicar aplicativos nas áreas de trabalho de nossos usuários. Algum modelo de atualizações automatizadas ainda seria desejado.

@JeffSchwandt

Essas etapas foram em relação à conversão de projetos WinUI usando versões anteriores (1-2) para a versão 3.

Converter um aplicativo WPF em um WinUI não é particularmente viável de forma automatizada (sem uma enorme quantidade de esforço, mas mesmo assim seria extremamente sujeito a erros).

Espero que este seja o tópico certo para postar este pedido.

Rust está precisando desesperadamente de uma estrutura de interface do usuário adequada agora. Seria bom se o WinUI pudesse dar suporte ao Rust no futuro com um SDK nativo e algumas ferramentas.

Espero que este seja o tópico certo para postar este pedido.

Rust está precisando desesperadamente de uma estrutura de interface do usuário adequada agora. Seria bom se o WinUI pudesse dar suporte ao Rust no futuro com um SDK nativo e algumas ferramentas.

Boas notícias, o Rust / WinRT está em desenvolvimento, o que permitirá que aplicativos Rust usem APIs do WinRT como o WinUI! Dê uma olhada em https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/

@jevansaks Ei, obrigado pela resposta! Sim, eu sei que Kenny trabalha em Rust / WinRT, mas eu me pergunto se WinRT é a única camada de API que o WinUI suporta? Não tenho certeza de como isso se encaixaria no fato de que o uso da API WinRT de aplicativos de desktop tornou-se disponível apenas no Windows 10 1903, enquanto o WinUI visa oferecer suporte a versões mais antigas do Windows 10.

Rust / WinRT (como C ++ / WinRT) deve funcionar até o Windows 7. O próprio WinRT sempre funcionou em aplicativos de desktop / win32. Apenas certas APIs tinham requisitos de armazenamento / uwp / empacotamento (não o WinRT como um todo). Contanto que o WinUI não tenha esses requisitos, você poderá usar o WinUI a partir de aplicativos de desktop via C ++ / WinRT e Rust / WinRT em qualquer plataforma compatível.

Os aplicativos de desktop WinUI devem oferecer suporte a blocos dinâmicos e atualização de blocos - com bons exemplos simples e ferramentas SDK para criar blocos com mais facilidade do que os aplicativos UWP atuais.

Não tenho certeza de como isso se encaixaria no fato de que o uso da API WinRT em aplicativos de desktop tornou-se disponível apenas no Windows 10 1903

O WinUI Desktop está sendo projetado para WinUI 3.0 agora, e isso deve permitir que aplicativos Win32 simples usem WinUI de nível inferior (o plano atual é de 1803).

A IU do Windows deve suportar pelo menos os principais frameworks MVVM - MVVM Light, Prism e Caliburn. Infelizmente, seu problema documentado com alterações em INotifyPropertyChanged e INotifyCollectionChanged quebrando ObservableCollectioncertamente quebra o MVVM Light, e provavelmente os outros dois frameworks também. Achei que você deveria saber.

Infelizmente, seu problema documentado com alterações em INotifyPropertyChanged e INotifyCollectionChanged quebrando ObservableCollection certamente quebra o MVVM Light, e provavelmente as outras duas estruturas também. Achei que você deveria saber.

Obrigado @terrycox! Estamos cientes e isso será resolvido pelo WinUI 3.0 RTM e, de preferência, em uma versão de visualização antes disso;)

A IU do Windows

Sim, deve corrigir problemas documentados, mas não há necessidade de uma biblioteca .Net UI, incluindo WinUI, para oferecer suporte a uma estrutura MVVM. Ele só precisa oferecer suporte a objetos que representam elementos de interface do usuário. Um MVVM .Net ou estrutura reativa é uma maneira de gerar e alterar objetos .Net que representam a IU com base em objetos que representam dados. Nenhum precisa saber sobre o outro. Qualquer estrutura pode ser combinada com qualquer biblioteca de IU.

mas não há necessidade de uma biblioteca .Net UI, incluindo WinUI, para suportar uma estrutura MVVM.

Mas coisas como eventos e interfaces dos quais o UIElements está ciente são necessários e foi isso que quebrou.

De: Charles Roddie [email protected]
Enviado: quarta-feira, 25 de março de 2020 14:28:46
Para: microsoft / microsoft-ui-xaml [email protected]
Cc: The Sharp Ninja [email protected] ; Mencione a mençã[email protected]
Assunto: Re: [microsoft / microsoft-ui-xaml] Ferramentas e experiência do desenvolvedor WinUI 3.0 - entrada necessária (# 1045)

@terrycox https://github.com/terrycox A IU do Windows deve suportar pelo menos as principais estruturas MVVM - MVVM Light, Prism e Caliburn. ... seu problema documentado

Sim, deve corrigir problemas documentados, mas não há necessidade de uma biblioteca .Net UI, incluindo WinUI, para oferecer suporte a uma estrutura MVVM. Ele só precisa oferecer suporte a objetos que representam elementos de interface do usuário. Um MVVM .Net ou estrutura reativa é uma maneira de gerar e alterar objetos .Net que representam a IU com base em objetos que representam dados. Nenhum precisa saber sobre o outro. Qualquer estrutura pode ser combinada com qualquer biblioteca de IU.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-604040104 ou cancele a inscrição https://github.com/notifications/unsubscribe-auth/ AD3GCLASFGPUSCRG5PFKOOTRJJLO5ANCNFSM4ICOLUJQ .

As ferramentas Dotnet cli devem ser usadas junto com a. Net core sdk.
Comandos como dotnet new e dotnet build devem ser suficientes, sem dependência rígida de instalação do Visual Studio. Por favor, junte-se totalmente ao .Net Core Era!

• Será bom se o designer xaml for rápido. O designer XAML atual é lento e sempre gera algum erro dizendo que alguma exceção ocorreu e não funcionará. Por favor, corrija isso e forneça um designer robusto.

• atualmente o uwp não tem APIs que possam detectar a tela de bloqueio. Será bom se tivermos APIs que podem detectar lockscreen e fornecer booleanos como valores de retorno. Também devemos ser capazes de exibir algumas animações e emblemas após bloquear ou desbloquear.
  - API lockscreen existente

• Meu problema explicado

Seguindo as linhas do comentário de

Gostaria de ver um modelo de aplicativo que cria um aplicativo .NET 5 com interface do usuário WinUI 3.0 que faz referência a um aplicativo de host de armazenamento .NET 5. Isso permitiria menos instalações redundantes do .NET 5.0

Em um aplicativo de desktop WinUI, como ir de muxc.Window.ThisPtr para um hWnd para a janela Win32 nativa?

Acabei de experimentar os novos modelos de maio de 2020 para WinUI 3 Preview 1 para Desktop porque gosto da ideia.

Mas eu tenho uma pergunta. Com o WinUI sendo a plataforma de interface do usuário nativa no Windows, estou surpreso com a falta de comunicação para que ele realmente faça parte do Windows 10 também.

Meu aplicativo Hello World resultante tinha cerca de 120 MB. Claro, o espaço é barato, mas eu não tinha dependências sozinha aqui. Disto, o WinUI consumiu uma quantidade considerável de espaço, quase tanto quanto o próprio .NET 5 incluído. Isso é apenas para a construção x64. Inclua o x86 em um pacote multiplataforma e dobre esse tamanho. Adicione algumas outras dependências e poderemos facilmente estar olhando para um aplicativo de 300 MB para empacotar para distribuição.

Por que o WinUI 3 não é simplesmente parte da edição do Windows do .NET 5? Isso faz parte do esforço de modularização do .NET Core? Mas se não, onde é o lugar para isso? Verdadeiramente insidioso em todas as pastas de aplicativos? Como a interface de usuário oficial do Windows 10 ...?

Ou fará parte do Windows 10 no futuro? Se o WinUI fosse tratado mais como uma biblioteca de sistemas e o .NET 5 começasse a ser fornecido com o Windows mais tarde, estaríamos olhando para aplicativos comparativamente pequenos. Mas espero que esta seja exatamente a história do Windows 10X, pelo menos, e talvez também do Windows 10 não-X mais tarde? Excluindo essas duas bibliotecas, bem como a DLL de ponte C # / WinRT do Windows 10 SDK, o tamanho do aplicativo cai para 1-5 MB.

@ryandemopoulos disse no Discord que o WinUI será entregue como um pacote de estrutura, portanto, os aplicativos que usam a Store ou MSIX para distribuição não terão que carregar sua própria versão do WinUI, pois todos compartilharão a mesma cópia dele.

Tornar o WinUI parte do próprio Windows iria derrotar o ponto de o WinUI ser desacoplado do sistema operacional.

"Disponível de forma confiável e não no tamanho do aplicativo" é a preocupação. Espero que o .NET 5 seja distribuído de forma semelhante.

@lmcdougald Eu convido você a abrir um problema no .NET Core Installer e solicitar que o .NET 5 use o Framework Packaging para manutenção também.

@jonasnordlund há outra discussão # 2500 onde estamos falando sobre a implantação do WinRT Runtime. Talvez você encontre alguma resposta aí. :)

@ marb2000 Eu abri um problema, mas estou honestamente perplexo. Isso não é visto como essencial para qualquer aplicativo que forneça o Windows 10X?

Aqui está uma compilação de vários recursos, alguns dos quais não são diretamente WinUI, mas sua falta afeta diretamente a experiência de qualquer desenvolvimento de cliente .NET - clientes UWP incluídos e, especialmente, clientes de aplicativos LoB.

• A primeira e mais importante prioridade para mim é que você alimente a Plataforma Uno. Para mim, é o que torna o UWP relevante, eu teria comprometido o XF ou outra tecnologia se o Uno não estivesse por perto. (https://github.com/microsoft/microsoft-ui-xaml/issues/2024)
• API abstrata de gerenciamento de identidade do lado do cliente a ser usada no ViewModel (https://github.com/microsoft/ProjectReunion/issues/31)
• Suporte completo para anotações de dados, validações e títulos de IU, comprimentos de strings, atributos obrigatórios, campos somente leitura, marcas d'água etc. etc. etc. (https://bit.ly/3gcMJ3a)
• Melhore o OData para que se torne uma alternativa adequada ao que costumavam ser os serviços RIA. Por exemplo: suporte à geração de atributos, implementações de interface, tipos genéricos, documentos XML (https://github.com/OData/odata.net/issues/1746)
• Traga todos os recursos ausentes do WPF
• x:Bind também deve ter todos os recursos que Binding possui, como escopos ou associações aninhadas (https://github.com/microsoft/microsoft-ui-xaml/issues/2237)
• Reinicialização a quente (https://github.com/microsoft/ProjectReunion/issues/44)
• Mais do que simples templates Hello World. Como tal, que acomoda login de usuário, MVVM, roteamento, projetos x-plat (como Uno-Platform), etc. Em outras palavras, dê mais poder ao WTS.
• Recursos de layout do editor XAML WYSIWYG como em WinForms, como encaixe, espaçamento, etc. - isso parece estar concluído! ❤

Obrigado pela sua compilação @weitzhandler , muito conveniente.

A equipe WinUI tem um ótimo relacionamento com a equipe de produto Uno (não Microsoft), Xamarin Forms / MAUI team e React Native. Colaboramos ativamente com eles e desejamos a eles um futuro de sucesso.

Sobre os recursos do WPF ausentes, você pode listar os principais, por favor? Fechar a lacuna entre o WPF e o WinUI é um dos nossos objetivos. No entanto, serão necessários vários lançamentos.

A propósito de modelos mais complexos. O Window Template Studio tem essa missão.

Eu fiz um problema para tentar reunir áreas onde WinUI está faltando em comparação com WPF # 719 @weitzhandler @ marb2000

A propósito de modelos mais complexos. O Window Template Studio tem essa missão.

@ marb2000 podemos trazer o Window Template Studio para o nosso VSIX? Ou talvez vice-versa? Basta usar o Window Template Studio como o veículo para enviar todos os modelos WinUI3 (e Project Reunion) daqui para frente?

A propósito de modelos mais complexos. O Window Template Studio tem essa missão.

@ marb2000 podemos trazer o Window Template Studio para o nosso VSIX? Ou talvez vice-versa? Basta usar o Window Template Studio como o veículo para enviar todos os modelos WinUI3 (e Project Reunion) daqui para frente?

👀 @crutkas @sibille

Eu sugiro passar algum tempo com C ++ Builder (VCL / FMX) e Qt Creator / Design studio, para aprender o que é possível com C ++ e ferramentas modernas.

Idealmente, o WinUI ofereceria ferramentas semelhantes a esses produtos já oferecem hoje para GUIs de plataforma cruzada escritas em C ++.

O que me interessa é a experiência de desenvolvimento .NET e ter uma experiência semelhante para os casos de uso que sou forçado a usar C ++, que por qualquer motivo não estão disponíveis para nós.

O C ++ Builder e o QtCreator alcançam essa experiência e seria bem-vindo se os desenvolvedores .NET pudessem se sentir em casa quando precisassem passar alguns dias escrevendo código C ++ / WinRT.

Por que fazer isso sobre desenvolvedores .NET? A experiência C ++ XAML é simplesmente ruim, não importa se você é um desenvolvedor C ++ ou .NET.

Acredito que será ótimo se eles abrirem caminho para permitir que o mesmo XAML seja executado em Desktop, Web (Edge), Mobile e IoT.

Quando poderemos usar o WinUI 3 em um projeto c ++ sem C #, Xaml ou um designer?
também há alguma notícia sobre a data de abertura do código-fonte do núcleo c ++ do WinUI 3?

Edit: Acho que obtive uma resposta para minha primeira pergunta, parece que há um modelo de projeto c ++ WinUI 3 no WinUI 3.0 Preview 1 :

Depois de instalar a extensão .vsix, você pode criar um novo projeto WinUI 3.0 procurando por "WinUI" e selecionando um dos modelos C # ou C ++ disponíveis.

O caso de uso que eu adoraria que o WinUI melhorasse é fazer pequenas ferramentas baseadas em GUI para a equipe de suporte de TI da linha de frente, que geralmente são escritas em PowerShell. Seria ótimo poder fazer esses tipos de ferramentas no Visual Studio Code. Mesmo uma opção de desenvolvimento de VSCode baseada em C # seria um grande passo. O Visual Studio desenvolvido parece bastante pesado e complexo para este caso.

Atualmente, os ambientes empresariais estão usando ferramentas como estas:

• https://poshgui.com/ (assistente XAML baseado na web)
• Sapien PowerShell Studio 2020 (proprietário)
• Editor de scripts administrativos (ASE) (um projeto agora abandonado)

Outros padrões comumente usados ​​de "usar Visual Studio para o XAML" são descritos aqui:

• Crie uma interface gráfica simples para um script PowerShell
• Como construir uma interface gráfica do usuário do PowerShell para seus scripts

Minha pergunta está no contexto da pergunta @mqudsi que ele fez em maio, mas ninguém respondeu.

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

Como este é um aplicativo de desktop, não podemos usar ICoreWindowInterop e eu tentei ganhos aleatórios como new HandleRef(this, ThisPtr) onde 'this' é do tipo Microsoft.UI.Xaml.Window, mas continuo vendo o errno para Invalid Window Handle. Assim que obtiver esse hwnd, posso tentar usar mais COM para alterar o estilo da janela e compartilhar com outras pessoas, para que não sintam a mesma dor que estou sentindo agora :).

Para qualquer pessoa interessada, esta é a abordagem rápida que usei para pegar o hWnd da janela principal para que pudesse torná-la sem bordas. A solução completa para WPF equivalente a WindowStyle = None está aqui .

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

No momento, não parece haver uma maneira fácil de localizar / documentar para obter o hWnd quando o WinUI está em um processo de desktop, por isso mudei para a abordagem que usei. Parece funcionar bem o suficiente.

Acho que talvez UWP e Universal Windows como termos devam ser eliminados. Os termos carregam uma bagagem infeliz que leva os desenvolvedores a se esquivar.

Talvez pudéssemos substituir o template WinUI (Universal Windows) por WinUI (Win64)? Então tem a opção de Desktop ou Store?

Win64 é confuso - isso implicaria que a API do Win32 suporta apenas 32 bits e que, ao contrário, o UWP suporta apenas 64 bits, ambos falsos.

O nome Win32 por si só já confunde muitos iniciantes, não precisamos do Win64 para piorar as coisas.

@VagueGit algo que aprendi é que escolher o nome certo e elaborar a história é uma das coisas mais complicadas. Melhor do que substituir um nome, nós (Microsoft) devemos fornecer o produto (e a história) certos para ajudá-lo a ter sucesso. UWP é uma terminologia conhecida como Win32, portanto, devemos continuar a usá-la.

Esta é a nossa abordagem (muito simplificada):

O WinUI pode ser usado em dois "tipos" de aplicativos que visam dispositivos diferentes:

• Seu aplicativo é direcionado a muitos dispositivos com muitas entradas e fatores de forma. Em seguida, use UWP. O UWP foi criado para isso; portanto, você deve atender a requisitos como modelo de embalagem, loja, modelo de aplicativo, contêiner de segurança, etc.
• Seu aplicativo se destina apenas a desktops e requer acesso total ao sistema operacional. Use Win32 ou Desktop (que é como o Visual Studio chama WPF, WinForms, MFC, aplicativos).

WinUI em aplicativos UWP e WinUI em aplicativos Desktop (ou aplicativo UWP WinUI ou aplicativo Desktop WinUI) se adaptam melhor ao objetivo do modelo de projeto.

@ marb2000 Nomear as coisas é difícil, concorda. Mas alguns nomes infelizmente são tóxicos e devem ser deixados para trás. É por isso que de vez em quando os produtos são reformulados. UWP é um, mas é apenas minha opinião ... e todos com quem falo. Mas aí está.

Temos um aplicativo UWP que queremos migrar para o WinUI. Não usamos a API Win32, apenas direcionamos o desktop e não queremos usar a loja. Como isso se encaixa?

@ marb2000 Nomear as coisas é difícil, concorda. Mas alguns nomes infelizmente são tóxicos e devem ser deixados para trás. É por isso que de vez em quando os produtos são reformulados. UWP é um, mas é apenas minha opinião ... e todos com quem falo. Mas aí está.

Temos um aplicativo UWP que queremos migrar para o WinUI. Não usamos a API Win32, apenas direcionamos o desktop e não queremos usar a loja. Como isso se encaixa?

Para quem é o aplicativo, exatamente?

Como um consumidor que se esforça para usar aplicativos UWP, se o aplicativo não estiver na loja, provavelmente não vou tocá-lo, muito menos vê-lo.

Não se preocupe, @shaheedmalik , não

Portanto, sabemos que existe um mercado para aplicativos de negócios Win64 e acreditamos que estamos entre os poucos desenvolvedores de negócios que entregaram aplicativos Win64 pelos quais os clientes empresariais pagarão. Eu sei que existem alguns desenvolvedores neste segmento que seguem a rota universal do Windows / multiplataforma, mas eles são muito raros. A maioria dos desenvolvedores de negócios em minha experiência visa um fator de forma específico.

Falando da perspectiva de uma empresa de desenvolvimento que investiu pesadamente em UWP e fez sucesso de negócios com UWP, talvez modelos para WinUI (Desktop) e WinUI (Store)? Você só precisa seguir a mídia de tecnologia para ter uma ideia de como a UWP é vista mal como uma plataforma de desenvolvimento.

@VagueGit
"Temos um aplicativo UWP que queremos migrar para o WinUI. Não usamos a API Win32, apenas direcionamos o desktop e não queremos usar a loja. Como isso se encaixa?"

Então, você deseja migrar um UWP para WinUI 3 e implantar fora da Loja? Uma pergunta ingênua: você tentou do MSIX sideload ? Algum motivo além da Loja que impede você de usar UWP?

@VagueGit
"Portanto, sabemos que existe um mercado para aplicativos de negócios Win64."

Uma pergunta: Win64 significa muitas coisas. por exemplo, aplicativos compilam para x64. O que Win64 significa para você?

@ marb2000 UWP tem suporte insuficiente para relatórios de negócios. Acreditamos que a reformulação da marca pode ajudar a iniciar o desenvolvimento de ferramentas de terceiros, como redatores de relatórios. Jogamos com o carregamento lateral, mas não foi viável para nós até 20H1, pois o carregamento lateral não estava habilitado por padrão.

Achamos que o Win64 é o caminho a seguir no Windows. No passado, a Micro $ tentou lançar o Win32 como legado sem sucesso e agora está voltando a essa posição. Mas, no final das contas, o Win32 tem que ir embora, em nosso julgamento (eu digo isso depois de 30 anos de desenvolvimento do Win32). Conseguimos superar a maioria das limitações do UWP para fornecer um aplicativo de negócios que as empresas irão comprar. Estamos preocupados que outra iteração do UWP terá tração limitada sem rebranding.

Como mostra a confusão de @ marb2000 , o termo Win64 já é (mal) usado. Eu também indiquei isso antes.

Eu concordo que um rebranding pode ser necessário, mas Win64 é uma maneira terrível de fazer isso. Até que haja algo oficial, você deve usar o termo UWP para ser compreendido por todos.

@sylveon UWP é considerado por todos como um fracasso. Nós gostamos, mas poucos outros gostam. É por isso que o rebranding é importante. O que você acha do WinUI (Deskop) ou WinUI (Store) como modelos de projeto?

WinUI (Store) não é bom porque você também pode enviar aplicativos Win32 na loja ou enviar aplicativos UWP fora da loja. WinUI (Desktop) é bom, entretanto.

@sylveon WinUI (Loja) não impede outros projetos que visam a loja. Significa apenas que você deseja começar com o conjunto de recursos que permitem a liberação na loja.

É ruim o suficiente para confundir iniciantes.

Isso não deve ser direcionado a nenhuma pessoa em particular neste tópico, mas sim à minha própria opinião como desenvolvedor de aplicativos de desktop / proprietário de empresa.

Nunca fico preso ao nome de uma coisa. Eu só me importo com quais recursos ele tem e quão bem é suportado.

Eu diria que também há muitos desenvolvedores (incluindo eu) que ficam entusiasmados quando usamos termos como MAUI, mas ficam imediatamente desapontados quando percebemos que ainda é a mesma base de código. A reformulação da marca sugere “olha, estamos construindo essa coisa totalmente nova que começa a partir de uma base de código que é totalmente diferente daquela que bloqueou você de xyz”. O que eu AMO ver é uma lista enorme de recursos que mudaram e compensaram as dificuldades que eu ou qualquer outra pessoa tivemos.

As plataformas se desenvolvem com o tempo, assim como qualquer produto ou marca. Eu encontro conforto em marcas e nomes que existem há décadas porque automaticamente implica LTS. Embora eu saiba que as mudanças de nome às vezes são uma necessidade, eles também lembram os desenvolvedores do abandono (Silverlight). Existem muitos modelos de automóveis que tiveram anos em que foram atormentados por problemas, mas acabaram se tornando marcas de amor e respeitadas. Há muito o que dizer com familiaridade, mesmo que você não goste das experiências anteriores, porque sabe o que esperar. Contanto que os problemas sejam resolvidos, isso é o que realmente conta.

Acho que há pelo menos dois públicos que precisam ser considerados; desenvolvedores e usuários de produtos finais. Como desenvolvedor / proprietário de empresa, se eu tenho um cliente que precisa de um aplicativo e ele se sente prejudicado por nomes de tecnologia subjacentes, é meu trabalho incutir confiança neles de que o produto representado pelo nome amadureceu e o que os preocupa no passado foi atualizado. Por outro lado, se eu disser “olha, há uma coisa nova chamada WinUI ou MAUI” e eles já possuem produtos WPF ou UWP ou Xamarin que desenvolvemos para eles, uma resposta previsível deles é “ótimo, agora nossos aplicativos são escritos em 2,3 ou 4 tecnologias diferentes ”. É aqui que terei de vendê-los. Considerando que todos os clientes são diferentes, encontrarei resistência, independentemente de você deixar o nome como está ou alterá-lo.

O que é importante no final (para mim) é que temos as ferramentas de que precisamos para escrever aplicativos atraentes e ricos em recursos que tenham LTS. Eu fico entusiasmado quando vejo um produto atingir os prazos e leio o novo recurso e a lista de resolução de problemas quando o produto é lançado. Eu adoro isso sobre NetCore / Net5 (mudança de nome LOL) desde 2016. (A propósito, tentar dizer aos meus clientes que .Net5 é o que planejamos atingir um ano depois de convencê-los a mudar para NetCore também não é fácil!)

No momento, só quero avançar para o ponto em que posso escrever um aplicativo de desktop com o dialeto XAML e obter o mesmo desempenho de renderização que o UWP / WinUI oferece (sem a sandbox UWP). Por esse motivo e devido à queda da prévia de setembro, vou começar o teste de direção do Avalonia. Eu amo as semelhanças do WPF enquanto ouço sobre o desempenho de renderização via SkiaSharp.

Será emocionante em alguns anos, quando as opções para o desenvolvimento de IU se estabilizarem. Eles podem nomear modelos de projeto como quiserem, isso não mudará minha opinião sobre a falta de recursos.

Eu agradeço a todos vocês.

Eu recebo o que jtbrower diz em seu e-mail. Sua empresa como a nossa é uma das poucas que seguiram com sucesso o caminho do xaml. Não precisamos nos convencer dos benefícios.

Mas, por melhor que seja, o xaml foi um desastre para a Micro $. A esmagadora maioria dos desenvolvedores, ou permaneceram com o WinForms, ou mudaram totalmente para o desenvolvimento web. Desde a UWP, o êxodo de desenvolvedores piorou.

Para que as tecnologias xaml sejam sustentáveis, a Micro $ deve conquistar os milhões de desenvolvedores que não conseguiram integrar. Para esses desenvolvedores, fornecedores de ferramentas e mídia de tecnologia, o UWP é um beco sem saída. Outra iteração do UWP não os conquistará.

@VagueGit, mas os desenvolvedores estão interessados ​​o suficiente para saber que um produto renomeado é o mesmo. Eles conhecem o MAUI como um Xamarin Forms renomeado. Na verdade, eles parecem ir tão longe para dizer que MAUI era um nome roubado. Eu não acho que você pode motivar um desenvolvedor típico com uma mudança de nome. Todos nós queremos recursos, não é? Você não prefere ver o UWP permitir várias janelas ou permitir confiança total? Se eles fizessem as duas coisas, todos poderíamos ter como alvo o UWP e talvez manter a sandbox para aplicativos de loja. Estou apenas sonhando em voz alta o que realmente me deixaria empolgado! Recursos!!

Concordo absolutamente com você, jtbrower. Também agradeço sua ajuda e espero que outros critiquem suas idéias. Mas como sinalizar para desenvolvedores e fornecedores de ferramentas que existem dois UWPs diferentes, Store e Desktop?

Portanto, sem dúvida, aqueles que desejam continuar no caminho UWP podem começar com o modelo de armazenamento UWP, mas aqueles que desejam uma área de trabalho de 64 bits, não em área restrita e confiança total ... bem, isso não é UWP, certo?

A UWP é vista no mercado como deficiente. Todos, exceto nós, os obstinados desistiram da UWP quando a própria Micro $ desistiu de construir seus próprios aplicativos na UWP.

O mercado de desenvolvimento não está atento a desenvolvimentos em UWP. Desktop de 64 bits, sem área restrita e confiança total, é muito mais do que uma mudança de nome; é um paradigma diferente. Mas se ainda for chamado de UWP, passará despercebido por aqueles que cancelaram o UWP.

@VagueGit Fico feliz que você tenha obtido sucesso com a UWP. Nomear é difícil, e o fato de chamá-lo de "Plataforma Universal do Windows" e não ser realmente sustentável pela grande maioria dos desenvolvedores do Windows o torna, bem, não muito "universal". Um resumo preciso do Project Reunion é corrigir isso e tornar todos os aspectos da UWP verdadeiramente acessíveis a todos os desenvolvedores do Windows.

Eu concordo que UWP tem um nome ruim. Se você digitar a frase "UWP é" em um mecanismo de pesquisa, a primeira sugestão automática que o Bing ou o Google fornecerá é "UWP está morto". No entanto, acho que @ marb2000 está certo que devemos continuar a usar o nome, apesar da bagagem que ele carrega.

Com isso dito ...

Hoje, muitos aspectos dos projetos de desktop serão capazes de usar diferentes partes do que costumávamos definir como "UWP":

1. A pilha da IU (também conhecida como WinUI3)
2. Embalagem MSIX
3. Recursos MRT

Depois que o CoreApplication for eliminado, a única diferença entre o UWP e o Desktop será realmente o modelo de sandbox que você escolhe para o seu aplicativo e quais dispositivos você pode direcionar.

Discutimos fazer modificações nos modelos de projeto e ter uma experiência semelhante a um assistente que descreve isso com mais precisão.

@JeanRoca é o PM que está conduzindo isso e pode ter mais informações para compartilhar

Eu gosto da ideia do template WinUI Desktop. Mais apropriado do que Win32 e voltado para o futuro. É o modelo com o qual começaríamos, enquanto o Win32 sugeriu uma restrição de 32 bits. Esperançosamente, o WinUI Desktop terá alguma influência na mídia e entre os desenvolvedores.

Quando um aplicativo UWP é lançado fora da loja, o pacote é .appinstaller. Se atualizarmos esse aplicativo para Win UI Desktop, o pacote do instalador muda de appinstaller para msix.

Supondo que mantenhamos os mesmos detalhes no pacote do aplicativo e alteremos a versão de forma adequada, o Windows reconhecerá que esta é uma nova versão do mesmo aplicativo e preservará os dados locais ou irá instalá-la como um aplicativo diferente?

Do meu entendimento, WinUI 3.0 nunca será consumido do .NET Framework <= 4.8. Portanto, se estamos falando sobre WinUI, estamos falando sobre .NET Native ou .NET 3.1 / 5 + (ou outro conjunto de ligações).

Alguma sugestão de como avançar / perguntar mais sobre o empacotamento do framework para .NET 5 (ou acho que 6 neste momento)? Abri um problema e não obtive resposta. Empacotar o .NET 5 no aplicativo é um obstáculo.

@stevenbrix

Depois que o CoreApplication for eliminado, a única diferença entre o UWP e o Desktop será realmente o modelo de sandbox que você escolhe para o seu aplicativo e quais dispositivos você pode direcionar.

Infelizmente, outra grande diferença é que os desenvolvedores .NET são forçados a mudar para C ++ para APIs como DirectX, cuja equipe claramente se recusa a torná-los compatíveis com UWP, apesar de serem baseados em COM.

E, no processo, volte aos dias de produtividade de escrever MIDL manualmente com uma boa experiência de bloco de notas e copiar arquivos, aparentemente a equipe do Windows não pode deixar de usar ATL como experiência de desenvolvimento, em vez de fornecer uma experiência de NET para fluxos de trabalho C ++. C ++ / CX estava ficando muito fechado para C ++ Builder, então teve que ser eliminado em nome do material ISO, para que com sorte poderíamos obtê-los em C ++ 23 e em 2025 em VS.

Duvido que alguém se importe com a UWP até lá, a menos que uma experiência de desenvolvimento adequada seja estabelecida para limpar todas essas irregularidades.

Também nos lançam questões do GitHub sobre a qual equipe dar feedback é uma maneira muito rápida de perder o interesse. Eu simplesmente me importo muito, aparentemente.

As APIs DirectX não podem ser modificadas para compatibilidade com WinRT porque seria uma interrupção significativa da API para os consumidores existentes, e isso simplesmente não pode acontecer.

Existem vários wrappers gerenciados disponíveis para DirectX, como TerraFX que é uma ligação 1: 1 bruta ou Vortice que é um wrapper de API mais no estilo C #.

Quanto ao CX, ele teve que ir embora. As extensões de linguagem específicas do compilador são ruins e desaprovadas. Isso dificulta significativamente a portabilidade do código, muitas vezes fica para trás em termos de suporte ao padrão C ++ e requer integração vertical completa de bibliotecas existentes. A alternativa, WRL, era muito difícil de usar e excessivamente prolixa. Portanto, não é surpreendente que muitas pessoas (incluindo a divisão DX) não quisessem escrever APIs do WinRT.

C ++ / WinRT é uma solução muito melhor, é uma pena que teve que trazer de volta o IDL (mas um mal necessário atualmente). A equipe C ++ tem feito um trabalho muito melhor no suporte de padrões do que antes, então não seria surpreendente se realmente obtivéssemos metaclasses antes de C ++ 23 ser finalizado, o que deve melhorar radicalmente a UX do desenvolvedor.

@sylveon

Não se surpreenda que a comunidade de desenvolvimento do Windows ignore tudo o que sai de Redmond com tal justificativa para queda de produtividade.

O mesmo estava acontecendo com o CX ... não era muito usado porque os desenvolvedores C ++ não gostam de extensões de linguagem proprietárias.

Supondo que mantenham os detalhes do pacote do aplicativo iguais e alteremos a versão de forma adequada, o Windows reconhecerá que esta é uma nova versão do mesmo aplicativo e preservará os dados locais ou irá instalá-la como um aplicativo diferente?

@VagueGit , essa é uma ótima pergunta. No final do dia, a tecnologia para instalar aplicativos UWP e Desktop é a mesma. Eu sinto que a resposta é sim? Acho que, a partir de SDKs mais recentes, até mesmo aplicativos UWP têm a extensão .msix (posso estar errado, então não me cite). Tenho certeza que você poderia tentar fazer isso localmente e descobrir? @adambraden for fyi.

Alguma sugestão de como avançar / perguntar mais sobre o empacotamento do framework para .NET 5 (ou acho que 6 neste momento)? Abri um problema e não obtive resposta. Empacotar o .NET 5 no aplicativo é um obstáculo.

@lmcdougald Acho que sei a qual problema você está se referindo (mas não consigo encontrar). Haverá um, mas imagino que será no período .net6. Todos estão cientes de que isso é algo que precisa ser feito.

E, no processo, volte aos dias de produtividade de escrever MIDL manualmente com uma boa experiência de bloco de notas e copiar arquivos, aparentemente a equipe do Windows não pode deixar de usar ATL como experiência de desenvolvimento, em vez de fornecer uma experiência de NET para fluxos de trabalho C ++. C ++ / CX estava ficando muito fechado para C ++ Builder, então teve que ser eliminado em nome do material ISO, para que com sorte poderíamos obtê-los em C ++ 23 e em 2025 em VS.

Também nos lançam questões do GitHub sobre a qual equipe dar feedback é uma maneira muito rápida de perder o interesse. Eu simplesmente me importo muito, aparentemente.

@pjmlp Agradeço sua honestidade e paixão. Eu não poderia concordar mais que a experiência C ++ atual é abaixo da média. Fizemos algumas coisas para tornar a experiência C ++ mais parecida com .NET, mas como @sylveon mencionou, elas têm um custo. Por fim, decidimos que, se quisermos investir esforços de engenharia para tornar o C ++ excelente, devemos aplicá-lo na implementação do padrão C ++. É uma pena que as metaclasses sejam uma saída, e estamos discutindo maneiras de melhorar a experiência nesse ínterim, porque concordo com você que não podemos esperar tanto tempo.

Obrigado pela resposta - estou satisfeito com “todos estão cientes de que isso é algo que precisa ser feito” e viverei com um binário inflado por mais ou menos um ano.

@stevenbrix e @VagueGit - você ainda deve ser capaz de usar um arquivo appinstaller para seus pacotes msix. o arquivo appinstaller nada mais é do que um arquivo json que fornece o uri para seus pacotes. Como você mencionou cenários corporativos, pode personalizar os uris do instalador do aplicativo de maneira adequada para locais internos ou também torná-los diferentes para acesso externo - tudo dependente de seu CDN. Com relação ao controle de versão - sim para aplicativos empacotados, se a identidade do pacote for a mesma, a instalação de uma nova versão terá acesso aos dados do aplicativo existentes.

@stevenbrix @VagueGit Vou responder com as informações que tenho atualmente sobre a experiência do assistente. Eu ainda sou muito novo nesta função, então fique à vontade para considerar tudo o que eu digo com um grão de sal. Com isso dito, minha equipe está atualmente conduzindo os esforços no Windows Template Studio . Atualmente, este aplicativo permite criar um novo aplicativo WPF ou UWP a partir de modelos existentes em nosso assistente com as páginas e estruturas que você deseja.

O objetivo e o plano atual para este aplicativo no futuro é unificar e melhorar a experiência de desenvolvimento para todos os usuários. No momento, estamos desenvolvendo modelos para aplicativos de desktop com WinUI 3. Você pode encontrar o problema de rastreamento aqui . Também estamos discutindo fazer o mesmo para UWP para que nossos usuários possam migrar facilmente seus projetos quando chegar a hora. Ainda não sabemos exatamente como isso vai funcionar, mas nosso objetivo será unificar e simplificar a experiência o máximo possível. Espero que ajude!

O mesmo estava acontecendo com o CX ... não era muito usado porque os desenvolvedores C ++ não gostam de extensões de linguagem proprietárias.

Eles os amam no clang, GCC, Intel. xlCC, PGI, CUDA, C ++ Builder e uma infinidade de plataformas embarcadas.

Obviamente, o CX foi morto devido à política que não pode aceitar um ambiente C ++ RAD vindo da Microsoft e, em vez disso, ter todos nós fazendo MDIL / ATL com uma experiência do tipo bloco de notas.

Eu os evito a todo custo, não importa o compilador. Especialmente quando a referida extensão proprietária é uma linguagem completamente diferente por si só.

Eu os evito a todo custo, não importa o compilador. Especialmente quando a referida extensão proprietária é uma linguagem completamente diferente por si só.

Então, por que codificar em uma interface de usuário proprietária como WinUI, basta usar padrões abertos como o X Windows.

... como se isso pudesse ser usado no Windows. Eu evito extensões de compilador porque desejo compiladores multitarget (Clang e MSVC) para validação de conformidade de padrões e quero usar padrões C ++ mais novos.

Meu código usa C ++ 20. Muitas extensões de linguagem não têm suporte para C ++ 17 ou o tornaram muito tarde. Essa situação se repetirá com o C ++ 20 (ou piorará, já que o C ++ 20 tem muito mais coisas novas do que o 17). Por exemplo, você não pode misturar C ++ 20 ( /std:c++latest ) e CX ( /ZW ), você obterá um erro do compilador dizendo que as duas opções são incompatíveis.

Demorou até este ano para o NVCC oferecer suporte ao C ++ 17 do lado do dispositivo. Não é uma boa aparência.

Não quero me colocar em um canto onde a extensão de idioma que uso não pode ser usada com um padrão mais recente, mas também preciso de um novo recurso padrão.

Pelas razões acima, eu as evito. Se regredirmos a experiência do desenvolvedor WinUI C ++ para uma extensão de linguagem, passarei para uma estrutura GUI alternativa.

@sylveon Você perfeitamente portátil C ++ 20 para WinUI é completamente inútil fora do Windows, vá se divertir com o Qt sem extensões também.

Porque nada mais que valha a pena ser usado é deixado para usuários de desktop C ++.

Obrigado por confirmar que a política sem sentido foi o que matou CX.

Sugestão para serem amigáveis ​​uns com os outros. Não posso comentar sobre os argumentos técnicos do c ++ e não julgarei quem está certo.
A questão é que frases como go have fun with X não estão criando um ambiente amigável e colaborativo aqui. @stevenbrix e outros, por favor,

Obrigado @hansmbakker ☺️

@pjmm e @sylveon Agradeço a conversa apaixonada e honesta, é ótimo ter clientes como você que se importam.

Ambos os pontos são extremamente válidos e acho que o mundo é grande o suficiente para que vocês dois estejam certos.

@pjmlp , não estamos satisfeitos com a experiência atual com c ++ e reconhecemos que precisamos fazer algo antes das metaclasses de c ++. Tivemos algumas discussões sobre c ++ / winrt livre de idl, e @kennykerr e @ Scottj1s fizeram uma palestra sobre o Build. A maioria dos problemas que tivemos estavam relacionados à integração com WinUI, pois nosso compilador requer metadados. Queremos revisitar este fluxo de trabalho para ver se podemos ter uma história coesa que irá melhorar a experiência geral do desenvolvedor. Em vez de trazer de volta C ++ / Cx, uma versão livre de idl de c ++ / winrt interessaria a você?

Apenas para definir as expectativas, não espero ver muito progresso aqui em 2020.

Eu estaria muito interessado em um C ++ / WinRT livre de IDL.

A experiência IDE também não é a melhor. Por exemplo, não podemos criar um retorno de chamada de evento a partir do editor XAML como fazemos com C # (a lista suspensa de criação de novo retorno de chamada não faz nada). Navegar até a definição no editor XAML também não funciona.

Outros problemas são os vários bugs do compilador XAML que preenchi neste repositório, o que me faz exigir soluções alternativas que não são exigidas em outras linguagens com suporte.

@stevenbrix , gostaria de adicionar minha voz ao C ++ / WinRT sem IDL (e certamente não quero ver um retorno ao C ++ / CX). Escrevemos software de plataforma cruzada e compilamos com MSVC e LLVM (incluindo no Windows), portanto, C ++ compatível com os padrões é muito importante para nós.

@stevenbrix ,

@pjmlp , não estamos satisfeitos com a experiência atual com c ++ e reconhecemos que precisamos fazer algo antes das metaclasses de c ++. Tivemos algumas discussões sobre c ++ / winrt livre de idl, e @kennykerr e @ Scottj1s fizeram uma palestra sobre o Build. A maioria dos problemas que tivemos estavam relacionados à integração com WinUI, pois nosso compilador requer metadados. Queremos revisitar este fluxo de trabalho para ver se podemos ter uma história coesa que irá melhorar a experiência geral do desenvolvedor. Em vez de trazer de volta C ++ / Cx, uma versão livre de idl de c ++ / winrt interessaria a você?

Apenas para definir as expectativas, não espero ver muito progresso aqui em 2020.

O que só mostra como toda essa ideia com C ++ / WinRT foi ruim para começar, puxando-a para baixo sobre nós sem qualquer consideração por nossa queda de produtividade.

Para colocar isso em perspectiva, desenvolvedor de longa data cuja experiência de desenvolvedor do Windows remonta ao Windows 3.0, e hoje em dia C ++ é mais relevante para ser usado junto com aplicativos baseados em .NET, nunca sozinho.

As ferramentas da Borland eram meu pão com manteiga até que, por vários motivos conhecidos pelos desenvolvedores do Windows antigos, o caminho a seguir acabou sendo migrar para os compiladores da Microsoft.

O Visual C ++ nunca foi _Visual_ como C ++ Builder, nem mesmo com C ++ / CLI, dada a falta de integração com Forms e compilação AOT.

C ++ / CX parecia que a Microsoft finalmente tinha entendido, 25 anos depois teríamos os mesmos fluxos de trabalho de produtividade que usaríamos Delphi / C ++ Builder lado a lado.

Em vez disso, o que obtivemos como um movimento político para eliminar C ++ / CX sem qualquer consideração pela nossa queda de mão produtiva acenando a responsabilidade pelos recursos ausentes para ISO C ++ e WG 21, como se tudo que a equipe do Visual C ++ está tirando de nós fosse aceito pelo WG 21.

E mesmo que os recursos necessários sejam eventualmente adotados pelo ISO C ++, será 2023, 2026, ....? E aí está todo o ponto de quando esses recursos realmente serão disponibilizados para os desenvolvedores do Windows, basta olhar para o suporte de módulos. Estamos levando anos intermináveis ​​para alcançar a paridade com o que o C ++ / CX tem nos oferecido desde o lançamento do Windows 8 em 2012.

Então, dado que em 2020 não veremos nenhuma melhoria, já estamos falando de 9 anos aqui, então me desculpe se eu tendo a ficar um pouco irritado com a forma como tudo isso foi gerenciado, além de outros problemas que temos para lidar com a falha de UWP, Reunião, reinicialização do ecossistema .NET, enquanto somos solicitados a codificar como se fosse 2000 com experiência básica de bloco de notas MIDL e sopa infinita de modelos como ATL.

Então, sim, uma versão C ++ / WinRT livre de IDL, ou pelo menos uma experiência IDL com suporte total para Intellisense / Intelicode e não ter que copiar os arquivos manualmente. No entanto, isso não tirará a experiência do tipo ATL do próprio código C ++.

Do ponto de vista do desenvolvimento .NET / C ++, eu não me importo com a viagem no tempo para o passado dos frameworks Microsoft, mas sim como poderia parecer se o ponto de vista do C ++ RAD fosse levado mais a sério, infelizmente com a maneira como o C ++ / A história do WinRT foi gerenciada, e tudo o mais que está acontecendo agora com o retrocesso da UWP, eu me pergunto para onde foram "desenvolvedores, desenvolvedores, desenvolvedores".

Sinto muito se ainda parece um pouco raro, mas é assim que me sinto sobre minha queda de produtividade quando preciso sair do .NET para o C ++, em nome de alguma pureza ISO que a maioria dos compiladores C ++ não faz de qualquer maneira.

C ++ ainda é muito relevante autônomo. Muitos aplicativos são escritos em C ++ bruto, sem nenhum código gerenciado em execução. Na verdade, todo o tempo de execução UWP e a estrutura XAML / WinUI é C ++ nativo. Um aplicativo UWP escrito em C ++ (felizmente) não tem nenhuma linguagem gerenciada envolvida.

Eu diria que, se você sentir a necessidade de mudar para C ++ no .NET, deve se perguntar por que e tentar resolver esses problemas diretamente no .NET. Atuação? Use os tipos de span, stackalloc e intrínsecos de vetor. DirectX, APIs nativas ou COM? Use uma ligação como TerraFX. Interagindo com uma biblioteca somente C ++? Reimplemente o que você precisa dele no .NET.

O .NET fica melhor sem o C ++, e o C ++ fica melhor sem o .NET.

Não acho que o template em cppwinrt seja tão ruim. O que mais me irrita é a necessidade de geração de código e o horrível tempo de compilação que ele produz.

@sylveon Easy, por causa das APIs que a equipe do Windows se recusa a disponibilizar como UWP e nenhuma vinculação de terceiros não conta, nem todo mundo é abençoado com um departamento jurídico que permite tudo, sem considerações de licença e problemas de suporte futuro.

Borland (agora Embarcadero), e The Qt Company mostraram como fazer isso, cabe à Microsoft decidir o quão relevante eles querem manter a plataforma.

Tente ver até onde você irá com ISO C ++ em macOS, iOS, Android, ChromeOS GUIs.

Enfim, parar aqui, isso é inútil.

@pjmlp , temos aplicativos de plataforma cruzada com milhões de linhas de ISO C ++ que funcionam perfeitamente no iOS / macOS / Windows. C ++ é a única linguagem a ser usada quando você se preocupa com o desempenho e / ou a vida útil da bateria. As extensões C ++ não são boas para nós, pois usamos vários compiladores (que obviamente não implementam as extensões uns dos outros).
Usamos C ++ / CLI anteriormente e é uma dor de cabeça. Restrições como membros de classe permitindo apenas ponteiros C ++ crus tornam difícil armazenar ponteiros inteligentes. O tempo de compilação é longo (mudanças de um único caractere requerem 5 minutos de tempo de MD Merge).
C ++ inclui exigir empacotamento para alterar o pragma gerenciado / não gerenciado
O compilador é uma versão diferente para C ++ / CLI em comparação com C ++ (e me disseram no build que o compilador C ++ / CLI não suportaria mais tarde do que C ++ 17, o que é um problema ao incluir cabeçalhos de bibliotecas que usam C ++ 20 recursos).
O que estou tentando dizer é, não tenha vários esforços concorrentes. Fique com o padrão e trabalhe com ele. A Microsoft está no comitê C ++, eles ajudam a impulsionar o padrão, este deve ser o foco, não proprietário, bloqueado em extensões.

Poderíamos ter um compilador xaml, como xaml.exe para compilar arquivos xaml, semelhante a midl.exe, cl.exe ou link.exe? Seria muito útil construir um pipeline automático para a aplicação winui.

Às vezes, não queremos usar o visual studio para fazer o desenvolvimento, talvez usando qualquer editor que quisermos, mas manter um pipeline de construção separado. Parece que o aplicativo winui xaml é uma parte especial e parece que ainda não existe uma ferramenta de linha de comando para compilá-lo.

Isso é necessário para cenários como cmake: https://github.com/microsoft/ProjectReunion/issues/58

Poderíamos ter um compilador xaml, como xaml.exe para compilar arquivos xaml, semelhante a midl.exe, cl.exe ou link.exe? Seria muito útil construir um pipeline automático para a aplicação winui.

@sammi # 1433 resume uma solução plausível para o que você está procurando?

Poderíamos ter um compilador xaml, como xaml.exe para compilar arquivos xaml, semelhante a midl.exe, cl.exe ou link.exe? Seria muito útil construir um pipeline automático para a aplicação winui.

@sammi # 1433 resume uma solução plausível para o que você está procurando?

@jtbrower , esse é exatamente o recurso que estou procurando, obrigado!

Certamente é uma prévia, e isso significa que não devo esperar muito, mas o WinUI 3 preview 2 foi decepcionante para mim.

Minha maior necessidade está na área de design XAML. Fiquei bastante surpreso com o fato de que o designer XAML não funcionou e, até agora, não encontrei informações claras sobre quando ele funcionará.

Sim, concordo que o XAML Designer atual no Visual Studio é muito lento e quebra quando se altera coisas em tempo real que realmente não deveriam quebrá-lo. Por exemplo, alterando Height="*" para "Auto" ou 100. (a janela de erro exibe cerca de 10 erros - rabiscos em abundância e você tem que reconstruir o projeto)

Para ser claro - eu realmente não uso o designer para projetar - eu só quero ter uma ideia se meu layout se parece com o que eu tinha imaginado antes de passar pelo processo de construção. Se fosse mais fácil, se o designer fosse apenas "Exibir apenas" e atualizasse conforme eu ajustava o XAML (sem travar), tudo bem para mim, já que não uso a GUI para alterar o XAML .. ou muito raramente . Na verdade, o que o WindowsCommunityToolkit faz com a fonte XAML que permite ao usuário alterar a fonte e ver a saída em tempo real é bom o suficiente para meus propósitos.

Dito isso, o WinUI tem uma ótima ideia - desacoplar todas essas coisas "fáceis" do sistema operacional e deixar o trabalho do desenvolvedor evoluir muito mais rapidamente, e podemos agrupar as dependências com o aplicativo para evitar ter que atualizar 1 bilhão de dispositivos para que eles possam executar nosso novo material excelente.

Espero que o Project Reunion também acabe separando totalmente a GUI do contêiner do aplicativo. UX semelhante ao UWP, sem área restrita / limites, seria um grande passo à frente.

Mas quando podemos ter um Designer XAML que funcione novamente ... por favor?

Acho que o hot reload praticamente substituiu o propósito de "somente visualização" do designer XAML.

Mas estamos falando sobre ferramentas WinUI aqui. O hot reload e a árvore visual ao vivo também não funcionam para o WinUI.

O que eu quis dizer com o designer View Only foi "Eu poderia me contentar com isso se fosse algo que pudéssemos colocar em uma próxima visualização"

Posso estar errado (E, por favor, diga-me se estou), mas agora, a única maneira de ver sua IU no WinUI é construí-la e executá-la.

Mas estamos falando sobre ferramentas WinUI aqui. O hot reload e a árvore visual ao vivo também não funcionam para o WinUI.

O que eu quis dizer com o designer View Only foi "Eu poderia me contentar com isso se fosse algo que pudéssemos colocar em uma próxima visualização"

Posso estar errado (E, por favor, diga-me se estou), mas agora, a única maneira de ver sua IU no WinUI é construí-la e executá-la.

Ei @ ericleigh007 , você teve a chance de conferir nosso último lançamento WinUI 3 Preview 3? Recentemente, adicionamos muitas melhorias nas ferramentas, como IntelliSense, Hot Reload, Live Visual Tree e Live Property Explorer. Você pode verificar as notas de versão aqui e obter a prévia mais recente aqui . Estou interessado em sua opinião, sinta-se à vontade para entrar em contato!

@JeanRoca Infelizmente, acompanhar a experiência de desenvolvimento C ++ / CX não foi uma dessas melhorias nas ferramentas. Não espere muito amor do desenvolvedor pelo WinUI quando o conjunto de ferramentas C ++ proposto parecer voltar a 2000, escrever arquivos IDL no bloco de notas (sem qualquer suporte de editor) e copiar os arquivos manualmente.

Isso me faz ficar no .NET o máximo que posso ou apenas continuar usando C ++ / CX, apesar dos avisos para mudar para C ++ / WinRT.

Obrigado pela atualização; Estarei tentando isso hoje e apresentarei um relatório. 🤞

Enviado do Mail https://go.microsoft.com/fwlink/?LinkId=550986 para Windows 10

De: JeanRoca [email protected]
Enviado: quarta-feira, 18 de novembro de 2020 4:41
Para: microsoft / microsoft-ui-xaml [email protected]
Cc: Eric [email protected] ; Mencione a mençã[email protected]
Assunto: Re: [microsoft / microsoft-ui-xaml] Ferramentas e experiência do desenvolvedor WinUI 3.0 - entrada necessária (# 1045)

Mas estamos falando sobre ferramentas WinUI aqui. O hot reload e a árvore visual ao vivo também não funcionam para o WinUI.

O que eu quis dizer com o designer View Only foi "Eu poderia me contentar com isso se fosse algo que pudéssemos colocar em uma próxima visualização"

Posso estar errado (E, por favor, diga-me se estou), mas agora, a única maneira de ver sua IU no WinUI é construí-la e executá-la.

Hey @ ericleigh007 https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fericleigh007&data=04%7C01%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637412713160082691%7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = jha7IQJyg% 2BKEZKwKvA% 2BKEZKwKvA ter https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F3620&data=04%7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160082691% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = 2jVKkAs9Whd6U9kH1ZxJKy956wI6Itg7jq6lCuaqEgE% 3D & reservados = 0 e receba as últimas pré-visualização aqui https://eur05.safelinks.protection.outlook.com/?url=https% 3A% 2F% 2Fdocs.microsoft.com% 2Fen-nos% 2Fwindows% 2Fapps% 2Fwinui% 2Fwinui3% 2F & dados = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160092685% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = VF2s7jilqpksevP6Fx7mXW1QCNJN2% 2BK5yWOndg3rKoc% 3D & reserved = 0 . Estou interessado em sua opinião, sinta-se à vontade para entrar em contato!

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F1045%23issuecomment -729402012 & dados = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160092685% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = R1S2JpfBSzsNKJBAH5% 2Fgme8Bq% 2FjHbzB9FySk1KnZKbk% 3D & reservados = 0 , ou de cancelamento https: //eur05.safelinks.protection.outlook .com /? URL = https% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% 2FABX3S2XLYXYXP7BZZC3OE73SQNGBFANCNFSM4ICOLUJQ & dados = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160102680% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = 0H6IpND3YX1s6oyXy% 2FCXNAMN9n8fvSPdWks% 2FfmXT0Bc% 3D & reserved = 0 .

-Não há editor / método wysiwyg que funcione com winui3 c ++ (desktop) agora, certo?

A Microsoft está conseguindo alienar os usuários C ++ / CX também? Essa coisa toda não está indo muito bem. Qualquer um que adotou a tecnologia que a Microsoft estava pressionando há alguns anos para UWP, seja .net ou c ++, está com problemas agora sem o suporte da Microsoft.

Parece que o WinUI 3 serve apenas para aplicativos de desktop escritos em WPF - mas eles vão perceber rapidamente que o UWP não tem todos os recursos do WPF e o WinUI ainda menos recursos. Todos ficarão frustrados, o que é um péssimo lugar para iniciar o WinUI 3.

@robloo Como alguém que costumava defender o UWP, eles me perderam, é WPF e Win32 até que eles resolvam a bagunça.

C ++ / WinRT foi um movimento político, e nos disseram apenas para engolir e esperar até que ISO C ++ eventualmente fornecesse reflexão e suporte a metaclasses, para a equipe do Visual Studio replicar a experiência C ++ / CX.

Como mencionado, até mesmo editar arquivos IDL não é diferente de usar o Bloco de notas bruto.

O fato de nós em .NET termos que tolerar que a Microsoft não disponibilizasse todos os componentes UWP para nós, era de alguma forma barrável com C ++ / CX oferecendo uma experiência semelhante a C ++ / CLI. Agora, com C ++ / WinRT, estamos de volta ao ATL.

Então, lendo as discussões sobre os problemas da Reunião e o roteiro de atualização, fica claro que eles levarão vários anos para corrigir o curso.

O WPF e o Win32 podem ser antigos, mas estão aqui e funcionam, sem necessidade de outra reescrita e perda de recursos.

-Não há editor / método wysiwyg que funcione com winui3 c ++ (desktop) agora, certo?

O designer XAML meio que funciona, mas não foi realmente projetado para a edição wysiwyg para começar. Recarregar a quente (que agora funciona na visualização 3) funciona melhor.

A árvore visual ao vivo e a visualização da propriedade ao vivo funcionam bem na visualização 3. Quando o designer está programado para estar disponível?

Também notei que o designer de desktop (WPF) (não UWP) costumava funcionar no 2.4 (ou algo assim), mas agora meus testes não o veem funcionando novamente? Estou perdendo algo com o estado atual do designer?

Desculpe, estou atrasado para a festa. @wjk acertou em cheio no primeiro ponto.

1. MSIX é muito bom, mas eu ainda uso o bom e velho MSI para instalar aplicativos mais complexos que requerem recursos que o MSIX não suporta. Também estou desconfiado de usar o MSIX por causa do alto custo dos certificados Authenticode necessários.

Eu realmente aprecio o fascínio do MSIX, mas este mandato de assinatura de certificado é um obstáculo para mim. Preciso de um assistente de instalação adequado para SCM que possa usar para criar uma experiência clássica de instalador de desktop. Por que não aproveitar as melhorias no MSIX e criar uma nova versão do instalador MSI sem a Microsoft Store e os requisitos de certificação para uma experiência de desenvolvimento mais moderna? Talvez seja isso o que significa o recurso "Suporta implantação não-MSIX" listado no Roadmap atual? Se for assim, acho que estou preso à espera da 3.x, a menos que por algum milagre, isso o torne uma versão anterior. Ansioso por isso, porque os projetos do instalador do VS estão tragicamente desatualizados e nada amigáveis ​​para o controle de origem. 😓

@Chiramisu Concordo com o sentimento, mas também estou confuso - e a experiência de sideload + AppInstaller não é suficiente?

@Chiramisu Você já experimentou o WiX ? Eu o uso para todos os meus instaladores baseados em MSI e funciona muito, muito bem. Há também uma extensão do Visual Studio , para que você possa ter projetos de WiX que automatizam os vários comandos de compilação.

@robloo Como alguém que costumava defender o UWP, eles me perderam, é WPF e Win32 até que eles resolvam a bagunça.

C ++ / WinRT foi um movimento político, e nos disseram apenas para engolir e esperar até que ISO C ++ eventualmente fornecesse reflexão e suporte a metaclasses, para a equipe do Visual Studio replicar a experiência C ++ / CX.

Como mencionado, até mesmo editar arquivos IDL não é diferente de usar o Bloco de notas bruto.

O fato de nós em .NET termos que tolerar que a Microsoft não disponibilizasse todos os componentes UWP para nós, era de alguma forma barrável com C ++ / CX oferecendo uma experiência semelhante a C ++ / CLI. Agora, com C ++ / WinRT, estamos de volta ao ATL.

Então, lendo as discussões sobre os problemas da Reunião e o roteiro de atualização, fica claro que eles levarão vários anos para corrigir o curso.

O WPF e o Win32 podem ser antigos, mas estão aqui e funcionam, sem necessidade de outra reescrita e perda de recursos.

Para que eu possa acompanhar, você pode me dar uma dica de qual edição IDL está falando com C ++ / WinRT? Pelo que vi do co_await e de outras sintaxes do C ++ 17, a complexidade parece ter aumentado muito em relação ao C ++ / CX.

EM? Não é possível que, a menos que alguém crie alguns invólucros realmente bons em torno disso, que o C ++ / WinRT baseado nos recursos do C ++ 17 seja muito complexo e muito diferente dos projetos atuais? O C ++ / CX não poderia ser mantido o suficiente para que algum "excelente invólucro" fosse criado para o C ++ 17 para tornar o C ++ / WinRT razoavelmente simples de usar e para o qual migrar?

(agora alguém vai criar um link para um artigo que mostra como isso é feito, e vou me sentir um tolo)

@lmcdougald Ainda não tentei. Deve-se observar que meu projeto específico ainda está no .NET Framework 3.5. Eu sei eu sei. Eu não tive permissão para atualizá-lo ainda, então estou preso com a tecnologia do instalador que funcionará com esta estrutura antiga. 😖

@wjk Já

Gentilmente

@Chiramisu Sim, o WiX funciona com versões antigas do .NET Framework e, sim, também funciona com aplicativos winforms. Uma vez que cria arquivos MSI brutos, o WiX pode instalar qualquer coisa, em qualquer linguagem de programação. Em termos de aprendizado, eu começaria com os tutoriais básicos . Também gostaria de apontar como detectar se o .NET está instalado e como executar NGEN em arquivos usando WiX , já que você está usando essas tecnologias em seu aplicativo. A extensão do Visual Studio também vem com vários modelos de projeto, para fornecer a você o esqueleto de código correto para adicionar. (Observação: não use o modelo Bootstrapper, pois esse é um tópico muito mais avançado.) Espero que isso ajude!

@Chiramisu Estou tão confuso com o que você está procurando - me parece que você está procurando ferramentas de empacotamento para seu projeto atual e não para um projeto WinUI 3.0.

É importante notar que o .NET Framework 3.5 pode ser empacotado em um MSIX. Você poderia construir um pacote MSIX para o seu aplicativo existente com um projeto de pacote no VS 2019 e, em seguida, passar por uma longa transição sem problemas, mas é muito trabalhoso:

O WinUI 3.0 nunca oferecerá suporte oficial ao .NET 3.5 e provavelmente nunca oferecerá suporte ao .NET Framework em nenhuma versão. Eu começaria sua modernização com o objetivo de atualizar para .NET 4.6 (ou idealmente superior, 4.8 seria o ideal) sem alterar seu projeto de empacotamento existente. Se tudo correr bem, eu começaria a fazer a transição da funcionalidade para uma biblioteca compartilhada do .NET Standard que você faz referência em seu aplicativo .NET 4.6+ atualizado.

Assim que o aplicativo .NET 4.6 estiver estável e testado, você pode trocá-lo como uma atualização automática para seu projeto de empacotamento MSIX. Após a etapa .NET Standard, você pode criar um cabeçalho de projeto que usa quase o mesmo código do .NET Core 3.1 (ou 5, mas acho que o status LTS provavelmente significa algo para sua organização). Novamente, teste e depois mude o MSIX para usar esta versão.

Mudar de WinForms para WinUI nesse ponto é uma questão de aprender WinUI e reimplementar a interface. Novamente, crie um novo cabeçalho de projeto, implemente e faça referência à biblioteca .NET Standard, teste e, a seguir, troque o pacote para usar esta versão.

É assim que eu faria a modernização sem criar projetos totalmente divergentes em qualquer ponto. Eu priorizaria configurar o empacotamento MSIX e as etapas do .NET 4.6 + .NET Standard, pois essas etapas proporcionarão a você muito mais ferramentas de ajuda e conexão com o ciclo de desenvolvimento .NET moderno. Mudar rapidamente para o .NET 5 parece uma má ideia para a sua organização a curto prazo, considerando que seu ciclo de vida é 1/10 do tempo que o .NET 3.5 existe.

Para que eu possa acompanhar, você pode me dar uma dica de qual edição IDL está falando com C ++ / WinRT? Pelo que vi do co_await e de outras sintaxes do C ++ 17, a complexidade parece ter aumentado muito em relação ao C ++ / CX.

EM? Não é possível que, a menos que alguém crie alguns invólucros realmente bons em torno disso, que o C ++ / WinRT baseado nos recursos do C ++ 17 seja muito complexo e muito diferente dos projetos atuais? O C ++ / CX não poderia ser mantido o suficiente para que algum "excelente invólucro" fosse criado para o C ++ 17 para tornar o C ++ / WinRT razoavelmente simples de usar e para o qual migrar?

(agora alguém vai criar um link para um artigo que mostra como isso é feito, e vou me sentir um tolo)

Como o C ++ normal não tem os recursos para extrair os metadados de tipo necessários para fazer um arquivo .winmd, você deve escrever suas classes WinRT em um arquivo .idl, em cima de .hpp e .cpp.

co_await é muito menos complexo do que escrever .then([=](Foo^ thing) { }) qualquer lugar, é muito semelhante à sintaxe await C #.

Aqui está um exemplo (idl + hpp + cpp) do projeto de componente de tempo de execução padrão:

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

#pragma once

#include "Class.g.h"

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

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

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

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

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

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

Aqui está um pequeno exemplo co_await:

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

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

Olá,

Estamos lendo seus comentários e tomando notas sobre os pontos fracos.

@ ericleigh007 O XAML Designer estava fora de questão porque, depois de coletar o feedback do cliente, os principais pontos roteiro de recursos . De acordo com o plano de engenharia atual, está fora do 3.0 RTM, então é pós-3.0.

@pjmlp Eu simpatizo com sua

@robloo , não estamos atendendo a aplicativos de desktop escritos em WPF. C ++ / WinRT é o primeiro cidadão no ecossistema WinUI. É o que usamos para escrever WinUI, portanto, estamos testando nossas ferramentas e linguagens adequadas.

@Chiramisu Deixe-me explicar o que significa "suporte para implantação não-MSIX". Hoje você precisa instalar e executar um aplicativo Desktop WinUI 3 usando MSIX. Esse recurso é sobre como remover essa necessidade. Para executar um aplicativo Desktop WinUI 3, você só precisa duplicar em um .EXE e pronto. Para instalar seu aplicativo, você pode apenas fazer uma xcopy (não há necessidade de assinar nada). Basicamente, você poderá usar outros sistemas de embalagem e instalação como o WiX.

@ marb2000 Obrigado por reconhecer o problema. O que eu e muitos outros desenvolvedores do Windows não entendemos é por que você (como no gerenciamento do WinDev) decidiu que era uma boa ideia aplicar C ++ / WinRT à força bruta sobre nós com ferramentas inferiores, mesmo voltando ao MFC é melhor, pelo menos não estamos copie manualmente os arquivos.

No momento estou me concentrando em ASP.NET, WFP e Win32, apenas continue acompanhando as coisas UWP com a esperança de que a Microsoft eventualmente perceba que estamos fartos de reescrever aplicativos e sendo arrastados para configurações manuais, como no UAP => UWP transição, .NET Framework para .NET Core ou sim C ++ / CX => C ++ / WinRT.

Isso é mais uma coisa de feedback, como um membro ativo da comunidade de desenvolvedores do Windows que se sente um pouco decepcionado com as constantes reescritas desde a introdução do Windows 8.

@pjmlp Não sei por que você está criticando o C ++ / WinRT, que é apenas um wrapper C ++ (compatível com o padrão) em torno das APIs do Windows. É possível escrever aplicativos com C ++ / WinRT sem a necessidade de ferramentas (e arquivos IDL etc).

@pjmlp Não sei por que você está criticando o C ++ / WinRT, que é apenas um wrapper C ++ (compatível com o padrão) em torno das APIs do Windows. É possível escrever aplicativos com C ++ / WinRT sem a necessidade de ferramentas (e arquivos IDL etc).

Esse é exatamente o problema, suporte zero a ferramentas versus a experiência de desenvolvimento de C ++ / CX no Visual Studio.

Sem suporte de edição para arquivos IDL, nem mesmo realce de sintaxe, muito menos intelisense. E então alguém é instruído a copiar manualmente, ou mesclar, as unidades de tradução geradas!

É como fazer ATL antigamente.

Eu não me importo com a compatibilidade ISO C ++, UWP é apenas Windows e não há nenhum compilador C ++ sem extensões de linguagem.

Não consigo ver como alguém pode ver isso como um progresso, além dos caras do WinDev que eram os únicos usuários do WRL.

@pjmlp ,

Eu não me importo com a compatibilidade ISO C ++, UWP é apenas Windows e não há nenhum compilador C ++ sem extensões de linguagem.

Para aqueles de nós que escrevem grandes aplicativos de plataforma cruzada C ++, ser compatível com os padrões é um grande negócio. As restrições de C ++ / CX eram terríveis (sem variáveis ​​de membro que não sejam ponteiros brutos, chapéus! ( ^ ) etc). Atualmente, temos uma grande biblioteca de interoperabilidade C ++ / CLI e os pontos problemáticos são numerosos demais para listar.

Sem suporte de edição para arquivos IDL, nem mesmo realce de sintaxe, muito menos intelisense. E então alguém é instruído a copiar manualmente, ou mesclar, as unidades de tradução geradas!

Novamente, você está combinando C ++ / WinRT e ferramentas. São 2 coisas distintas. C ++ / WinRT é um wrapper C ++ em torno das APIs do WinRT. IDL é para geração de código e, sim, concordo que é horrível, é tão ruim que não uso.

Eu escrevo um aplicativo somente para Windows e ainda me preocupo com a conformidade com os padrões, pois ele me permite usar um compilador diferente nos casos em que o MSVC falha.

@MarkIngramUK

Novamente, você está combinando C ++ / WinRT e ferramentas. São 2 coisas distintas. C ++ / WinRT é um wrapper C ++ em torno das APIs do WinRT. IDL é para geração de código e, sim, concordo que é horrível, é tão ruim que não uso.

Tenho codificado para plataformas Microsoft desde o MS-DOS 3.3, adicionei C ++ à minha caixa de ferramentas em 1992 com o Turbo C ++ 1.0, usei a maior parte dos produtos Borland e Microsoft no que diz respeito ao desenvolvimento C ++. Não precisa de nenhuma palestra sobre o que é C ++ / WinRT.

O que definitivamente não é, é uma correspondência para a experiência de desenvolvedor C ++ Builder e Qt (com Qt Designer), que C ++ / CX mostrou a promessa de eventualmente alcançar, 25 anos depois.

Mas, aparentemente, a maioria das pessoas aqui quer apenas Visual C ++ 6.0 com ATL 3.0, e o resto de nós deve apenas ficar com a experiência de desktop .NET 5, WPF e Win32, porque somos uma minoria que não merece consideração, caso contrário, C ++ / WinRT nunca teria foi empurrado do jeito que estava.

Vamos ser honestos, C ++ / WinRT agora tem quase 4 anos, e a Microsoft nem mesmo era capaz de fornecer suporte para realce de sintaxe e intelisense?

Algo que alguns de nós criamos no Notepad ++ (destaque de sintaxe). Sério?

Isso definitivamente mostra onde estão as prioridades, e não é dessa forma que o WinUI será adotado, muitas reescritas desde o Windows 8.

@pjmlp , novamente você está falando sobre as coisas erradas. C ++ / WinRT é apenas C ++, portanto, tem realce de sintaxe e suporte a intellisense. Exatamente como qualquer outro código C ++ que você tenha.

A integração com IDE poderia ser melhor, como você mencionou o destaque da sintaxe IDL e outras coisas como sugerir a criação de uma implementação padrão em .hpp e .cpp a partir do IDL (como como atualmente uma função declarada sem uma definição em um cabeçalho avisa com rabiscos verdes para criar um), mas voltar para C ++ / CX é um downgrade da rede IMO. Exigiria muito esforço integrar todas as bibliotecas e código compartilhado que uso com C ++ / CX e me forçar a fazer o downgrade do meu projeto de C ++ 20 para C ++ 17 (do qual não quero desistir, 20 me dá muitas coisas boas).

C ++ / WinRT também é muito menos intrusivo do que C ++ / CX quando os programas querem apenas consumir classes WinRT, não criá-las.

Qt e C ++ Builder alcançam sua experiência principalmente em C ++ compatível com os padrões (note que Qt tem algo semelhante a IDL, chamado Qt MOC). Se eles podem, o VS também pode. Requer apenas mais amor de alguém em DevDiv.

E como você mencionou anteriormente, @sylveon , estamos livres para construir com outros compiladores (atualmente construímos com MSVC e Clang / LLVM). Com C ++ / CX ou outras extensões MS, isso seria impossível.

@MarkIngramUK e @sylveon

Eu terminei com este tópico, está bastante claro que feedback como o meu não é bem-vindo para melhorar a experiência do desenvolvedor WinUI e ferramentas.

Divirta-se com seu C ++ / WinRT compatível com o padrão.

você pode editar isso para corrigir o erro de digitação 'sem catering' .. Acho que deveria ser 'agora ...'

@pjmlp Acho que entendo EXATAMENTE o que você quer dizer.

Há cerca de um ano, abandonei a ideia de portar meu código UWP C ++ / CX para C ++ / WinRT. O incentivo para portar era poder usar o Clang para compilar meu aplicativo UWP porque o MSVC ++ contém um bug que relatei há cerca de 18 meses, mas eles simplesmente não parecem estar interessados ​​em consertar.

No entanto, descobriu-se que o Visual Studio não oferece suporte à construção de aplicativos UWP usando Clang. Ótimo, então o benefício de "somente ISO C ++" do C ++ / WinRT foi jogado fora da janela. Adicione a isso o fato de que portar uma base de código C ++ / CX sobre C ++ / WinRT é como viajar 20 anos no tempo.

Basicamente, desisti de portar nossos aplicativos Android / iOS para o Windows. Simplesmente não é viável para uma pequena loja como a nossa lidar com a confusão que é o desenvolvimento de aplicativos do Windows, além de desenvolver para Android / iOS.

@MarkIngramUK Parece que você simplesmente não entendeu que o ferramental É MUITO IMPORTANTE. Nem todos têm recursos para compensar a falta de ferramentas adequadas.

Agora, depois de meu discurso retórico, aqui está minha opinião:

Suporte usando WinUI 3 com C ++ / CX. Uma vez que as ferramentas para C ++ / WinRT são aceitáveis ​​para empresas que não têm os recursos para construir suas próprias ferramentas, pode ser ok mudar para C ++ / WinRT. Agora definitivamente não é.

@pjmlp Acho que entendo EXATAMENTE o que você quer dizer.

Há cerca de um ano, abandonei a ideia de portar meu código UWP C ++ / CX para C ++ / WinRT. O incentivo para portar era poder usar o Clang para compilar meu aplicativo UWP porque o MSVC ++ contém um bug que relatei há cerca de 18 meses, mas eles simplesmente não parecem estar interessados ​​em consertar.

No entanto, descobriu-se que o Visual Studio não oferece suporte à construção de aplicativos UWP usando Clang. Ótimo, então o benefício "somente ISO C ++" do C ++ / WinRT foi jogado pela janela. Adicione a isso o fato de que portar uma base de código C ++ / CX sobre C ++ / WinRT é como viajar 20 anos no tempo.

Basicamente, desisti de portar nossos aplicativos Android / iOS para o Windows. Simplesmente não é viável para uma pequena loja como a nossa lidar com a confusão que é o desenvolvimento de aplicativos do Windows, além de desenvolver para Android / iOS.

@MarkIngramUK Parece que você simplesmente não entendeu que o ferramental É MUITO IMPORTANTE. Nem todos têm recursos para compensar a falta de ferramentas adequadas.

Agora, depois de meu discurso retórico, aqui está minha opinião:

Suporte usando WinUI 3 com C ++ / CX. Uma vez que as ferramentas para C ++ / WinRT são aceitáveis ​​para empresas que não têm os recursos para construir suas próprias ferramentas, pode ser ok mudar para C ++ / WinRT. Agora definitivamente não é.

Por curiosidade, qual foi o bug relatado há 18 meses? Você tem um link para isso em algum lugar?

oi Miguel,
___editado para corrigir o terrível estado de coisas após responder do Outlook para Android___

Tive uma ideia que pode deixar seus objetivos para as visualizações e lançamentos claros, já que você disse que a plataforma Winrt é o que está usando para desenvolver o WINUI.

veja este artigo, que fala muito sobre a gravação de IDL e a cópia manual de arquivos e modifica-os para que corresponda ao estado em que você está trabalhando nas ferramentas

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

Se não for aqui, talvez possamos discutir isso em outro lugar.

a propósito, você me convenceu sobre o designer XAML, especialmente com ferramentas existentes como o XAML Studio. (se ele também pudesse carregar algum código para que pudesse carregar com êxito o XAML que faz uso de IValueConverter ...

Conforme mencionado em meu post anterior, a conformidade do padrão C ++ 17 de C ++ / WinRT por si só não é, na maioria dos casos, incentivo para migrar uma base de código C ++ / CX para C ++ / WinRT porque você é forçado a compilar com o compilador Visual C ++ da Microsoft qualquer forma. Se você pudesse trocar o compilador, isso mudaria completamente.

Mas o Visual Studio não oferece suporte à troca do compilador para componentes do Windows Runtime. É um mistério para mim por que isso não é compatível, especialmente porque é compatível com aplicativos de desktop, conforme descrito nesta postagem do blog . O suporte do Clang realmente deve ser expandido para os componentes do Tempo de Execução do Windows.

Estamos usando o Clang para compilar nossa base de código para Android e iOS. Ser capaz de usar o Clang para compilar nossa base de código para Windows seria, na verdade, um bom motivo para migrar do C ++ / CX. A solicitação de recurso do Visual Studio para isso já existe, mas nada foi feito até agora pela equipe do Visual Studio.

Você tem conformidade com o padrão C ++, tem suporte do Clang no Visual Studio para aplicativos de desktop. Portanto, execute a etapa final e forneça um motivo real para migrar do C ++ / CX, fornecendo suporte do Clang para componentes do Tempo de Execução do Windows.

A conformidade com os padrões é útil para os consumidores - como você mencionou, os produtores estão presos ao MSVC. Existe uma maneira de "forçar" o clang-cl (que é efetivamente o que o conjunto de ferramentas LLVM já faz ) definindo a propriedade CLToolExe para um caminho para clang-cl no arquivo .vcxproj . Não tenho certeza se isso funciona bem em projetos UWP, mas vale a pena tentar.

Depois que as ferramentas de produtor XAML e C ++ / WinRT forem desbloqueadas em projetos de desktop, isso também deixará de ser um problema para mim.

@ackh Eu tenho um projeto UWP para construir no Clang 11:

Aqui está o que eu fiz:

• Descarregue o projeto e adicione a seguinte diretiva como a primeira diretiva em <Project>

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

• Substitua <AdditionalOptions>%(AdditionalOptions) /bigobj</AdditionalOptions> por <AdditionalOptions>%(AdditionalOptions) /bigobj -Xclang -std=c++20 -mcx16</AdditionalOptions>
• Substitua <PreprocessorDefinitions>WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions> por <PreprocessorDefinitions>_SILENCE_CLANG_COROUTINE_MESSAGE;WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions>
• Logo abaixo disso, adicione <ModuleOutputFile />
• Recarregue o projeto
• Construir

No entanto, há algumas armadilhas:

• Alguns avisos relacionados a argumentos não usados ​​sustentam: você provavelmente poderia consertá-los alterando / removendo os argumentos não usados.
• Por alguma razão, o Clang emite um arquivo de objeto de 64 bits em 32 bits, pode apenas precisar adicionar -m32 ao CLI tho.
• Como o Clang ainda não implementa totalmente as corrotinas, você não poderá usá-las.
• O VS faz uma reconstrução completa de thread único cada vez que você executa o aplicativo, em vez de incremental e / ou paralelo.

Eu sugeriria abrir um problema em https://github.com/microsoft/ProjectReunion para chamar a atenção sobre isso.

@sylveon Muito obrigado por postar essas instruções. Vou tentar isso em algum momento, mas ainda espero que o Visual Studio ofereça suporte para isso fora da caixa em algum momento.