Estaba en su nivel de frustración hace unos años cuando comencé a migrar aplicaciones WPF. Así que ciertamente comprendo tus sentimientos. Ha habido algunos avances desde entonces y, como dijiste, el equipo de WinUI realmente lo está intentando.

Desde mi punto de vista, hay un problema de diseño fundamental que no podemos solucionar: WinRT tenía una desventaja técnica porque tiene que interoperar directamente con C ++ y JavaScript ( aquí hay un ejemplo y otro ). Realmente no funciona bien con muchos de los conceptos de alto nivel, como los genéricos. Por supuesto, también hay un gran beneficio con esta arquitectura: ahora todo Windows puede compartir las mismas API de WinRT.

WinRT también fue realizado por el equipo de Windows bajo Sinofsky, creo, lo que significa que sí, vivían en su propio mundo y no tenían experiencia trabajando con el ecosistema de desarrolladores de usuarios finales existente. Terminamos con una API de 'mínimo común denominador' con la que tanto los desarrolladores nativos como los administrados no disfrutan trabajar. Esta es fundamentalmente una de las principales razones por las que Windows Phone murió: los desarrolladores no pudieron desarrollar / portar aplicaciones fácilmente. Sin Apps no había clientes. Microsoft aprendió esta lección.

Así que hemos perdido varias de las ventajas del código administrado a las que nos hemos acostumbrado a lo largo de los años. Definitivamente todavía parece un paso atrás de WPF: encuentro errores y funciones incompletas todo el tiempo. Creo que el # 1830 nunca sucedería en los días de WPF. Todavía tenemos que avanzar de alguna manera.

WinUI 3.0 es claramente un paso en la dirección correcta para intentar arreglar esto al menos en la interfaz. Sin embargo, preferiría que Microsoft implemente un proceso de desarrollo más robusto y más pruebas antes de lanzar nuevos controles ... Sé que el desarrollo ahora es empujar cambios, arreglar más tarde. Si bien eso puede funcionar para las aplicaciones, no es un buen patrón para una plataforma en la que una vez que se configuran las cosas, es muy difícil cambiarlas más adelante. (TreeView, NumberBox, etc ... tienen tantos problemas en el primer lanzamiento que nunca saldrían por la puerta, y mucho menos etapas de planificación, hace 15 años).

Es triste para mí ver lo que una vez fue la plataforma de interfaz de usuario más poderosa, WPF, evolucionar hacia esto. Pero Microsoft ahora, de forma lenta pero segura, escucha los comentarios y arregla las cosas. Se entiende que hay mucho más trabajo por hacer.

¿Crees que los usuarios harán felizmente lo anterior? No, no lo harán; de hecho, el 79,8% no lo hace (mis datos de AppCenter respaldan esto). Dejándome con usuarios que no usan mi aplicación, o simplemente haciendo que mi aplicación parezca insatisfactoria en comparación con otras aplicaciones nativas.

Quizás no esté considerando el hecho de que sus usuarios realmente se están deteniendo a pensar: "espera, ¿realmente quiero otorgar acceso a esta aplicación a todo mi disco?" Esa es una advertencia de luz roja para las personas que no están familiarizadas con la aplicación, el desarrollador o la empresa.

Estás culpando al proceso por el que los usuarios deben pasar para otorgar acceso a tu aplicación a todo su disco por la baja tasa de retención. Quizás debería reconsiderar su "necesidad" de broadFileSystemAccess en primer lugar, y más bien hacer que los usuarios seleccionen manualmente las carpetas a las que se sienten cómodos dándole acceso.

Para su información, si quisiera probar una aplicación y después de la instalación fuera como "oye, dame permiso para acceder a todo, en todas partes", también la ejecutaría.

Cuando solicita broadSystemAccess, su aplicación, por defecto, no tiene ese acceso.

Obviamente ... Solo hizo una solicitud, sus usuarios realmente tienen que otorgarle acceso si se sienten cómodos haciéndolo.

Además, basado en el título irrespetuoso que rompe el Código de Conducta de Microsoft Open Source , y el contenido no es sobre WinUI, este problema debería cerrarse. @jevansaks @jesbis

Una última cosa que agregar. Creo que Rich Lander lo dijo mejor en el Standup de la comunidad .NET del 15 de enero (comenzando a las 1:12:40).

@verelpode Sigues la línea mencionada en el video anterior, pero te mantienes constructivo y

Cuando solicita broadSystemAccess, su aplicación, por defecto, no tiene ese acceso.

Obviamente ... Solo hizo una solicitud, sus usuarios realmente tienen que otorgarle acceso si se sienten cómodos haciéndolo.

Ese no es el problema: al menos en Android / iOS, te preguntan esas cosas mientras tu aplicación intenta acceder al disco duro, y no se cierra , como es nuestro caso.

Su aplicación no se cerraría si presentara selectores de archivos que le permitan al usuario elegir a qué quiere dar acceso a su aplicación.

En su lugar, lo quiere todo, se está quejando de un pequeño paso adicional que los usuarios deben tomar una sola vez, y culpan a su tasa de retención de este paso.

Además, basado en el título irrespetuoso que rompe el Código de Conducta de Microsoft Open Source , y el contenido no es sobre WinUI, este problema debería cerrarse. @jevansaks @jesbis

Es muy difícil ser respetuoso, cuando casi me estoy volviendo loco. Por no decir, lo he dicho antes, no hay lugar para escribir sobre WinRT. Con mucho gusto usaría un tono diferente, si realmente pudiera escribir, y alguien estaría escuchando. Todos los gritos anteriores simplemente no deberían existir: WinRT debería ser lo suficientemente maduro . Todavia no...

¿Dónde puede la comunidad hablar realmente con el equipo de WinRT? ¿Alguien está escuchando?

Su aplicación no se cerraría si presentara selectores de archivos que le permitan al usuario elegir a qué quiere dar acceso a su aplicación.

En su lugar, lo quiere todo, se está quejando de un pequeño paso adicional que los usuarios deben tomar una sola vez, y culpan a su tasa de retención de este paso.

Mi aplicación permite a los usuarios editar fotos y videos, y quiero que el usuario obtenga una vista previa fácilmente cuando elija, no use un selector de archivos de estilo antiguo. Así que sí, es muy importante que tenga acceso a todos los discos duros. Y no, esas carpetas virtuales de "Imágenes" y "Videos" son las que Microsoft cree que los usuarios guardan en sus fotos y videos. Esa no es la realidad.

He dicho esto antes, no hay lugar para escribir sobre WinRT.

Como indican sus enlaces, ya ha estado despotricando sobre WinRT en los foros de preguntas y respuestas de UWP, que es donde se le ha indicado que vaya.

Entonces, al publicar aquí, parece que solo desea una audiencia más grande, en lugar de lograr realmente algo (ya que el equipo de WinUI no funciona en WinRT).

Como indican sus enlaces, ya ha estado despotricando sobre WinRT en los foros de preguntas y respuestas de UWP, que es donde se le ha indicado que vaya.

Sin embargo, no hay solución para ninguno de mis problemas. En una sesión de preguntas y respuestas, haces preguntas y recibes respuestas. Pero realmente no puedes sugerir nada para cambiar (desafortunadamente).

Mi aplicación permite a los usuarios editar fotos y videos, y quiero que el usuario obtenga una vista previa fácilmente cuando elija, no use un selector de archivos de estilo antiguo. Así que sí, es muy importante que tenga acceso a todos los discos duros.

No, no es. Sus usuarios no tienen fotos y videos en todo el disco, están en ubicaciones específicas que pueden no ser las carpetas especiales.

Haga que los usuarios elijan esas carpetas una vez, entonces siempre podrá tener acceso a través de FutureAccessList . No hagas que te den acceso a todos sus archivos y no se escaparán.

@kmgallahan Claro, el tono se puede marcar un poco, pero todos nos hemos sentido frustrados antes. Es aún más frustrante pensar que no se están abordando problemas obvios. Creo que a veces es constructivo desahogar esas frustraciones en un foro donde las personas pueden validarlas y también ofrecer posibles soluciones. Sus puntos técnicos son válidos, es solo para WinRT y un poco para UWP, ambos no son los controles WinUI XAML que representa este repositorio. Por esa razón, esto probablemente debería cerrarse como fuera de tema.

Creo que podemos mantener este tipo de discusiones profesionales sabiendo que se originan en la frustración y mucho interés creado en el éxito del ecosistema de desarrollo.

Claro, el tono se puede marcar un poco hacia atrás, pero todos nos hemos sentido frustrados antes. Es aún más frustrante pensar que no se están abordando problemas obvios.

Gracias :)

No, no es. Sus usuarios no tienen fotos y videos en todo el disco, están en ubicaciones específicas que pueden no ser las carpetas especiales.

Haga que los usuarios elijan esas carpetas una vez, entonces siempre podrá tener acceso a través de FutureAccessList . No hagas que te den acceso a todos sus archivos y no se escaparán.

Claramente, no están en esos lugares específicos ...

Claro, puedo usar FutureAccessList y hacer que los usuarios recuerden dónde guardan sus fotos / videos, porque todos sabemos dónde guardamos todas nuestras fotos / videos, ¿verdad?

En lugar de (lo que hace mi aplicación) obtener una vista previa de las carpetas y mostrarle las carpetas donde tiene fotos / videos.

Algunas notas:

Gracias @jtorjo por tomarse el tiempo para escribir sobre sus experiencias y comentarios, y también por su tiempo en la página de preguntas y respuestas .

Como @robloo y @kmgallahan mencionaron, la mayor parte de esto no está directamente relacionado con WinUI y es posible que esté presionando un poco el código de conducta 🙂

Sin embargo, también reconocemos que la participación en el sitio de preguntas y respuestas y el Centro de comentarios podría ser mejor cuando se trata de diferentes áreas de la plataforma de desarrollo de Windows. Realmente estamos tratando activamente de mejorar eso, pero entiendo que es frustrante encontrar un buen lugar para proporcionar comentarios y ver si está sucediendo algo.

Por ejemplo, realmente vemos todo lo que llega a través del Centro de comentarios, pero no hay una buena manera de responder o continuar una discusión. Por lo tanto, siempre que se mantenga constructivo y esté relacionado con la UX / desarrollo de la aplicación de Windows, estamos de acuerdo con discutir algunos comentarios generales de la plataforma aquí si un tema no encaja bien en otro lugar.

Por lo que vale, estos temas también reciben una atención interna seria. Nos comunicamos con algunos expertos de WinRT hoy para ver si hay alguna actualización sobre estas áreas que podamos compartir, ya que resumió cuidadosamente algunos de los principales problemas con la plataforma y las herramientas en general.

Para el desarrollo de aplicaciones de escritorio: WinUI 3 es una gran parte de nuestro esfuerzo por desacoplar la plataforma de desarrollo de Windows para eliminar esas barreras de interoperabilidad y facilitar la adopción incremental de WinUI y UWP. Sabemos que necesitamos habilitar mejor las aplicaciones de escritorio con UX moderno sin requerir todas las restricciones actuales. Tenemos muchos expertos, incluidos algunos de los principales creadores de WPF, trabajando en ello.

En particular, estamos pasando mucho tiempo en las islas Xaml y en WinUI para aplicaciones de escritorio y estamos ansiosos por el próximo paso que lanzará una vista previa para que la gente lo pruebe más adelante este año. Estamos tratando de ser más transparentes y estar más impulsados ​​por la retroalimentación y eso debería ser más fácil a medida que movemos cosas como la plataforma Xaml completa (es decir, WinUI 3) al código abierto.

Si las personas están interesadas en el estado actual de los planes de escritorio, también podríamos entrar en un poco más de detalle en una de las llamadas comunitarias mensuales; siéntase libre de sugerir temas aquí:

Llamada a la comunidad de WinUI (22 de enero de 2020) # 1857

Hola @jesbis ,

¡Gracias por ver mis problemas!

Como @robloo y @kmgallahan mencionaron, la mayor parte de esto no está directamente relacionado con WinUI y es posible que esté presionando un poco el código de conducta 🙂

Sí, realmente lo siento, sentí que me estaba volviendo loco. Las cosas que mencioné aquí son críticas, me apasiona mucho esto, ya que me encontré con todo lo anterior. Todos cobran un precio enorme, mucha gente simplemente se da por vencida incluso en el intento.

Sin embargo, también reconocemos que la participación en el sitio de preguntas y respuestas y el Centro de comentarios podría ser mejor cuando se trata de diferentes áreas de la plataforma de desarrollo de Windows. Realmente estamos tratando activamente de mejorar eso, pero entiendo que es frustrante encontrar un buen lugar para proporcionar comentarios y ver si está sucediendo algo.

Totalmente de acuerdo. Como nota al margen, en realidad traté de informar el BroadSystemAccess en Feedback Hub, y después de proporcionar todos los detalles y dedicarle unos 15 minutos, probablemente terminé presionando una tecla de acceso rápido que era el equivalente a "Atrás". Perdí todo mi trabajo (no deshacer, no copiar texto al portapapeles, nada). Claramente, estaba locamente frustrado y simplemente me di por vencido.

Por lo que vale, estos temas también reciben una atención interna seria. Nos comunicamos con algunos expertos de WinRT hoy para ver si hay alguna actualización sobre estas áreas que podamos compartir, ya que resumió cuidadosamente algunos de los principales problemas con la plataforma y las herramientas en general.

¡Frio!

Para el desarrollo de aplicaciones de escritorio: WinUI 3 es una gran parte de nuestro esfuerzo por desacoplar la plataforma de desarrollo de Windows para eliminar esas barreras de interoperabilidad y facilitar la adopción incremental de WinUI y UWP. Sabemos que necesitamos habilitar mejor las aplicaciones de escritorio con UX moderno sin requerir todas las restricciones actuales. Tenemos muchos expertos, incluidos algunos de los principales creadores de WPF, trabajando en ello.

¡Eso es genial! Definitivamente lo estoy esperando con más ganas. Es muy probable que actualice mi aplicación una vez que haya terminado, pero hasta entonces tengo muchos problemas.

Si las personas están interesadas en el estado actual de los planes de escritorio, también podríamos entrar en un poco más de detalle en una de las llamadas comunitarias mensuales; siéntase libre de sugerir temas aquí:

Llamada a la comunidad de WinUI (22 de enero de 2020) # 1857

¿Puedo sugerir los temas de WinRT que mencioné aquí?

¡Gracias de nuevo!

Por ejemplo, realmente vemos todo lo que llega a través del Centro de comentarios, pero no hay una buena manera de responder o continuar una discusión. Por lo tanto, siempre que se mantenga constructivo y esté relacionado con el desarrollo de aplicaciones, estamos de acuerdo con recibir algunos comentarios generales de la plataforma aquí si un tema no encaja bien en otro lugar.

@jesbis
¡Esta es una gran noticia! ¡Muchas gracias al equipo de WinUI por mostrar esta flexibilidad y tratar de mitigar los problemas (percibidos) del sistema de retroalimentación de WinRT aunque no es necesario!

@kmgallahan

Creo que Rich Lander lo dijo mejor en el Standup de la comunidad .NET del 15 de enero (comenzando @ 1:12:40).

Entonces Rich Lander dice allí que prefiere personas con un poco de agresividad pero agradables al mismo tiempo. Creo que uno de los mayores problemas de la sociedad es que mucha gente es tan "educada" que su comportamiento se vuelve extremista y se convierte en falta de respeto y rudeza, mientras que superficialmente parece "educado". La gente muy "educada" habla de manera indirecta y vaga, y esto hace que su comunicación sea difícil de entender y fácil de malinterpretar. Las personas muy "educadas" son irrespetuosas y groseras porque dicen efectivamente el equivalente de:

"Creo que no puedes manejar la verdad directa, por lo tanto, te manejaré con gruesos guantes de algodón esponjoso, te empacaré en plástico de burbujas y te hablaré de manera muy cortés, indirecta y vaga, porque si te trato como adulta madura y expreso mis opiniones honestas, vas a enloquecer, explotar y enloquecer. Eres una persona muy frágil, delicada e inmadura, por eso debo hablarte muy cortés e indirectamente, porque puedes No manejes la verdad directa ".

De esa manera, cuando la llamada "cortesía" se lleva al extremo (como hace mucha gente), se vuelve irrespetuosa y grosera, sin dejar de parecer "cortés". En otras palabras, la incomprensión de la cortesía y el respeto es uno de los mayores problemas de la sociedad. Mucha gente no se da cuenta de que la cortesía excesiva es una falta de respeto y hace que los proyectos fracasen, etc. Este problema de la cortesía falsa provoca otro fallo de comunicación cada segundo de cada hora de todos los días en algún lugar del mundo - ocurre constantemente - y la sociedad sufre mucho por ello.

@jtorjo
Aquí está el origen del problema:

Repetición del catastrófico error de Nokia

WinRT / UWP repitió accidentalmente el mismo error que Nokia, BlackBerry, Apple en un momento y otras compañías. La historia de Nokia: Nokia era un gigante de mucho éxito, pero más tarde Nokia se dio cuenta de que se habían quedado atrás en la tecnología de los teléfonos inteligentes. Para resolver este problema, necesitaban darle máxima prioridad a la realización de una serie de versiones mejoradas de su sistema preexistente. En lugar de hacer eso, intentaron cambiar a un nuevo sistema y los mató. Literalmente los mató: Nokia Mobile se vio obligado a aceptar ser comprado por Microsoft.

Entonces, esperaría que Microsoft aprenda del error de Nokia y no repita el mismo problema. Desafortunadamente, Microsoft repitió el mismo error que Nokia. Microsoft se embarcó en WinRT / UWP en lugar de producir nuevas versiones de WPF y .NET Framework. ¿Adivina qué pasó? El mismo desastre catastrófico que Nokia: los mató. Windows Mobile está muerto y fue cancelado por ejecutivos de Microsoft. Por lo tanto, lamentablemente, Microsoft no aprendió del catastrófico error de Nokia. Ahora todos los teléfonos inteligentes ejecutan Android o Apple en lugar de WinRT / UWP, por lo que WinRT / UWP fue una falla catastrófica que hizo que Microsoft perdiera por completo su lugar en una industria de teléfonos inteligentes multimillonaria. WinRT / UWP causó pérdidas multimillonarias a Microsoft.

BlackBerry cometió el mismo error que Nokia y Microsoft. BlackBerry tuvo mucho éxito, pero más tarde BlackBerry se dio cuenta de que se habían quedado atrás en la tecnología de los teléfonos inteligentes. Para resolver este problema, necesitaban darle máxima prioridad a la realización de una serie de versiones mejoradas de su sistema preexistente. En lugar de hacer eso, intentaron cambiar a un nuevo sistema. BlackBerry originalmente usó BlackBerry OS, y luego, alrededor del año 2013, cambiaron al sistema QNX. ¿Qué sucedió? Lo mismo que WinRT y Nokia. Los mató. En 2016, BlackBerry anunció que dejaría de diseñar sus propios teléfonos.

También sucedió con Apple en un momento del pasado. Apple casi se derrumbó y tuvo mucha suerte de sobrevivir. Varios años después, Apple finalmente se recuperó fuertemente a través de los teléfonos inteligentes. Suerte de estar vivo después del catastrófico error.

Cambios importantes

Microsoft afirma que no pudo continuar con el desarrollo de WPF; No podía usar WPF para teléfonos inteligentes / tabletas debido a cambios importantes, pero ese es un caso de miedo extremo a cambios importantes. Sí, es aconsejable tener mucho cuidado con los cambios importantes, pero si se lleva al extremo, acaba con proyectos y empresas. La realidad es que los cambios de última hora, de hecho, pueden ser introducidos. Microsoft podría haber lanzado "WPF 5" con soporte para teléfonos inteligentes / tabletas / pantallas táctiles, y anunció que incluye cambios importantes, pero ningún desarrollador está obligado a actualizarlo de inmediato. Las aplicaciones preexistentes no se rompen porque continúan ejecutándose con WPF 4 hasta que el desarrollador de la aplicación se siente cómodo y listo para cambiar a WPF 5. Por lo tanto, los cambios importantes no causan caos ni fallas.

Es el mismo principio que una nueva versión de un paquete NuGet que incluye cambios importantes. Su aplicación no se rompe repentinamente cuando se lanza la nueva versión del paquete. Sus usuarios continúan usando su aplicación y no experimentan ningún problema porque su aplicación continúa usando la versión anterior del paquete hasta que se sienta cómodo y listo para actualizar su aplicación para usar la última versión del paquete NuGet. Por lo tanto, se pueden introducir cambios importantes.

Inversión del punto de vista sobre el código administrado

Microsoft dijo que el código administrado proporciona excelentes ventajas, y fue absolutamente cierto en mi experiencia al usar código administrado y no administrado. Comencé mi carrera escribiendo código no administrado. Más tarde probé las afirmaciones de Microsoft y cambié a código administrado y experimenté excelentes mejoras en productividad y confiabilidad. Más tarde, Microsoft invirtió extrañamente su punto de vista y produjo WinRT con una base en código no administrado, y el antiguo Component Object Model (COM) del año 1993, y el uso excesivo de Win16 (también conocido como Win32). La base de WinRT es una tecnología que está desactualizada durante décadas: código nativo, COM y Win16, también conocido como Win32. No debería sorprender que la mayoría de los desarrolladores de aplicaciones fueran reacios a cambiar a WinRT / UWP.

Android es ahora el líder del mercado. Microsoft puede aprender de Android. Las aplicaciones de Android generalmente se escriben con código administrado. Aunque no me gusta Java y prefiero usar C #, debo decir que Java es mucho mejor que los nativos Win16 y COM.

Varios miembros del personal de Microsoft siguen diciendo "nativo" como si eso fuera algo bueno. Comencé mi carrera con "nativo" y sé por años de experiencia que "nativo" es algo malo. Legiones de desarrolladores de Android también saben que lo nativo es algo malo, pero muchos miembros del personal de UWP lo dicen como si fuera genial. Para usar las palabras de @jtorjo , el equipo de WinRT estaba y está "fuera de contacto con la realidad". El equipo de WinRT continúa comportándose como si WinRT fuera un éxito, a pesar de que falló catastróficamente y Windows Mobile ya fue cancelado por los ejecutivos de Microsoft.

Tengo que seguir repitiendo esas palabras una y otra vez: WinRT / UWP fue un fracaso catastrófico. Me he visto obligado a seguir repitiendo esas palabras porque el equipo de WinRT está "fuera de contacto con la realidad" en el sentido de que se niegan a reconocer que WinRT / UWP fue una falla catastrófica y que Microsoft no debería seguir repitiendo los mismos errores de WinRT como si no hubiera pasado nada.

Por ejemplo, actualmente DataGrid está escrito en código administrado moderno, pero los equipos de WinUI quieren reescribir DataGrid para usar código "nativo" y creen que esto es una "actualización" cuando en realidad es una degradación y regresión a las prácticas. que están desactualizados por décadas. En general, WinRT / UWP está plagado de confusiones entre las prácticas de ingeniería de software modernas y obsoletas. Por lo tanto , el uso de

Para ver otro ejemplo de _ "fuera de contacto con la realidad" _, mire el diseño de WebView2 : es como viajar en el tiempo al comienzo de mi carrera, hace décadas, cuando usamos conceptos obsoletos como HRESULT lugar del moderno manejo de excepciones. Es asombroso ver que WebView2 se lanza como un nuevo proyecto en el año 2020, pero que aún utiliza técnicas antiguas como HRESULT y LPCWSTR . El diseño de WebView2 está fuera de contacto con las prácticas modernas de ingeniería de software.

Entonces, en la línea de lo que dijo Rich Lander, mi mensaje anterior demuestra mi respeto por el equipo de WinUI, porque si le faltaba el respeto al equipo de WinUI, entonces siempre sería muy cortés con el equipo, o no diría nada en absoluto. Si no respetaba al equipo, descartaría e ignoraría a WinUI: no me molestaría en escribir ningún mensaje en absoluto; vería a WinUI como "sin esperanza" y como una "causa perdida" y no daría ningún comentario en todos. El hecho de que proporcione comentarios detallados demuestra que respeto al equipo. Mucha gente no da ningún comentario, eso es una falta de respeto para el equipo. Es una falta de respeto ver al equipo tan desesperado que no vale la pena escribir comentarios para ellos.

Si estuvieras en la corte, dirías muy cortésmente "Su Señoría" al juez, incluso si odias sus entrañas. La cortesía extrema es la mala educación. Los jueces interpretan "Su Señoría" como respeto, pero en realidad es una falta de respeto.

Microsoft se embarcó en WinRT / UWP en lugar de producir nuevas versiones de WPF y .NET Framework. ...

Acordado. He estado desarrollando UWP durante varios meses ... Hay bastantes limitaciones, pero he hecho todo lo posible para ser "zen" al respecto y, más o menos, seguir adelante. Pero cuanto más trabajaba, más me daba cuenta de que las limitaciones eran de hecho WinRT, no UWP.

La cuestión es que esto es lo que tenemos y, claramente, tenemos que seguir adelante con eso. En mi opinión, esto debería ser:

1. UWP necesita ocultar tanto como sea posible el hecho de que usa WinRT y
2. WinRT debería esforzarse por eliminar tantas limitaciones (innecesarias) como sea posible
3. El enfoque principal debe ser el escritorio y luego las otras plataformas (Hololens, xbox, etc.)

(ps El hecho de que, para un archivo, para obtener sus propiedades, necesito llamar a una función asíncrona, todavía me hace temblar)

Inversión del punto de vista sobre el código administrado

La razón por la que tendríamos que lidiar con COM en WinRT está más allá de mi comprensión. Parece que envolvieron un código DCOM antiguo o algo así, pero eso debería estar 100% oculto para los usuarios de WinRT.
El hecho de que tengamos que estar al tanto de COM es realmente malo. Eso, una vez más, debería estar lo más oculto posible para mí, el usuario de la (s) biblioteca (s).

[edición posterior] Ahora que lo pienso, al menos necesitaríamos COM para manejar DirectX. Aún así, debería estar lo más oculto posible a los usuarios de las bibliotecas.

Varios miembros del personal de Microsoft siguen diciendo "nativo" como si eso fuera algo bueno.

Nativo, en el contexto de "compilar en .net nativo", creo que es algo bueno, sin embargo, no me gustan sus limitaciones. Mi proyecto no se puede compilar en .net nativo, porque usa otra lib que porté a UWP y usa algunas API, que los poderosos chicos de la Tienda creen que es "inaceptable". La biblioteca en cuestión es https://github.com/naudio/NAudio , una biblioteca increíblemente poderosa. Solo por esta razón, simplemente dije: NO publicaré mi aplicación en la tienda de MS.

Para ver otro ejemplo de _ "fuera de contacto con la realidad" _, mira el diseño de WebView2 ; es como hacer un viaje en el tiempo al comienzo de mi carrera.

No estoy 100% seguro, pero probablemente tengas razón. Sé que se dice que WebView es un contenedor sobre un control Win32, y sé de un error extraño, que los enlaces de WebView no funcionarían cuando WebView estaba encima de otro control.

Hola @robloo ,

Lo siento por la respuesta tardía

Estaba en su nivel de frustración hace unos años cuando comencé a migrar aplicaciones WPF. Así que ciertamente comprendo tus sentimientos. Ha habido algunos avances desde entonces y, como dijiste, el equipo de WinUI realmente lo está intentando.

Sí, totalmente de acuerdo. En 2016-2017, ni siquiera tocaría UWP.

Desde mi punto de vista, hay un problema de diseño fundamental que no podemos solucionar: WinRT tenía una discapacidad técnica porque tiene que interoperar directamente con C ++ y JavaScript ( aquí

Eso es más que triste, por decir lo menos ... ¿Por qué de por qué querríamos interoperabilidad JS?

... es un ejemplo y otro ). Realmente no funciona bien con muchos de los conceptos de alto nivel, como los genéricos. Por supuesto, también hay un gran beneficio con esta arquitectura: ahora todo Windows puede compartir las mismas API de WinRT.

Hay muchas cosas que odio de WinRT, ¿qué hay más en la lista?

El hecho de que incluso necesite saber sobre esto, es malo. De hecho, necesitaba crear 2 proyectos tan pequeños, y todo fue prueba y error, para entender lo que realmente puedo usar.

Así que hemos perdido varias de las ventajas del código administrado a las que nos hemos acostumbrado a lo largo de los años. Definitivamente todavía parece un paso atrás de WPF: encuentro errores y funciones incompletas todo el tiempo. Creo que el # 1830 nunca sucedería en los días de WPF. Todavía tenemos que avanzar de alguna manera.

Sí, lo hacemos ...

WinUI 3.0 es claramente un paso en la dirección correcta para intentar arreglar esto al menos en la interfaz. Sin embargo, preferiría que Microsoft implemente un proceso de desarrollo más sólido y más pruebas antes de lanzar nuevos controles ... [...]

De acuerdo al 100%.

Es triste para mí ver lo que una vez fue la plataforma de interfaz de usuario más poderosa, WPF, evolucionar hacia esto. Pero Microsoft ahora, de forma lenta pero segura, escucha los comentarios y arregla las cosas. Se entiende que hay mucho más trabajo por hacer.

Sí, claramente hay gente increíble en MS que está escuchando. Esperemos que podamos darle la vuelta a esto ...

La API de consulta de archivos es más que lenta

Aparentemente, alguien encontró una solución a esto. Claramente, es realmente muy triste que esto haya tomado tanto tiempo, y esta no es la forma preferida en la que me gustaría lidiar con la búsqueda de archivos, pero al menos realmente funciona.
https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

¡Muchas gracias a @ duke7553 !

@jtorjo ¡ Feliz de ayudar!

Encuentro esta discusión muy interesante y de hecho muy relevante para el futuro de la interfaz de usuario de Windows. Eso es porque WinUI no está en el vacío. Todo este repositorio tiene muy poco valor a menos que sea útil para crear aplicaciones que se ejecuten en algo que no sea WinRT / UWP. WinUI 3.0 no podría llegar lo suficientemente pronto.

Tenemos una visión y una hoja de ruta para la interfaz de usuario en Windows, pero eso se encuentra en la parte superior de la pila y no hay una visión de lo que hay debajo de esa capa de superficie:
¿WinUI se ve bien? SÍ
¿Puedes crear aplicaciones modernas y atractivas en Windows ahora (JAN2020)? NO
¿Puedes crear una buena aplicación con UWP? ¡INFIERNO NO!

Realmente no podemos avanzar sin abordar el elefante en la sala: mencioné anteriormente el hecho de que WinRT y UWP fueron fallas totales, no solo en el negocio sino también en la tecnología. Personalmente, estoy entre el recuento de cadáveres. Dejé de desarrollar mi proyecto de pasatiempo cuando no pude averiguar cómo reproducir un sonido cuando mi aplicación perdió el enfoque. Trivial. ¿Las cosas triviales tienen que ser tan difíciles como en UWP? ¿Puedes llamar genial a una plataforma cuando las cosas triviales son imposiblemente difíciles? WinUI es solo parte de una plataforma, ¿no es así?

Otro elefante en la habitación. Si alguien pregunta: Quiero crear un nuevo programa de Windows, ¿cuál es la mejor manera de hacerlo? ¡No hay una respuesta directa en JAN2020! Si intenta poner UWP en la respuesta, lo pasará mal. (¿Hay un solo comentario, publicación de blog, video de YouTube donde alguien dijo: Hice una gran aplicación con UWP y me gustó el proceso? Todos sabemos que no lo hay. Nadie está escribiendo sobre cómo crear una aplicación con UWP, literalmente no no existe en Internet). WPF? Sin controles modernos: tecnología muerta, no es una buena idea (aunque es mejor que UWP). La respuesta honesta tendría que ser: ¿probar con el electrón, tal vez? VSCode está hecho con eso, así que sabes que puedes hacer una buena aplicación con él.

Y esta idea de que puedes hacer una aplicación para Windows con cualquier idioma que te guste es solo una excusa. Estamos en una situación en la que puedes crear una aplicación para UWP muy mala con el idioma que desees. Pero no es al menos UNA excelente manera de hacerlo.

¿Lo navie mencionado antes en el hilo? Completamente de acuerdo. Visual Studio: el Juggernaut en sí (UI) está hecho con código administrado: WPF. Es genial, incluso fantástico. Si bien incluso Microsoft no puede crear aplicaciones correctas con este supuesto código nativo de superion. Veo un comportamiento inesperado todos los días con OneNote, Weather e incluso Start / Search / Taskbar. Se siente inestable y, a veces, el enfoque no funciona como debería.

Este es un tema rico e importante. Muy relevante para WinUI y, lamentablemente, no hay mejor lugar para hablar de ello. Estos temas deben ser tratados de forma abierta por Microsoft.

Tenemos una visión y una hoja de ruta para la interfaz de usuario en Windows, pero eso se encuentra en la parte superior de la pila y no hay una visión de lo que hay debajo de esa capa de superficie:
¿WinUI se ve bien? SÍ

¡Sí lo es!

¿Puedes crear aplicaciones modernas y atractivas en Windows ahora (JAN2020)? NO

Creo que puedes, pero es realmente muy difícil. Las cosas triviales son increíblemente difíciles de hacer (soy la prueba viviente de que es posible, pero seguro que necesitas nervios de acero):

• en el frente de la interfaz de usuario, habrá problemas, pero por lo general lo dominará
• en el frente de "cualquier otra cosa", las cosas son bastante oscuras.
• tratar con archivos en UWP es un infierno, debido a la API de StorageFile / Folder, que, para decirlo de manera intermedia, odio con todo mi corazón

Realmente no podemos avanzar sin abordar el elefante en la sala: mencioné anteriormente el hecho de que WinRT y UWP fueron fallas totales, no solo en el negocio sino también en la tecnología. Personalmente, estoy entre el recuento de cadáveres. Dejé de desarrollar mi proyecto de pasatiempo cuando no pude averiguar cómo reproducir un sonido cuando mi aplicación perdió el enfoque. Trivial. Hacer cosas triviales tiene que ser tan difícil como en

Acordado. De hecho, reproducir sonidos del sistema, que en WPF es como SystemSounds.Beep.Play() , no está disponible en UWP.

Básicamente, no hay una biblioteca de sonido en UWP, debido a las "grandes" restricciones de WinRT, lo que básicamente significa que no puede importar ninguna función de archivos DLL que sean win32. Prácticamente, todas las bibliotecas decentes no se pueden migrar a UWP. Sin bibliotecas, sin aplicaciones.

En la "biblioteca de sonidos" de UWP, naudio ha hecho todo lo posible por trabajar en UWP. Claramente, fracasó. Hice una bifurcación, eliminé muchos #ifdefs y ahora funciona para mis necesidades. Nunca podré publicar mi aplicación en MS Store, ni quiero hacerlo.

En mi opinión, el mejor paso en la dirección correcta es que la EM

1. Finalmente, enfóquese en el escritorio de Windows PRIMERO . Deja de perseguir mil plataformas, como Hololens, Xbox y similares. Claro, habrá personas que quieran desarrollar para esas plataformas, pero el porcentaje es minúsculo.
2. Elimine todas las restricciones de API para que las personas puedan compilar bibliotecas en UWP
3. Una vez que solicite broadSystemAccess, simplemente entréguelo y deje de ser tan sobreprotector.
4. Una vez que solicite broadSystemAccess, permita System.IO en todos los HDD
5. Facilite la distribución fuera de la tienda MS (+ solucione el problema del "Certificado nuevo")

Otro elefante en la habitación. Si alguien pregunta: Quiero crear un nuevo programa de Windows, ¿cuál es la mejor manera de hacerlo? ¡No hay una respuesta directa en JAN2020! Si intenta poner UWP en la respuesta, lo pasará mal. (¿Hay un solo comentario, publicación de blog, video de YouTube donde alguien dijo: Hice una gran aplicación con UWP y me gustó el proceso? Todos sabemos que no lo hay. Nadie está escribiendo sobre cómo crear una aplicación con UWP, literalmente no no existe en Internet). WPF? Sin controles modernos -

Sí, estoy de acuerdo: encontrar buenos recursos en UWP es casi cero. Muchos problemas, solo tendrás que abordarlos y solucionarlos por tu cuenta.

tecnología muerta, no es una buena idea (aunque es mejor que UWP). La respuesta honesta tendría que ser: ¿probar con el electrón, tal vez? VSCode está hecho con eso, así que sabes que puedes hacer una buena aplicación con él.

Sobre WPF solo tengo palabras de elogio. Lo he desarrollado durante bastantes años. y aunque la curva de aprendizaje es bastante empinada, una vez que lo dominas, ¡es increíble! Encontré algunos errores graves, que sabía que nunca se solucionarían, pero eso es todo.

Me vi obligado a cambiarme a UWP, ya que para que mi aplicación sea lo suficientemente rápida, tuve que usar win2d. Hay cosas que faltan en UWP en lo que respecta a la interfaz de usuario (como, en el momento en que comencé a portar, no hay una forma nativa de definir Cursor para un control), pero en general, siempre encontré soluciones alternativas .

¿Lo navie mencionado antes en el hilo? Completamente de acuerdo. Visual Studio: el Juggernaut en sí (UI) está hecho con código administrado: WPF. Es genial, incluso fantástico. Aunque ni siquiera Microsoft

Claramente, apuesto mi culo **, a que no podrías crear Visual Studio en UWP por mi vida, y no estoy hablando de la interfaz de usuario, podrías igualar y superar la interfaz de usuario de Visual Studio, pero el resto. ...

Este es un tema rico e importante. Muy relevante para WinUI y, lamentablemente, no hay mejor lugar para hablar de ello. Estos temas deben ser tratados de forma abierta por Microsoft.

100% de acuerdo!

¿Puedes crear aplicaciones modernas y atractivas en Windows ahora (JAN2020)? NO

Creo que puedes, pero es realmente muy difícil. Las cosas triviales son increíblemente difíciles de hacer (soy la prueba viviente de que es posible, pero seguro que necesitas nervios de acero):

• en el frente de la interfaz de usuario, habrá problemas, pero por lo general lo dominará
• en el frente de "cualquier otra cosa", las cosas son bastante oscuras.
• tratar con archivos en UWP es un infierno, debido a la API de StorageFile / Folder, que, para decirlo de manera intermedia, odio con todo mi corazón

Aquí somos como perros apaleados. En realidad, ¡es tan difícil crear una nueva aplicación moderna para el escritorio de Windows! ¿No debería haber al menos una forma excelente de hacer aplicaciones? Cuando vaya a Microsoft Store en Windows e intente desplazarse por la categoría de aplicaciones, no encontrará ninguna aplicación decente hecha con UWP. Por cierto, no puedo comprobarlo yo mismo porque ...

Sí, señoras y señores de la aplicación "moderna" y "nativa". Dado que Windows ahora es prácticamente gratuito, la principal fuente de monetización no debería ser la aplicación más sólida del sistema, pero estoy divagando. En realidad, no es necesario investigar la aplicación para saber con qué tecnología se creó. Solo una mirada y podrá saber si se creó con UWP. No hay proyectos comerciales serios construidos con UWP, y lo que se construye con él es ... ya sabes ...

Y eso es porque ES taaaan difícil. Window10 es la plataforma más grande después de Internet y Android. ¡Pero Nadie está creando aplicaciones para ello con las herramientas que supuestamente se hicieron para ese propósito! Solo contempla eso. ¡Es más fácil crear una aplicación Electron para 3 sistemas operativos que solo para Windows con UWP!

¿Está bien para nosotros, perros apaleados, que solo queremos crear aplicaciones de escritorio de Windows para exigir herramientas excelentes? ¡Digo sin disculpas que sí! Pero todo lo que tenemos es silencio de radio de Microsoft. ¿Quién quiere escuchar un cuento de hadas de que su aplicación podría funcionar en Holo Lens, Windows Phone o Xbox? Nadie. Después de 5 años, no ha habido ninguna aplicación comercial que funcione en 2 de las plataformas prometidas para UWP. (Principalmente porque esas plataformas no salen). Una vez más, ¡reflexiona sobre eso! Lo mejor que nos ha pasado es que WinUI está siendo portado DE NUEVO a la antigua win32.

Me encanta el escritorio de Windows, aprendí a programar haciendo C # en WinForms y WPF. Y fue fácil y excelente para un novato como yo. Hoy estoy salivando mirando esos jugosos controles en WinUI, pero alguien tiene que aclarar el panorama general de la plataforma. Necesitamos un mensaje claro sobre el liderazgo tecnológico práctico y no sobre las aspiraciones de mercado de algunos ejecutivos de empresas de EM.

Hola,
Llego un poco tarde a esta discusión, pero quería dar mi humilde opinión de todos modos.
Con respecto a las aplicaciones comerciales para UWP: una que me viene a la mente es Adobe XD. Este es UWP y se siente muy maduro y completo.
Mis propias experiencias con UWP, siendo un desarrollador de .Net durante 13 años: por supuesto, puede crear una aplicación de buen aspecto y rendimiento con ella. Pero ... no es una experiencia hermosa. Estamos en el proceso de crear una aplicación médica y muchas de las cosas que ya se mencionaron aquí y en otros lugares también las encontramos:

• API de archivo lento increíble
• Muy lento "tiempo F5". Entonces, entrar en depuración para compilar / iniciar la aplicación para probar algo es al menos 10 veces más lento que en WPF. (piense aproximadamente 2 minutos en un Surface Book 2)
• En general, estar restringido por el sandbox.
  Estos son solo los que tengo en la parte superior de la cabeza. Al final, cuando se lanzó XamlIslands, decidimos alojar nuestra interfaz de usuario de UWP completa en una ventana de WPF, con un núcleo .net rápido detrás de todo. No creo que mucha gente haya usado XamlIsland en esta magnitud (concluyendo de los problemas de github / PR que creamos). Sin embargo, esta tecnología también tiene algunas limitaciones muy serias. A modo de ejemplo, el tiempo de compilación aumenta aún más. Perdiendo la capacidad de editar en vivo Xaml. ¿Creando un instalador para una aplicación WPF / XamlIsland / UWP seria? Duele. etc ...
  Entonces, para resumir, por supuesto, se puede crear hermosas aplicaciones para UWP. Pero es tan improductivo y lento. Y restringido.
  Así que, como muchos otros, estamos esperando con entusiasmo el lanzamiento y la maduración de WinUI 3, pudiendo tener el frontend "UWP" y el backend .net core (o .net 5 ;-)) sin trucos.

@jasonwurzel esos son algunos puntos muy buenos

• La API del archivo es lenta, pero mientras tanto @ duke7553 publicó una solución en # 1465 (comentario)
  Eso es cierto, pero no lo sabíamos en ese entonces. Es redundante decirlo, de alguna manera es una locura implementar esta solución solo para obtener una E / S rápida de archivos ...
• El tiempo F5 ralentiza las cosas y creo que se pueden utilizar algunas mejoras
• Tengo curiosidad por conocer las limitaciones con las que se encontró al intentar desarrollar una aplicación UWP regular en lugar de seguir la ruta de las islas xaml. Estoy trabajando en algunas aplicaciones en este momento y pude resolver cualquier limitación al incluir procesos Win32, pero entiendo que no siempre es la forma ideal de crear una aplicación.
  Supongo que al final fue la suma de los obstáculos que encontramos, sin duda algunos de los cuales podrían haberse resuelto con procesos externos. Sin ningún orden en particular:
• Observación de la bandeja de CD / puertos USB para medios insertados
• observar algún directorio elegido por el usuario en cualquier lugar de la PC local y hacer que la aplicación / Windows recuerde el derecho de acceso al actualizar
• exigiendo broadFileSystemAccess, obteniendo la excepción, abriendo la página de configuración de Windows correspondiente, el usuario verifica la palanca de la aplicación, la aplicación boom se cierra sin previo aviso, no hay posibilidad de intervenir.
• mismo dominio: permitir que el usuario elija un directorio sin tener que abrir un FolderPicker al estilo de Windows (no, no queremos diseñar nuestra aplicación de pantalla completa de una manera agradable y optimizada y luego el diálogo de Windows salta a la cara del usuario)
• problema del huevo y la gallina: disponibilidad / soporte de paquetes nuget (muchas más personas todavía usan WPF, por lo que encontrar soluciones a pequeños problemas es mucho más rápido)
• controlando la ubicación de la instalación

@AndrewPawlowski Me sorprende que digas eso cuando hay muchas aplicaciones geniales para UWP que son modernas y atractivas, incluidas algunas que son de código abierto en GitHub.
Solo porque renunció a crear una aplicación porque no descubrió cómo hacer algo no significa que una plataforma haya fallado, significa que su aplicación falló. Si miras a tu alrededor, puedes ver a muchos desarrolladores que trabajaron duro y crearon algunas aplicaciones realmente buenas, incluidas aplicaciones que continúan reproduciendo sonido cuando la aplicación pierde el foco.

No digo que no sea posible, pero es muy, muy difícil. Y no estoy hablando de una aplicación simple "similar a un Bloc de notas", estoy hablando de una aplicación muy compleja que se ocupa de la interfaz de usuario / edición de video / edición de sonido / carga / guardar muchas cosas en el disco / (intentar y no tener éxito ) lanzar cosas (y por favor no me digas nada sobre la API de confianza completa). Estoy hablando de una aplicación de 50-100K + líneas de código.

Eso es mucho más difícil.

Y el hecho de que puedas reproducir un sonido cuando la aplicación pierde el enfoque, nadie dice que no puedas, pero debería ser mucho más fácil de lo que es ahora.

Pregunta si hay alguien que disfruta del proceso de desarrollo de aplicaciones para UWP y la respuesta es que hay muchas y en los últimos meses he recibido muchas solicitudes de otros desarrolladores para que ayuden en sus aplicaciones, la plataforma claramente está ganando interés.

Estoy de acuerdo, por eso me embarqué en la migración de mi aplicación a UWP. Pero ha sido un camino lleno de baches, y todavía lo es.

También afirma que no hay nadie escribiendo sobre el desarrollo de aplicaciones para UWP y tengo que decir que es simplemente falso, @rudyhuyn , Martin Zikmund son solo dos ejemplos de desarrolladores que escriben sobre UWP, pero también hay muchos otros.

Estoy totalmente de acuerdo, pero compárelo con la gente que escribe sobre wpf. Es una gota en el agua.

Simplemente haga una búsqueda simple en github: "c # wpf" (3701 resultados) vs "c # uwp" (337 resultados).
Estoy seguro de que si buscara lo mismo y filtrara por "número de confirmaciones> 500" (lo que significa que el usuario se quedó con el proyecto) -> encontrará una imagen más tenue.

Esto muestra que puede crear tanto aplicaciones atractivas en 2020 como aplicaciones modernas para UWP y que muchas de sus declaraciones no son precisas.

Ruego no estar de acuerdo, para poder desarrollar una aplicación compleja para UWP y ser feliz de hacerlo,> estamos muy lejos de eso.

• Tengo curiosidad por conocer las limitaciones con las que se encontró al intentar desarrollar una aplicación UWP regular en lugar de seguir la ruta de las islas xaml. Estoy trabajando en algunas aplicaciones en este momento y pude resolver cualquier limitación al incluir procesos Win32, pero entiendo que no siempre es la forma ideal de crear una aplicación.

Por mi parte, intenté usar win2d usando Xaml Islands en septiembre, no funcionó ni un poco. Probé algunos de los ejemplos de MS y tampoco funcionaron. En ese momento, me di cuenta de que realmente necesito portar mi aplicación a UWP o, de lo contrario, esto nunca funcionará.

En cuanto a una prueba más reciente: https://github.com/microsoft/Win2D/issues/731

• Muy lento "tiempo F5". Entonces, entrar en depuración para compilar / iniciar la aplicación para probar algo es al menos 10 veces más lento que en WPF. (piense aproximadamente 2 minutos en un Surface Book 2)

¡Oh si! Ni siquiera mencioné esto, pero sí, es increíblemente lento. Lo he solucionado modificando los proyectos que compilo y los que no, y dependiendo de la parte de la aplicación en la que esté trabajando, esto es decente o horrible (y por decente, quiero decir, aproximadamente 10-15 segundos la mayor parte del tiempo)

• En general, estar restringido por el sandbox.

Oh sí :)

• La API del archivo es lenta, pero mientras tanto @ duke7553 publicó una solución en # 1465 (comentario)

De acuerdo, pero solo piense en cuánto tiempo le tomó a alguien encontrar esa solución, que claramente existía, pero estaba profundamente enterrada en los documentos. Y en este momento, probablemente muy pocas personas lo sepan (incluyéndome a mí).

Si realiza una búsqueda en Google, no encontrará ninguna de las publicaciones que muestren esa solución, por lo que probablemente pasarán unos meses antes de que la mayoría de los desarrolladores se den cuenta.

@jasonwurzel

Así que, como muchos otros, estamos esperando con entusiasmo el lanzamiento y la maduración de WinUI 3, pudiendo tener el frontend "UWP" y el backend .net core (o .net 5 ;-)) sin trucos.

Solo quiero señalar que MS dijo que una vez que aterrice .NET 5, podrá usarlo para sus proyectos de UWP sin problemas. No es necesario ningún "truco" o una situación como .NET Core 3.x. Aquí está la publicación del anuncio de .NET 5 nuevamente: https://devblogs.microsoft.com/dotnet/introducing-net-5/

sí, eso es a lo que me estaba refiriendo 👍

Creo que la palabra "completamente" en _ "completamente fuera de contacto con la realidad" _ era injusta e inexacta, pero @jtorjo estaba muy frustrado por razones comprensibles. Si Microsoft estuviera completamente fuera de contacto con la realidad, entonces el equipo de WinUI no estaría trabajando para separar WinUI de UWP. En general, el equipo de WinUI parece estar más en contacto que otros departamentos de UWP / WinRT. Creo que una descripción precisa sería que existe cierto grado de falta de contacto en algunos equipos en este momento.

Importancia de una GUI de lista con columnas

Aunque el equipo de WinUI es probablemente el equipo con mejor desempeño de todos los equipos relacionados con UWP / WinRT, creo que todavía se cometieron algunos errores en la gestión de proyectos de WinUI. Una GUI de lista con columnas (como DataGrid ) es una característica principal esencial que todos los clientes utilizan a diario (como en el Explorador de Windows y varios otros ejemplos como Spotify, etc.). Desde el inicio de WinRT, ¡han pasado 8 años sin soporte oficial para una GUI de lista con columnas! Encuentro esta situación impactante. Por esa razón y otras, digo que UWP sigue siendo una versión alfa hoy (aún no tiene todas las funciones, por lo tanto, no es una verdadera beta). No es sorprendente que la mayoría de los desarrolladores de aplicaciones nunca se hayan tomado en serio UWP y, por lo tanto, Windows Mobile terminó siendo cancelado.

Una versión oficial de DataGrid de WinUI se ha retrasado durante los últimos 8 años. DataGrid se retrasó en el momento en que se lanzó WinRT 1.0 porque Microsoft nunca debería haber iniciado un nuevo sistema (como expliqué en mi mensaje anterior sobre Nokia, etc.). 8 años sin fundamentos, 8 años de retraso, y ahora el equipo de WinUI quiere hacer que DataGrid esté aún más retrasado perdiendo aún más tiempo al degradarlo a código nativo. Por varias razones, es difícil tomar UWP en serio y difícil confiar en él.

C ++ / CX fue reemplazado recientemente por C ++ / WinRT

Aquí hay otro ejemplo de estar "fuera de contacto con la realidad":
Obviamente, el software debe escribirse de una manera sensata (me refiero a "cuerdo" como terminología, no a un insulto como "Estás loco"). "Cuerdo" como terminología significa que no debe usar magia negra oscura y complicada para lograr una tarea sencilla y directa.
C ++ / CX fue reemplazado recientemente por C ++ / WinRT. C ++ / WinRT usa el llamado _ "patrón de plantilla curiosamente recurrente" _ para llamar a funciones a través de envío estático. Ese es un diseño realmente terrible porque no es un diseño cuerdo porque se trata de usar magia negra oscura y complicada para lograr una tarea simple y directa. Además, CLR / C # ya resolvió este problema hace décadas, por lo tanto, ¿por qué el equipo de WinRT sigue jugando y perdiendo el tiempo con temas muy antiguos y primitivos que ya se resolvieron hace décadas? ¿Por qué el equipo de WinRT está reinventando la rueda?

Busqué el NUEVO código fuente de C ++ / WinRT y mi impresión es que es un software de muy baja calidad, pero el equipo de WinRT lo ve como maravillosamente avanzado. Por tanto, "fuera de contacto con la realidad" es una descripción precisa.

El sistema de archivos de UWP sigue siendo la versión alfa

@jtorjo y otras personas han mencionado los problemas de rendimiento de las API del sistema de archivos de UWP. El rendimiento está por debajo del nivel necesario para describirlo como una versión beta con todas las funciones. Otra razón por la que la API de UWP FS sigue siendo una versión alfa es la falta de capacidad para mover una carpeta. Hace 25 años, Windows 95 tenía la capacidad de mover carpetas, pero a UWP todavía le falta esta capacidad fundamental. De alguna manera, Windows 95 es más poderoso que UWP. De varias formas, WPF y .NET Framework siguen siendo más potentes que UWP. Microsoft esperaba que los desarrolladores de aplicaciones tomaran UWP en serio, pero esto era muy irrazonable (o "fuera de contacto con la realidad") porque Microsoft nunca progresó UWP de la etapa alfa a la beta.

Windows asumió que los dispositivos móviles como "App Dev" eran el mercado en auge, y era moderno porque tenía la seguridad y la duración de la batería en su esencia.

Fueron expulsados ​​del mercado móvil debido a las fuerzas del mercado. Los dispositivos como Hololens y Xbox están tratando de eliminar el soporte heredado de Win32, para simplificar el desarrollo para ellos y una base de código del sistema operativo más eficiente.

Estas apuestas no han valido la pena, pero los ideales para un modelo moderno de entrega de aplicaciones y seguridad son objetivos loables.

Entonces, después de un examen de conciencia, Microsoft decidió desenredar el marco de la aplicación moderna, del marco de la interfaz de usuario.

WinUI 3.0 debería ser lo mejor de ambos mundos, permitiendo el acceso a la mayoría de las API modernas que se benefician de la proyección del lenguaje, los estándares de codificación modernos y la familiaridad con los dispositivos móviles. Pero también permite que las aplicaciones utilicen los tiempos de ejecución de Win32 y .NET, menos seguros pero más potentes.

Por supuesto, depender del acceso a Win32 restringirá las plataformas en las que se ejecutarán, y quién sabe hacia dónde se moverá el mercado en los próximos años.

Sugeriría, en lugar de insistir en los mismos motivos y quejas, esta comunidad se use para preguntar qué quieren los desarrolladores en el futuro, y no para culpar o despotricar de una manera que no haga avanzar el proyecto.

@mdtauk escribió:

Fueron expulsados ​​del mercado móvil debido a las fuerzas del mercado.

A varios miembros del personal de UWP / WinRT les gustaría creer mucho esa explicación, para _ sentirse_ mejor sobre lo que sucedió. No creo esa explicación. Creo que UWP falló debido a:

1. Mala gestión, y
2. No abordar el problema de los desarrolladores de aplicaciones que posponen perpetuamente las versiones para UWP de sus aplicaciones debido a la impresión de que UWP no estaba lista y todavía no está lista para el horario de máxima audiencia, y
3. Uso excesivo de viejas técnicas improductivas de ingeniería de software, y
4. No ganarse la confianza de la mayoría de los desarrolladores de aplicaciones, y
5. Cosas que hicieron que UWP pareciera tonto, como promover el uso de JavaScript en lugar de Java, lo que significa que no se reconoce la diferencia entre un lenguaje de scripting y un lenguaje de programación.

Lamentablemente, considerando que la mala administración es la razón principal del fracaso de UWP, es irónico que UWP esté escrito en código no administrado porque la palabra "no administrado" realmente resume la razón del error: mala administración tanto del código fuente como de la administración del proyecto.

@jtorjo escribió:

Nativo, en el contexto de "compilar en .net nativo", creo que es algo bueno

Estoy de acuerdo. La diferencia está en la generación automática de código nativo frente a la manual. Cuando el código nativo es producido automáticamente por un compilador o una herramienta, generalmente es algo bueno, mientras que si el código fuente nativo se escribe manualmente , entonces la productividad, el conjunto de características y la confiabilidad sufren sustancialmente.

Si observa el período de tiempo del desarrollo de WPF frente al período de tiempo del desarrollo de WinUI, entonces el desarrollo de WPF fue mucho más rápido (mucho mejor productividad), a pesar del hecho de que WinUI debería haber sido más fácil / más rápido de desarrollar que WPF porque WinUI reutiliza muchos de los mismos conceptos que ya se crearon para WPF. Desafortunadamente, Microsoft optó por realizar un uso excesivo de viejas técnicas de ingeniería de software que contradecían su propio punto de vista previo y sabotearon su propia productividad y llevaron a los desarrolladores de aplicaciones a posponer perpetuamente el desarrollo de aplicaciones para UWP.

¿Qué se puede hacer ahora para solucionar los errores del pasado? Deje de repetir los mismos errores que llevaron al fracaso de UWP. No continúes como si nada malo hubiera pasado. Usaré DataGrid como ejemplo aquí: agregue nuevas funciones a DataGrid lugar de retrasar aún más DataGrid. No haga que DataGrid tenga un retraso de más de 8 años haciendo una reescritura / conversión manual inútil a código nativo.

A los usuarios finales no les importa si DataGrid está escrito en código administrado o no administrado, y no saben qué significan esos términos, por lo tanto, lo que es mucho más importante y sensato es mantenerlo con el código administrado tal como está y mejorar el funcionalidad / características de DataGrid. La cantidad de código nativo escrito manualmente en UWP ya es una situación desastrosa, entonces, ¿por qué empeorar la situación escribiendo aún más código nativo y aún más código obsoleto basado en Win16 / 32 y COM?

Entiendo que no puede simplemente tirar todo el código obsoleto, pero PUEDE dejar de empeorar la situación de lo que ya es. Es decir, deje de escribir código nativo aún más antiguo. Establezca una política que, a partir de ahora, todos los nuevos códigos / proyectos se escribirán utilizando técnicas modernas de ingeniería de software. No degrades el código administrado preexistente como DataGrid, etc.

El sistema de archivos de UWP sigue siendo la versión alfa
@jtorjo y otras personas han mencionado los problemas de rendimiento de las API del sistema de archivos de UWP. El rendimiento está por debajo del nivel necesario para describirlo como una versión beta con todas las funciones. [...]

Mencioné esto antes y lo mencionaré nuevamente: la API StorageFolder / StorageFile es una de las peores API que he visto. Estamos en el siglo XXI, y necesito preguntar "oh, por favor, ¿puedo tener acceso a esto? ¿Y a aquello? ¿Y luego agregarlos a la gran FuturesAccessList?"

¿Y necesito solicitar propiedades básicas de forma asincrónica, como el tamaño del archivo? No me importa qué razón podría haber tenido esto, pero está muy fuera de contacto con la realidad en este momento.

Estas apuestas no han valido la pena, pero los ideales para un modelo moderno de entrega de aplicaciones y seguridad son objetivos loables.

Estoy totalmente de acuerdo...

[....] Por supuesto, depender del acceso a Win32 restringirá las plataformas en las que se ejecutarán, y quién sabe a dónde se moverá el mercado en los próximos años. [...]

Estoy completamente de acuerdo, pero pensar demasiado en el futuro también puede ser un dolor ...
Con eso quiero decir: si restringe el acceso a Win32 desde el principio, la migración de bibliotecas será prácticamente un "no-go", por lo que no tendrá un presente, y mucho menos un futuro.

Al permitirnos usar también código Win32, sí, es posible que no podamos migrar a otra plataforma (próxima), pero al menos tendremos código por hoy. Y mañana, será otro día, y cuando lleguemos allí, encontraremos una manera de portar nuestro código si realmente queremos.

Pero hago lo que tengo que elegir y comprenderé los riesgos.

Sugeriría, en lugar de insistir en los mismos motivos y quejas, esta comunidad se use para preguntar qué quieren los desarrolladores en el futuro, y no para culpar o despotricar de una manera que no haga avanzar el proyecto.

No estoy seguro de si esto estaba dirigido a mí o algo así, no soy un hablante nativo de inglés. Habiendo dicho eso, definitivamente quiero que este proyecto siga adelante, pero creo que es importante que abordemos algunos problemas que nos impiden implementarlo, hoy.

Sugeriría, en lugar de insistir en los mismos motivos y quejas, esta comunidad se use para preguntar qué quieren los desarrolladores en el futuro, y no para culpar o despotricar de una manera que no haga avanzar el proyecto.

No estoy seguro de si esto estaba dirigido a mí o algo así, no soy un hablante nativo de inglés. Habiendo dicho eso, definitivamente quiero que este proyecto siga adelante, pero creo que es importante que abordemos algunos problemas que nos impiden implementarlo, hoy.

No me dirijo a nadie, pero el título de la discusión es un poco negativo y la gente no tiende a responder y abordar problemas legítimos, si están envueltos en insultos y acusaciones.

También ahora sabemos que un marco de aplicación Win32 / .NET vendrá con WinUI 3.0; no tiene mucho sentido seguir criticando por ser WinRT solo en el pasado. 😁

@jtorjo

Estamos en el siglo XXI, y necesito preguntar "oh, por favor, ¿puedo tener acceso a esto? ¿Y a aquello? ¿Y luego agregarlos a la gran FuturesAccessList?"

El hecho de que las aplicaciones tengan que preguntarle al usuario es, en mi opinión, un paso en la dirección correcta. El hecho de que, a diferencia de las aplicaciones de Winforms y WPF, la aplicación no puede simplemente escanear todos mis archivos y yo tengo el control sobre las carpetas a las que puede acceder, es muy importante en términos de seguridad. Si crees que es malo que limitemos los recursos a los que pueden acceder las aplicaciones para proteger al usuario, supongo que esa es tu opinión, pero no quiero que todas las aplicaciones hagan lo que quieran con mis archivos.

¿Y necesito solicitar propiedades básicas de forma asincrónica, como el tamaño del archivo? No me importa qué razón podría haber tenido esto, pero está muy fuera de contacto con la realidad en este momento.

Supongo que la razón era que no debería bloquear el hilo de la interfaz de usuario, ya que lo peor que puede pasar desde un punto de UX es que la aplicación ya no responde porque el desarrollador olvida que las operaciones del disco pueden tardar un poco. El uso de await puede solucionar el problema y le obliga a desbloquear el hilo de la interfaz de usuario en algún momento. (Al menos así es como entiendo async await).

Como @mdtauk señaló correctamente, el título de la discusión es de hecho un poco negativo, y en lugar de seguir repitiendo las mismas viejas quejas, tales discusiones deberían usarse para generar ideas para resolver tales problemas.

Creo que todos debemos tener en cuenta que debemos cumplir con el código de conducta de fuente abierta de Microsoft, mantener una discusión profesional y ser respetuosos con todos, independientemente de si están presentes o no.

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

El hecho de que las aplicaciones tengan que preguntarle al usuario es, en mi opinión, un paso en la dirección correcta. El hecho de que, a diferencia de las aplicaciones de Winforms y WPF, la aplicación no puede simplemente escanear todos mis archivos y yo tengo el control sobre las carpetas a las que puede acceder, es muy importante en términos de seguridad. Si crees que es malo que limitemos los recursos a los que pueden acceder las aplicaciones para proteger al usuario, supongo que esa es tu opinión, pero no quiero que todas las aplicaciones hagan lo que quieran con mis archivos.

Entonces, comenzamos con una gran desventaja en comparación con las aplicaciones WPF. Eso es una cosa, la otra es

1. Ya lo estoy preguntando en la instalación.
2. Incluso si los usuarios no prestan atención, Windows podría mostrar una vez más al usuario "Esta aplicación quiere acceder a sus archivos" y el usuario podría decir Sí / No. Estaría totalmente bien con eso. Sin embargo, esto está LEJOS de lo que está sucediendo.

¿Y necesito solicitar propiedades básicas de forma asincrónica, como el tamaño del archivo? No me importa qué razón podría haber tenido esto, pero está muy fuera de contacto con la realidad en este momento.

Supongo que la razón era que no debería bloquear el hilo de la interfaz de usuario, ya que lo peor que puede pasar desde un punto de UX es que la aplicación ya no responde porque el desarrollador se olvida

El tamaño del archivo debe estar precargado (igual que la fecha del último acceso / última fecha de escritura); es tan importante que debe precargarse cuando realiza una consulta de archivos.

Como @mdtauk señaló correctamente, el título de la discusión es de hecho un poco negativo, y en lugar de seguir repitiendo las mismas viejas quejas, tales discusiones deberían usarse para generar ideas para resolver tales problemas.

Quiero totalmente que estos se resuelvan, nada más.

Creo que todos debemos tener en cuenta que debemos cumplir con el código de conducta de fuente abierta de Microsoft, mantener una discusión profesional y ser respetuosos con todos, independientemente de si están presentes o no.

Esta discusión no habría tenido lugar aquí, si hubiéramos tenido un lugar para hacer estas preguntas y para que WinRT escuchara los comentarios en otros lugares.

No me dirijo a nadie, pero el título de la discusión es un poco negativo y la gente no tiende a responder y abordar problemas legítimos, si están envueltos en insultos y acusaciones.

Estoy de acuerdo en que es un poco negativo, una vez más, esto no habría sucedido si hubiera habido otro lugar para dar su opinión sobre los problemas de WinRT.

También ahora sabemos que un marco de aplicación Win32 / .NET vendrá con WinUI 3.0; no tiene mucho sentido seguir criticando por ser WinRT solo en el pasado. 😁

Honestamente, realmente espero que este sea el caso. Sin duda esperaré a que se resuelvan estos problemas y, personalmente, no puedo esperar a que esa plataforma que no sea sandbox esté disponible. Pero hasta entonces, todavía estoy trabajando en una aplicación y sigo enfrentando los problemas que describí en primer lugar.

Entonces, comenzamos con una gran desventaja en comparación con las aplicaciones WPF. Eso es una cosa, la otra es

Para ser claros, ¿dejar el uso como opción para negar que las aplicaciones accedan a todos los archivos es una desventaja en su opinión?
Nosotros, como desarrolladores, tenemos que desarrollar el software para los usuarios, no contra ellos. Y, en mi opinión, no dejar al usuario opción sobre qué datos ve su aplicación es una desventaja de seguridad para los usuarios.

1. Ya lo estoy preguntando en la instalación.

¿Te refieres a la capacidad "broadFileSystemAccess"? En mi opinión, hay muy pocas aplicaciones que tengan una razón legítima para tener esta capacidad. (como ya señaló @kmgallahan )
Solo mire todas las aplicaciones que usa a diario. ¿Cuántos de ellos necesitan acceso a todos los archivos todo el tiempo? Probablemente no tantos, si es que hay alguno.

Como dijiste en tu comentario inicial:

¿Crees que los usuarios harán felizmente lo anterior? No, no lo harán; de hecho, el 79,8% no lo hace (mis datos de AppCenter respaldan esto).

Creo que probablemente haya una razón por la que los usuarios no están contentos de hacer esto (además del hecho de que esta es una configuración de seguridad que tienen que cambiar).

Sin embargo, es posible que no conozca todos los casos comerciales que requieran acceso a todos los archivos, por lo que, si hay alguno, me alegra escucharlos. Al final del día, no estamos aquí para luchar sino para enriquecer los puntos de vista de los demás (con suerte) 😅

Editar:

El tamaño del archivo debe estar precargado (igual que la fecha del último acceso / última fecha de escritura); es tan importante que debe precargarse cuando realiza una consulta de archivos.

Oh, claro, sí, algunos de esos definitivamente deberían estar pre-recogidos. Estoy de acuerdo en que esto es algo inconveniente para nosotros, los desarrolladores.

Esta discusión no habría tenido lugar aquí, si hubiéramos tenido un lugar para hacer estas preguntas y para que WinRT escuchara los comentarios en otros lugares.

Oficialmente, el centro de comentarios es para eso (creo), pero sí, en algún momento se siente un poco insensible. Es de esperar que el centro de comentarios mejore. Por lo que puedo ver, ya le hicieron algunos cambios a lo largo del tiempo, así que creo que esto también cambiará.

@ Felix-Dev

Aquí está la publicación de anuncio de .NET 5 nuevamente

Gracias por vincularte a eso. En especial, encontré esta parte interesante, y creo que esta es una noticia positiva:

"La interoperabilidad de Java estará disponible en todas las plataformas.

También hay un poco de discusión sobre Java en los comentarios al final de esa página web, donde Rich Lander confirma la interoperabilidad bidireccional. Interpreto esto como una señal positiva de que Microsoft está volviendo a estar en contacto con la realidad. No soy fanático de Java (prefiero C #), pero reconozco que la interoperabilidad de Java es muy beneficiosa y debería haber sido el foco de UWP / WinRT desde el principio. Si UWP / WinRT le hubiera dado la máxima prioridad a Java y C # (código administrado) en lugar del viejo y torpe código nativo (C ++ / CX, Win16 / 32, COM), y si UWP no hubiera mezclado el propósito de JavaScript con Java, entonces UWP habría atraído a muchos más desarrolladores de aplicaciones, y Windows Mobile podría estar vivo hoy.

Nos guste o no, es necesario despertar y reconocer la realidad de la situación: el líder del mercado es Android con su enfoque en el desarrollo de aplicaciones Java. Java y C # significan código administrado. Microsoft cometió un error enormemente costoso cuando invirtió su punto de vista sobre el código administrado.

Aunque realmente no me gusta Java, tengo claro que las técnicas Java de Android son mucho mejores que la vieja y torpe forma en la que Microsoft está desarrollando WebView2 con el uso de técnicas de programación antiguas de Win16, como punteros de 16 bits frente a punteros de 32 bits. , y HRESULT lugar del moderno manejo de excepciones, etc. WebView2 usa LPCWSTR y L significa "puntero largo", es decir, un puntero de 32 bits en lugar de un puntero de 16 bits. punteros "cortos" en Win16. El W significa "caracteres anchos", lo que significa Unicode (UTF-16) en contraposición a los caracteres ASCII / ANSI de 8 bits. En comparación, el uso de Java por parte de Android es mucho más profesional, moderno e inspira confianza que lo que están haciendo algunos departamentos de Microsoft.

Entonces, en una nota positiva, es una gran noticia saber que Microsoft admitirá Java (aunque personalmente prefiero C # sobre Java). Los desarrolladores de aplicaciones de Android aumentarán su interés en Windows tan pronto como se lance una buena interoperabilidad Java confiable.

También ahora sabemos que un marco de aplicación Win32 / .NET vendrá con WinUI 3.0; no tiene mucho sentido seguir criticando por ser WinRT solo en el pasado. 😁

1. El futuro es brillante, me encanta lo que veo que se está desarrollando en WinUI.
2. El pasado fue bastante sombrío, para una plataforma con 900 MILLONES de dispositivos, la escasa prevalencia de UWP es difícil de defender. EDITAR: el pasado es el único lugar del que podemos aprender, por lo que es importante discutirlo.
3. El presente es, creo, es el punto principal de este hilo y no se está abordando. Si alguien quiere comenzar hoy una aplicación no trivial que tardará entre 1 y 1,5 años en desarrollarse, ¿qué consejo honesto se puede dar? Mi respuesta sería: experimenta con WinUI, crea tus librerías en dotnet Core y espera a que salga WinUI3.0 para empezar a crear tu aplicación. No se moleste con UWP porque querrá tirarlo de su aplicación de todos modos, probablemente no quiera diferentes plataformas, ya que la de 900 millones es bastante grande. Las preguntas sobre el presente no son triviales, las decisiones comerciales deben tomarse hoy.

Lo que no se dice, pero lo que realmente está sucediendo es que UWP y la interfaz de usuario moderna no se están extendiendo a win32, pero en realidad UWP se está refactorizando FUERA de la pila . ¿Por qué alguien querría lidiar con UWP cuando podría usar el poder de dotnet standard 2 y dotnet core 3 y todas las librerías que están disponibles con eso?

Acerca del sandboxing y otras buenas ideas introducidas en UWP: eran buenas ideas, pero podrían haberse ejecutado mucho mejor. Espero que vuelvan y que exista la posibilidad de OPT-IN en una caja de arena u OPT-IN en la administración estatal similar a UWP. Como desarrolladores, queremos servir a los usuarios, pero en UWP nos amenazaron como el problema que la plataforma necesitaba contener.

¿Qué consejo honesto se puede dar? ¿Esperar?

@AndrewPawlowski Si ha determinado que UWP y la caja de arena no funcionan para usted, creo que escribir una aplicación WPF empaquetada con MSIX es una buena opción hasta que llegue WinUI 3. Ya puede llamar a las API exclusivas de Windows 10, proporcionar al usuario una experiencia de instalación / desinstalación moderna y, en general, elegir de la superficie de la API de Windows 10 lo que le gusta y lo que no (es decir, puede comenzar a usar las API de Windows 10 Shell). Es realmente un placer trabajar con algunas API de WinRT en comparación con las formas anteriores de win32 y creo que algunos escenarios incluso se hacen mejor en DesktopBridge en lugar de UWP puro. Caso en cuestión: al registrar una aplicación para el inicio automático al iniciar sesión, consulte esta publicación para ver una comparación del comportamiento de UWP frente a DesktopBridge. En el caso de DesktopBridge, aún así, en última instancia, deja al usuario en control, pero no se le pedirá al usuario constantemente dos veces (primero, un interruptor en la aplicación, luego un mensaje del sistema pidiendo confirmación) al habilitar el inicio en el registro. en la aplicación.

Desafortunadamente, muchas partes de las API de WPF realmente muestran su edad ahora en comparación con las API de IU de UWP, por lo que solo tendrá que vivir con eso unos meses más (al menos). Los muchos kits de herramientas de WPF disponibles mitigarán este hecho, pero si realmente desea una apariencia nativa para su aplicación de escritorio de Windows (¡y una experiencia de desarrollo XAML moderna!), Realmente no podrá escapar de las API de IU de UWP (y más tarde las API de WinUI 3). Eso significa que, incluso si puede reutilizar parte del código de la interfaz de usuario de WPF para WinUI más adelante, la modernización de la interfaz de usuario seguirá siendo un elemento de trabajo bastante grande, creo.

Ese es el estado del desarrollo de aplicaciones nativas de Windows que veo actualmente para usted si no puede esperar hasta que se envíe WinUI 3 y UWP no sea una opción para usted.

@AndrewPawlowski

1. El futuro es brillante, me encanta lo que veo que se está desarrollando en WinUI.

Concurrir

1. El pasado fue bastante sombrío, para una plataforma con 900 MILLONES de dispositivos, la escasa prevalencia de UWP es difícil de defender. EDITAR: el pasado es el único lugar del que podemos aprender, por lo que es importante discutirlo.
2. El presente es, creo, es el punto principal de este hilo y no se está abordando. Si alguien quiere comenzar hoy una aplicación no trivial que tardará entre 1 y 1,5 años en desarrollarse, ¿qué consejo honesto se puede dar? Mi respuesta sería: experimenta con WinUI, crea tus librerías en dotnet Core y espera a que salga WinUI3.0 para empezar a crear tu aplicación. No se moleste con UWP porque

Mi pensamiento inicial fue el mismo, pero no esperé ...

Acerca del sandboxing y otras buenas ideas introducidas en UWP: eran buenas ideas, pero podrían haberse ejecutado mucho mejor.

100% de acuerdo

Sin embargo, es posible que no conozca todos los casos comerciales que requieran acceso a todos los archivos, por lo que, si hay alguno, me alegra escucharlos. Al final del día, no estamos aquí para luchar sino para enriquecer los puntos de vista de los demás (con suerte) 😅

En cualquier lugar donde desee obtener una vista previa de las cosas, querrá un acceso rápido a los archivos. En mi caso, quiero obtener una vista previa de las carpetas para mostrar visualmente al usuario dónde están las fotos / videos, y para los videos, quiero que el usuario obtenga una vista previa del video antes de seleccionarlo. El punto es: el selector de archivos ofrece una experiencia bastante insatisfactoria, y quería enriquecer eso.

Oficialmente, el centro de comentarios es para eso (creo), pero sí, en algún momento se siente un poco insensible. Es de esperar que el centro de comentarios mejore. Por lo que puedo ver, ya le hicieron algunos cambios a lo largo del tiempo, así que creo que esto también cambiará (^ ∇ ^)

Personalmente, no me gusta el centro de comentarios, es demasiado poco específico, entre otros problemas.

@jtorjo @chingucoding feedback hub para WinRT APIs podría ser reemplazado / emparejado con Microsoft Q&A pronto, consulte este compromiso: https://github.com/MicrosoftDocs/winrt-api/commit/efcc4e041122e8a816a12c0581199c2f36ba36fc

Como se ha mencionado a Chigusa allí: @chigy ¿Será la plataforma de preguntas y respuestas de Microsoft la plataforma de comentarios preferida para las API de WinRT que no son de WinUI? Si no es así, ¿cómo se relacionará con el centro de comentarios (es decir, archivar errores / preguntas sobre preguntas y respuestas, solicitudes de API en el centro de comentarios, ...)?

Ojalá no terminemos con tres plataformas de comentarios diferentes 😆

Dado que esta es una discusión sobre UWP, puedo promover una solicitud de función: Permitir verbos del menú contextual con la integración del explorador de archivos sin tener una asociación de tipo de archivo https://aka.ms/AA71n2t por cierto. https://aka.ms/AA6rmrk (pero está en la categoría incorrecta, ¿tal vez alguien pueda arreglar esto?)

Una buena fuente de solicitudes de funciones es:
https://web.archive.org/web/20161221051552/https : //wpdev.uservoice.com/forums/110705-universal-windows-platform/category/171141-missing-apis
Lástima que la instantánea de esta voz de usuario sea bastante antigua (2016). Puedo recordar que había cosas como:

• alinee el comportamiento de la solicitud broadFileSystemAccess como se comportaría al solicitar la cámara, la ubicación, la aplicación de inicio al inicio ...
• auto. impresión (actualmente solo es compatible con POS en IoT hasta donde recuerdo)
• hacer que la impresión sea más configurable

@jtorjo

En cualquier lugar donde desee obtener una vista previa de las cosas, querrá un acceso rápido a los archivos. En mi caso, quiero obtener una vista previa de las carpetas para mostrar visualmente al usuario dónde están las fotos / videos, y para los videos, quiero que el usuario obtenga una vista previa del video antes de seleccionarlo. El punto es: el selector de archivos ofrece una experiencia bastante insatisfactoria, y quería enriquecer eso.

Supongo que para eso primero debes dejar que el usuario elija una carpeta en la que quiera usar tu aplicación. Después de todo, el usuario sabe mejor dónde guardó sus videos.

De lo contrario, es posible que desee echar un vistazo a:
https://docs.microsoft.com/en-us/windows/uwp/files/quickstart-managing-folders-in-the-music-pictures-and-videos-libraries

Pero para ser honesto, no sé qué exactamente lo ayudaría broadFileSystemAccess en ese caso. No puede estar seguro de dónde están exactamente los archivos (a diferencia del usuario). Pero tal vez no entiendo completamente la idea de su aplicación correctamente.

@ Felix-Dev
Gracias por la información, no sabía que los comentarios de WinRT podrían cambiar.

Ojalá no terminemos con tres plataformas de comentarios diferentes 😆

¡Jaja sí, ojalá que no!

@jtorjo : ¿ha considerado cancelar la migración de su aplicación de WPF a UWP? Puede cancelarlo y esperar hasta que se publique WinUI 3, y luego no se verá obligado a usar la API problemática del sistema de archivos UWP, broadFileSystemAccess, etc. Mientras tanto, mientras espera WinUI 3, puede continuar entregue nuevas versiones de su aplicación a sus usuarios al continuar desarrollando la versión WPF de su aplicación.

Durante los 8 años transcurridos desde el comienzo de WinRT, nunca hemos proporcionado ninguna aplicación de WinRT o UWP a nuestros usuarios. En su lugar, les hemos proporcionado muchas actualizaciones que continúan usando la versión WPF de nuestro software. Nuestros usuarios no tienen ninguna queja sobre esto porque no les importan los detalles técnicos como WPF, WinUI, UWP, sino que les importa qué tan bien funciona la aplicación y qué funcionalidad tiene. Nuestros usuarios tampoco tienen ninguna queja sobre la GUI antigua porque nuestras aplicaciones WPF incluyen un montón de modernizaciones de GUI.

@AndrewPawlowski dijo "experimentar con WinUI". Sí, experimente. He escrito un montón de código para UWP y WinUI a lo largo de los años, pero todo es código experimental, alfa o beta. Nunca llegué a un punto en el que me sintiera lo suficientemente cómodo como para lanzar aplicaciones para UWP a los usuarios.

La separación de WinUI 3 de UWP es de gran ayuda, pero no creo que sea una solución completa. WinUI 3 no aborda la baja productividad / lento ritmo de desarrollo de WinUI: WPF se desarrolló mucho más rápido que WinUI, aunque WPF era más difícil que WinUI.

El equipo de WinUI dice que el ritmo se acelerará cuando WinUI 3 sea de código abierto, y tal vez lo sea, pero personalmente no escribiré ninguna contribución de C ++ / CX, C ++ / WinRT, Win16 / 32 o COM para WinUI 3. I Comencé mi carrera con Win16 / Win32 hace décadas, y Win32 era una pesadilla, y no tengo ninguna intención de volver a técnicas de programación tan antiguas y problemáticas. A lo largo de los años, mantuve mis habilidades de ingeniería de software actualizadas y cambié a C # y .NET Framework, y fue una mejora y un beneficio importantes, y no volveré a la pesadilla del antiguo Win16 / 32. días y grandes cantidades de código nativo escrito manualmente.

@AndrewPawlowski escribió:

¿Qué consejo honesto se puede dar? ¿Esperar?

Esa es una pregunta realmente difícil de responder. Por un lado, sí, espera a WinUI 3, pero por otro lado, WinUI 3 no es una resolución completa del gran problema que inició WinRT hace 8 años. WinUI 3 es una útil resolución parcial.

Gran video de Ignite: https://youtu.be/Ul5JcdIJv5s

Creo que gran parte de la discusión aquí cuestiona el propósito de WinRT. Tanto los desarrolladores como los usuarios todavía se preguntan qué papel desempeñará una vez que WinUI 3 y .NET 5.0 permitan una fácil interacción entre las diferentes tecnologías. Sin mencionar, la eventual capacidad de elegir entre los modelos de aplicaciones de espacio aislado y los clásicos.

Supongo que escribir nuevas API de WinRT es más fácil para Microsoft de hacer internamente, lo que explica por qué han declarado muchas veces antes que la mayor parte de la innovación de la capa de API se realizará dentro de WinRT. Esto significa que para las aplicaciones nuevas y modernas de Windows, tiene sentido usar WinRT porque tendrá las últimas y mejores integraciones con nuevas experiencias que vendrán con los nuevos factores de forma. WinRT solo está destinado a ser un conjunto específico de API universales que se iluminan en su aplicación .NET en Windows.

Dicho esto, creo que todos estamos de acuerdo en que las aplicaciones universales serían más valiosas si UWP Desktop Extension Pack tuviera mejores capacidades de integración con el Shell de Windows existente.

Quién sabe, es posible que Microsoft tenga planes para reemplazar eventualmente el Windows Explorer Shell con el nuevo Composable Shell (CShell) que se encuentra en Windows 10X, etc. Los expertos en Twitter también han descubierto un nuevo UDK (Kit de desarrollo desacoplado) que se encuentra en Windows que podría permitir mejor integración con este nuevo shell en el futuro.

@AndrewPawlowski

Probablemente no quieras diferentes plataformas, ya que la de 900 millones es bastante grande.

Si bien entiendo lo que quiere decir, debe darse cuenta de que UWP y .NET ya no son cosas que se excluyen mutuamente, por lo que si tuviera sentido lanzar su aplicación con características universales, uno debería invertir en comprender partes de WinRT.

Estoy divagando. Como alguien que creó un competidor del Explorador de archivos de Windows con un modelo de aplicación puramente UWP, WinUI 3 no puede llegar lo suficientemente rápido. En un futuro cercano, no tendrá que elegir entre usar las funciones universales y los "900 millones de usuarios" 😀

@jtorjo Aconsejaría cambiar el título por uno que se perciba menos negativamente, para que más personas aporten sus comentarios aquí.
Quizás "Oportunidades para agregar valor a WinRT"

@verelpode

@jtorjo : ¿ha considerado cancelar la migración de su aplicación de WPF a UWP? Puede cancelarlo y esperar hasta que se publique WinUI 3, y luego no se verá obligado a usar la API problemática del sistema de archivos UWP, broadFileSystemAccess, etc. Mientras tanto, mientras espera WinUI 3, puede continuar entregue nuevas versiones de su aplicación a sus usuarios al continuar desarrollando la versión WPF de su aplicación.

Pensé mucho en esto, esto es lo que quería hacer. Pero no puedo dejar de hacerlo, porque realmente necesito win2d (o más concretamente, una buena envoltura sobre Direct2D). ShapDX (otro contenedor sobre Direct2D) parecía mucho más complicado, así que elegí usar win2d (que es UWP). Por lo tanto, transfiera todo a UWP.

Supongo que para eso primero debes dejar que el usuario elija una carpeta en la que quiera usar tu aplicación. Después de todo, el usuario sabe mejor dónde guardó sus videos.

¿Realmente apuesta su vida por eso? Yo no lo haría, claramente, si eres un usuario avanzado, puedes estar increíblemente organizado y saber dónde está cada detalle. De lo contrario....

Y luego, cada vez que usted (el usuario), de alguna manera copie fotos / videos en una nueva carpeta, deberá recordar decirle a mi aplicación que también lo incluya ...

Por no decir que la "gran" FutureAccessList - realmente no especifica -> si agrego una carpeta, ¿todas sus subcarpetas serán accesibles para mi aplicación?

Además, si agregué algo a FutureAccessList, ¿necesito recuperarlo desde allí o puedo obtenerlo con GetFolderFromPathAsync / GetFileFromPathAsync (es lo primero, prefiero saltar por un acantilado)?

¿Y sabía que si usa FutureAccessList.AddOrReplace y usa la ruta del archivo como token, obtiene una excepción? Qué reflexivo ... (no está en ninguna parte de la descripción)

WinUI 3 y .NET Core serán una opción en el futuro; supongo que esa combinación, sin la zona de pruebas de UWP, funcionará de la misma manera que WPF, pero con los controles XAML más nuevos, la capa visual y el acceso simple a la API de WinRT.

Supongo que para eso primero debes dejar que el usuario elija una carpeta en la que quiera usar tu aplicación. Después de todo, el usuario sabe mejor dónde guardó sus videos.

¿Realmente apuesta su vida por eso? Yo no lo haría, claramente, si eres un usuario avanzado, puedes estar increíblemente organizado y saber dónde está cada detalle. De lo contrario....

Bueno, si el Usuario no sabe dónde guardó sus videos, ¿qué debería hacer su aplicación? Analizar todos los archivos del sistema, que incluso con el software más rápido puede llevar horas. Al menos para mí esto no parece una buena experiencia. Después de todo, si su aplicación está dirigida a usuarios que quieren hacer algo con videos, los usuarios ya están algo "organizados" en el sentido de que saben que tienen videos en alguna parte. Pero nuevamente, solo mis pensamientos sin conocer realmente su aplicación y su caso comercial específico.

Y luego, cada vez que usted (el usuario), de alguna manera copie fotos / videos en una nueva carpeta, deberá recordar decirle a mi aplicación que también lo incluya ...

Creo que si tiene acceso al directorio principal, también puede acceder a las carpetas secundarias futuras (aunque no estoy 100% seguro).

¿Y sabía que si usa FutureAccessList.AddOrReplace y usa la ruta del archivo como token, obtiene una excepción? Qué reflexivo ... (no está en ninguna parte de la descripción)

Eso es extraño, ¡esto es algo que definitivamente debería documentarse!

Personalmente, no soy un fanático de las aplicaciones que solicitan "broadFileSystemAccess", ya que muchas de ellas no lo necesitan. Tal vez haya algunos casos en los que tenga sentido (escribir un explorador de archivos, etc.) pero muchos casos que necesitan acceso a ALGUNAS carpetas no deberían seguir adelante y decir "por favor, permítame acceder a todos los archivos", ya que también puede solicitar esas carpetas en particular.

Pero tal vez no conozca suficientes casos comerciales para eso. ¡Si hay más, me encantaría escucharlos!

Pero tal vez no conozca suficientes casos comerciales para eso. ¡Si hay más, me encantaría escucharlos!

• herramientas y software de utilidades, como una herramienta de (des) compresión. Si desea extraer el archivo comprimido en el mismo directorio donde se encuentra el archivo actual y cuando el menú contextual del explorador de Windows llamó a la aplicación, solo tiene acceso de escritura al archivo seleccionado. Por lo tanto, no podrá crear un nuevo archivo o directorio (para los archivos sin comprimir).

  • Si el usuario arrastró el archivo a su aplicación uwp, ¡no tiene acceso de escritura a esos archivos!
    https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

como una herramienta de (des) compresión. Si desea extraer el archivo comprimido en el mismo directorio donde se encuentra el archivo actual y cuando el menú contextual del explorador de Windows llamó a la aplicación, solo tiene acceso de escritura al archivo seleccionado. Por lo tanto, no podrá crear un nuevo archivo o directorio (para los archivos sin comprimir).

Creo que es muy discutible si debería tener acceso a toda la carpeta cuando hace clic derecho en un solo archivo o no. Aunque tbh, generalmente especifico una carpeta diferente al comprimir / descomprimir, ya que generalmente las necesito solo para "intercambio", es decir, copias de seguridad o descargas / cargas. Entonces, para mí, es casi necesario especificar dónde exactamente guardar los archivos. Pero este puede ser un caso de uso válido según la elección del usuario 😅

Si el usuario arrastró el archivo a su aplicación uwp, ¡no tiene acceso de escritura a esos archivos!
https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

Bueno, eso parece un poco complicado para usuarios y desarrolladores. Hubiera esperado que obtuviera al menos acceso de escritura a los archivos eliminados. En mi opinión, esto es solo una restricción innecesaria para los desarrolladores.

Aunque al menos en mi uso diario de aplicaciones, solo dejo archivos en los comentarios de GitHub. Para todos los demás casos, simplemente hago doble clic o clic derecho, pero acepté que en algunos casos eso no es genial. Supongo que, después de todo, hay algunos casos en los que tendría sentido tener acceso a todos los archivos.

Bueno, si el Usuario no sabe dónde guardó sus videos, ¿qué debería hacer su aplicación? Analizar todos los archivos del sistema, que incluso con el software más rápido puede llevar horas. ...

Claramente, hay muchas posibilidades, una de ellas es, cuando el usuario expande una carpeta, para obtener una vista previa de ella, para que pueda ver fácilmente qué carpetas tienen fotos / videos y cuáles no. Una cosa que mi aplicación realmente haría, si Windows me permitiera

Personalmente, no soy un fanático de las aplicaciones que solicitan "broadFileSystemAccess", ya que muchas de ellas no lo necesitan.

No importa. El modelo de protección del sistema de archivos de la caja de arena de WinRT está más allá de la realidad. Es algo que alguien tomó del gran mantra "Mobile first", que simplemente no se aplica al escritorio.

De hecho, una forma mucho más inteligente de almacenar archivos / carpetas en la zona de pruebas es dejar que el usuario decida qué archivos / carpetas quiere proteger; debería haber una forma muy fácil de hacerlo (como, tal vez en el Explorador de archivos, con un comando de clic derecho) .

Esto contrasta con bloquear todo de forma predeterminada, y luego los usuarios sin darse cuenta le dan acceso a archivos confidenciales por error.

Permítanme ser franco aquí: cualquier aplicación no trivial no vive en el vacío.

Claramente, hay muchas posibilidades, una de ellas es, cuando el usuario expande una carpeta, para obtener una vista previa de ella, para que pueda ver fácilmente qué carpetas tienen fotos / videos y cuáles no. Una cosa que mi aplicación realmente haría, si Windows me permitiera

Sí, esa es una posibilidad. Pero, ¿cuándo vas a escanear la carpeta? ¿Y qué carpetas exactamente puede expandir el usuario en su aplicación?

No importa.

¿Qué estás tratando de decir exactamente aquí?

De hecho, una forma mucho más inteligente de almacenar archivos / carpetas en la zona de pruebas es dejar que el usuario decida qué archivos / carpetas quiere proteger; debería haber una forma muy fácil de hacerlo (como, tal vez en el Explorador de archivos, con un comando de clic derecho) . Los usuarios sabrán claramente qué documentos / archivos son confidenciales y los protegerán.

Creo que toda esta protección de acceso no se trata solo de archivos "confidenciales", sino de privacidad en general, por ejemplo, archivos de configuración (que suelen estar ocultos en carpetas que los usuarios no ven) o simplemente qué programas están instalados. Ésta es información a la que no quiero que todos los programas puedan acceder, especialmente las "aplicaciones triviales", como las llamó.

Y también hay una analogía con el mundo real: solo piense en seifs.

Sí, puedes guardar cosas en cajas fuertes. Pero esto no cambia el hecho de que tenga la llave de su piso o de su casa. Pero decir que todos los programas pueden acceder a todo excepto en una caja fuerte es como decir que no necesitas una puerta para tu piso porque tienes una caja fuerte para tus objetos de valor.

Esto contrasta con bloquear todo de forma predeterminada, y luego los usuarios sin darse cuenta le dan acceso a archivos confidenciales por error.

Estos errores pueden ocurrir en ambos casos, pero creo que es más probable que se olvide de bloquear un archivo confidencial que de dar acceso accidentalmente a un archivo confidencial.

Permítanme ser franco aquí: cualquier aplicación no trivial no vive en el vacío. Necesitará obtener datos de algún lugar (entrada) y enviarlos a algún lugar. La entrada y la salida son a menudo archivos; necesita interoperar con otras aplicaciones y así sucesivamente. Y WinRT simplemente me hace imposible diseñar una interfaz de usuario agradable para dársela a mis usuarios.

Decir que es imposible es exagerado aquí, ya que hay muchas aplicaciones geniales para UWP (aunque no muchas, desafortunadamente).

Sí, esa es una posibilidad. Pero, ¿cuándo vas a escanear la carpeta? ¿Y qué carpetas exactamente puede expandir el usuario en su aplicación?

¿Está familiarizado con el concepto de Explorador de Windows? Expandes una carpeta o unidad; ahí es cuando comenzaría a escanear

Creo que toda esta protección de acceso no se trata solo de archivos "confidenciales", sino de privacidad en general, por ejemplo, archivos de configuración (que suelen estar ocultos en carpetas que los usuarios no ven) o simplemente qué programas están instalados. Ésta es información a la que no quiero que todos los programas puedan acceder, especialmente las "aplicaciones triviales", como las llamó.

Esto no es un problema, si la aplicación mantendría sus archivos en su propia carpeta "solo esta aplicación puede acceder".

Esto contrasta con bloquear todo de forma predeterminada, y luego los usuarios sin darse cuenta le dan acceso a archivos confidenciales por error.

Estos errores pueden ocurrir en ambos casos, pero creo que es más probable que se olvide de bloquear un archivo confidencial que de dar acceso accidentalmente a un archivo confidencial.

Estoy completamente en desacuerdo - todo el punto de "confidencial" debería hacer que quieras bloquear ese archivo.

Decir que es imposible es exagerado aquí, ya que hay muchas aplicaciones geniales para UWP (aunque no muchas, desafortunadamente).

Te estás contradiciendo aquí. Pero profundicemos en la inmensidad de las excelentes aplicaciones para UWP:

Observe la "abundancia" de Me gusta, que debería indicarle cuántas personas lo están usando. Quería dar un contraste a la tienda de manzana, pero no puedo porque no tengo una manzana. Pero veamos Android: Facebook tiene más de 70 millones de reseñas (en comparación con 1353 en Windows). Instagram tiene más de 93 millones de reseñas (en comparación con 1578 aquí). Y estoy casi seguro de que tanto Facebook como Instagram son en realidad aplicaciones electrónicas, no UWP.

¿Está familiarizado con el concepto de Explorador de Windows? Expandes una carpeta o unidad; ahí es cuando comenzaría a escanear

Entonces, ¿está creando algo similar al Explorador de Windows que previsualizará archivos de video en carpetas?

Esto no es un problema, si la aplicación mantendría sus archivos en su propia carpeta "solo esta aplicación puede acceder".

Entonces, por un lado, las aplicaciones generalmente deberían tener acceso a todos los archivos, pero por otro lado, el usuario bloqueará algunos archivos y carpetas (ya que solo tendrá archivos "confidenciales" y todo lo demás es automáticamente no confidencial) y algunas carpetas son bloqueado por aplicaciones de los mismos? ¿Y si quiero programar una aplicación que se ocupe de archivos generados por programas? ¿Todos los programas de respaldo fallarían ya que no podrían respaldar programas? No estoy muy seguro de cómo funcionaría, y lamento no haber entendido mal su idea aquí.

Estoy completamente en desacuerdo - todo el punto de "confidencial" debería hacer que quieras bloquear ese archivo.

Entonces, ¿qué no elegiría exactamente como confidencial? No quiero que todas las aplicaciones vean las fotos de mis vacaciones, pero Photoshop debería poder verlas. Entonces, ¿son confidenciales o no? ¿O esta "marca" confidencial es una lista de programas y algunos archivos no son confidenciales para algunas aplicaciones?

Te estás contradiciendo aquí.

Sí, mi fraseo era basura allí. Lo siento por eso. Quería indicar que definitivamente existen excelentes aplicaciones no "triviales" que simplemente funcionan bien.

Observe la "abundancia" de Me gusta, que debería indicarle cuántas personas lo están usando. Quería dar un contraste a la tienda de manzana, pero no puedo porque no tengo una manzana. Pero veamos Android: Facebook tiene más de 70 millones de reseñas (en comparación con 1353 en Windows). Instagram tiene más de 93 millones de reseñas (en comparación con 1578 aquí). Y estoy casi seguro de que tanto Facebook como Instagram son en realidad aplicaciones electrónicas, no UWP.

Esto no es un problema con UWP sino más bien con el hecho de que:

1. La gente no suele escribir comentarios.
2. La tienda de iTunes / Google Play Store es mucho más antigua que la tienda de Microsoft.
3. La Microsoft Store no fue bien recibida entre los usuarios y no comenzó bien
4. La mayoría de las empresas prefieren desarrollar sitios web en lugar de aplicaciones de plataforma limitada.

Y estoy casi seguro de que tanto Facebook como Instagram son en realidad aplicaciones electrónicas, no UWP.

Es difícil saber si son electrónicas o no, ya que el sitio web y la aplicación se ven muy diferentes. Basado en el hecho de que los cuadros de diálogo se ven casi exactamente como los predeterminados, pueden ser aplicaciones para UWP.

Entonces, ¿está creando algo similar al Explorador de Windows que previsualizará archivos de video en carpetas?

Eso es parte de un asistente de mi aplicación.

Entonces, por un lado, las aplicaciones generalmente deberían tener acceso a todos los archivos, pero por otro lado, el usuario bloqueará algunos archivos y carpetas (ya que solo tendrá archivos "confidenciales" y todo lo demás es automáticamente no confidencial) y algunas carpetas son bloqueado por aplicaciones de los mismos? ¿Y si quiero programar una aplicación que se ocupe de archivos generados por programas?

Mi idea fue la opuesta a la que tenemos ahora. No digo que sea perfecto, ni mucho menos, pero cualquier cosa es mejor que lo que está sucediendo ahora. Entonces, de manera predeterminada, tendría acceso a todos los archivos no confidenciales. Si necesita acceder a archivos confidenciales, primero debe preguntar.

Entonces, ¿qué no elegiría exactamente como confidencial? No quiero que todas las aplicaciones vean las fotos de mis vacaciones, pero Photoshop debería poder verlas. Entonces, ¿son confidenciales o no? ¿O esta "marca" confidencial es una lista de programas y algunos archivos no son confidenciales para algunas aplicaciones?

A mi modo de ver, esta "bandera" convertiría un archivo o carpeta en "Acceso denegado". Si realmente quisiera acceder a él, podría pedir permiso y el usuario podría optar por dárselo o no (y el permiso podría ser, solo esta vez, o para siempre).

Sí, mi fraseo era basura allí. Lo siento por eso. Quería indicar que definitivamente existen excelentes aplicaciones no "triviales" que simplemente funcionan bien.

No digo que no los haya. Estoy diciendo que es increíblemente difícil hacer uno, en comparación con WPF.
Estoy diciendo que estoy perdiendo días lidiando con problemas que simplemente no deberían existir.

Como, por ejemplo, a veces, obtengo una excepción (una excepción COM, para ser específico), y en lugar de obtenerla en el punto de falla, en realidad la obtengo en otro hilo, y la mayoría de las veces, incluso el seguimiento de la pila es perdió. Descubrir lo que sucedió es muy, muy doloroso.

Otro problema es el mantra "vamos a obtener información asincrónica", que detesto mucho. Estoy tratando con una representación que debe ser inmediata, pero la carga de mapas de bits es asincrónica. Así que tuve que construir un mecanismo de almacenamiento en caché realmente complicado solo para eso.

Y no entremos en tiempos de compilación. Y últimamente, a veces, al compilar, obtengo un "... dll está integrado en modo de lanzamiento" (que básicamente no puede ser, porque estoy construyendo depuración). La solución es simplemente limpiar toda la solución y reconstruir (lo que lleva más de 1 minuto).

Y sí, choques. VS se bloquea cada 10-20 carreras, me supera por qué.

Y estos son los problemas que me vinieron a la cabeza hace un momento. Hay muchísimos más.

Esto no es un problema con UWP sino más bien con el hecho de que:

1. La gente no suele escribir comentarios.
2. La tienda de iTunes / Google Play Store es mucho más antigua que la tienda de Microsoft.
3. La Microsoft Store no fue bien recibida entre los usuarios y no comenzó bien
4. La mayoría de las empresas prefieren desarrollar sitios web en lugar de aplicaciones de plataforma limitada.

Bueno, desearía haber tenido una comparación de la tienda de Apple; estoy bastante seguro de que sus aplicaciones principales tienen millones de reseñas. La idea es que la tienda MS nunca tuvo éxito, porque la gente simplemente se da por vencida con UWP / WinRT. Si no hubiera necesitado win2d, me habría rendido al menos 20 veces.

Solo piense en eso: necesito pedirle a Windows que pase a pantalla completa, como una aplicación para UWP. Eso es más que una locura. Y para hacerlo aún más estúpido, eso solo se aplicará en la próxima ejecución .

Estaba mirando la API "Tomar una captura de pantalla de la pantalla"; simplemente me rendí, es inútil. Básicamente, quería tener una forma genial de iniciar la aplicación, basada en la pantalla actual (más o menos, tener una transición a mi aplicación) -> no es posible, porque requiere la interacción del usuario (es decir, el usuario tiene que decir - sí , Quiero permitir tomar una captura de pantalla, lo que arruina todo)

No comenzaré con el portapapeles, que solo funciona cuando su aplicación está en primer plano. Y para hacerlo aún más divertido, Microsoft pensó "le daremos acceso al portapapeles en todo momento, cuando esté en depuración", pero en el lanzamiento, obtendrá una agradable excepción de "Acceso denegado". ¿Sabes cuántas horas me tomó finalmente darme cuenta de por qué mi aplicación no se iniciaba en la versión (mientras que todo era excelente en la depuración)?

La lista continúa, creo que podría escribir un libro. Claro, UWP / WinRT son geniales en teoría. Pero cuando empieces a usarlo, bueno ...

Es difícil saber si son electrónicas o no, ya que el sitio web y la aplicación se ven muy diferentes. Basado en el hecho de que los cuadros de diálogo se ven casi exactamente como los predeterminados, pueden ser aplicaciones para UWP.

Bien, mi punto es que la gente renuncia a las aplicaciones para UWP, los beneficios se ven superados por los muchos problemas que conlleva.

@jtorjo
(Solo para asegurarse de que lo sepa).

No comenzaré con el portapapeles, que solo funciona cuando su aplicación está en primer plano.

Llegué a ese mismo problema (o similar) durante el desarrollo de una de mis aplicaciones para UWP donde tuve que colocar datos en el portapapeles y al final lo resolví a través de un proceso de plena confianza win32 adjunto (que solo llama a SetClipboardData de Win32). Si el concepto de tener un proceso de plena confianza win32 adjunto para su aplicación para UWP es una novedad para usted, estará bien con una buena introducción aquí (el autor trabajó anteriormente en UWP en Microsoft).

@ Felix-Dev

Llegué a ese mismo problema (o similar) durante el desarrollo de una de mis aplicaciones para UWP donde tuve que colocar datos en el portapapeles y al final lo resolví a través de un proceso de plena confianza win32 adjunto (que solo llama a SetClipboardData de Win32). Si el concepto de tener un proceso de plena confianza win32 adjunto para su aplicación para UWP es una novedad para usted, estará bien con una buena introducción aquí (el autor trabajó anteriormente en UWP en Microsoft).

¡Gracias por la anotación! Sabía sobre el proceso de plena confianza de win32. Probablemente he leído esos artículos varias veces :) De hecho, he pensado varias veces en tener una aplicación complementaria de proceso de plena confianza win32. Decidí no hacerlo, debido a la complejidad adicional: ya estoy luchando por generar kits de configuración que realmente funcionen sin la tienda MS. Simplemente no quería incluir esto en la ecuación también.

Entonces, ¿está creando algo similar al Explorador de Windows que previsualizará archivos de video en carpetas?

Eso es parte de un asistente de mi aplicación.

Eso suena como un explorador de archivos con pasos adicionales (⊙ˍ⊙)

Mi idea fue la opuesta a la que tenemos ahora. No digo que sea perfecto, ni mucho menos, pero cualquier cosa es mejor que lo que está sucediendo ahora. Entonces, de manera predeterminada, tendría acceso a todos los archivos no confidenciales. Si necesita acceder a archivos confidenciales, primero debe preguntar.

Entonces, básicamente, al final, su aplicación probablemente se encontrará con el mismo problema que ahora porque nunca sabrá si los archivos son confidenciales. ¿Qué pasa con los usuarios que marcarán todo como confidencial? Así que acaba de crear el mismo sistema que ahora, solo que con más variaciones a las que puede acceder.

Como, por ejemplo, a veces, obtengo una excepción (una excepción COM, para ser específico), y en lugar de obtenerla en el punto de falla, en realidad la obtengo en otro hilo, y la mayoría de las veces, incluso el seguimiento de la pila es perdió. Descubrir lo que sucedió es muy, muy doloroso.

Si eso le sucede a menudo, es muy molesto. Para mí, sin embargo, casi todas las excepciones que me ocurrieron (por ejemplo, en el XCG) tenían un StackTrace asociado y, a veces, incluso mensajes de excepción útiles. Así que realmente no puedo decir nada sobre eso porque nunca fue un problema para mí.

Otro problema es el mantra "vamos a obtener información asincrónica", que detesto mucho. Estoy tratando con una representación que debe ser inmediata, pero la carga de mapas de bits es asincrónica. Así que tuve que construir un mecanismo de almacenamiento en caché realmente complicado solo para eso.

A veces, async es un poco molesto, sin embargo, en la mayoría de los casos, los métodos async tienen una razón para ser async, ya que no desea bloquear la interfaz de usuario en operaciones como operaciones de red o archivos. Dicho esto, puede utilizar los siguientes métodos para ejecutar su método asincrónico de forma sincrónica:

`` c #
// Bloqueará el hilo hasta que MyAsyncMethod haya terminado
var myResult = MyAsyncMethod (). Resultado;

// Esto también terminará cuando el método haya terminado de ejecutarse.
// Tenga en cuenta que ConfigureAwait puede provocar que el método se llame en un contexto diferente
var myResult2 = MyAsyncMethod (). ConfigureAwait (falso);
`` For ConfigureAwait` puede echar un vistazo al siguiente artículo: https://devblogs.microsoft.com/dotnet/configureawait-faq/

Y no entremos en tiempos de compilación. Y últimamente, a veces, al compilar, obtengo un "... dll está integrado en modo de lanzamiento" (que básicamente no puede ser, porque estoy construyendo depuración). La solución es simplemente limpiar toda la solución y reconstruir (lo que lleva más de 1 minuto).

El "... dll" está integrado en el modo de lanzamiento es extraño. ¿Quizás comprobar si los archivos del proyecto son incoherentes? Con respecto al tiempo de compilación, sí, eso es un poco molesto, aunque ~ 1 minuto todavía está bien, WinUI tarda entre 5 y 10 minutos 😅

Y sí, choques. VS se bloquea cada 10-20 carreras, me supera por qué.

Sí, eso es bastante molesto, aunque no creo que esto dependa realmente de UWP, sino solo de Visual Studio en general (¡sigue siendo un proceso de 32 bits por una razón!).

Bueno, desearía haber tenido una comparación de la tienda de Apple; estoy bastante seguro de que sus aplicaciones principales tienen millones de reseñas. La idea es que la tienda MS nunca tuvo éxito, porque la gente simplemente se da por vencida con UWP / WinRT. Si no hubiera necesitado win2d, me habría rendido al menos 20 veces.

Parece que puede usar Win2D con WPF: https://github.com/Microsoft/Win2D/issues/660

Solo piense en eso: necesito pedirle a Windows que pase a pantalla completa, como una aplicación para UWP. Eso es más que una locura. Y para hacerlo aún más estúpido, eso solo se aplicará en la próxima ejecución.

Parece posible poner su aplicación para UWP en modo de pantalla completa, incluso al inicio: https://stackoverflow.com/questions/31758775/windows-10-universal-app-run-in-fullscreen-mode-by-default
(Aunque no he intentado enviar una aplicación con eso)

Estaba mirando la API "Tomar una captura de pantalla de la pantalla"; simplemente me rendí, es inútil. Básicamente, quería tener una forma genial de iniciar la aplicación, basada en la pantalla actual (más o menos, tener una transición a mi aplicación) -> no es posible, porque requiere la interacción del usuario (es decir, el usuario tiene que decir - sí , Quiero permitir tomar una captura de pantalla, lo que arruina todo)

La mayoría de los usuarios no quieren que las aplicaciones tomen fotografías de su pantalla de forma arbitraria sin su permiso. Puede que no tengas ningún problema con eso, pero yo ciertamente lo tengo y muchos otros.

No comenzaré con el portapapeles, que solo funciona cuando su aplicación está en primer plano. Y para hacerlo aún más divertido, Microsoft pensó "le daremos acceso al portapapeles en todo momento, cuando esté en depuración", pero en el lanzamiento, obtendrá una agradable excepción de "Acceso denegado". ¿Sabes cuántas horas me tomó finalmente darme cuenta de por qué mi aplicación no se iniciaba en la versión (mientras que todo era excelente en la depuración)?

Sí, obtiene una excepción, sin embargo, el hecho de que su aplicación no puede acceder a ella cuando no está enfocada se menciona en la documentación:

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

Pero, ¿por qué necesita acceder al portapapeles cuando el usuario no está usando su aplicación? Si intenta configurar el portapapeles cuando el usuario no está usando su aplicación, el usuario se irritará cuando interfiera con su copia / pegado. Y si lees el portapapeles cuando el usuario no le pide a tu aplicación que lo haga, lo estás espiando. A menos que ese sea su objetivo (en cuyo caso definitivamente no debería usar UWP), hay muy pocas razones para leer el portapapeles mientras su aplicación no está enfocada (si es que hay alguna).

Bien, mi punto es que la gente renuncia a las aplicaciones para UWP, los beneficios se ven superados por los muchos problemas que conlleva.

Quizás, pero también por el hecho de que es más fácil escribir un sitio web y empaquetarlo dentro de Electron y enviarlo a Mac, Linux y Windows en lugar de escribir aplicaciones separadas para todas las plataformas.

Eso suena como un explorador de archivos con pasos adicionales (⊙ˍ⊙)

No es. Lejos de ahi.

Entonces, básicamente, al final, su aplicación probablemente se encontrará con el mismo problema que ahora porque nunca sabrá si los archivos son confidenciales. ¿Qué pasa con los usuarios que marcarán todo como confidencial? Así que acaba de crear el mismo sistema que ahora, solo que con más variaciones a las que puede acceder.

No digo que mi solución sea la correcta. Claramente, preferiría no estar en una caja de arena en absoluto, solo digo que la implementación actual es muy mala.

A veces, async es un poco molesto, sin embargo, en la mayoría de los casos, los métodos async tienen una razón para ser async, ya que no desea bloquear la interfaz de usuario en operaciones como operaciones de red o archivos. Dicho esto, puede utilizar los siguientes métodos para ejecutar su método asincrónico de forma sincrónica:

Esto está mal. Esto simplemente asume que siempre llamaré desde el hilo de la interfaz de usuario. Quiero decir, seguro que esto está bien para cosas simples, pero puedo crear mis propios hilos y también puedo crear mis propias Tareas y hacer cosas allí.

Tener todo async solo me obliga a llamar siempre a await y marcar funciones async.

[...] Por ConfigureAwait puedes echar un vistazo al siguiente artículo: https://devblogs.microsoft.com/dotnet/configureawait-faq/

Gracias, lo sé. Otro problema que encontré fue cargar un mapa de bits (asíncrono) exactamente como sugirió. De vez en cuando, me encontraba con tiempos de espera locos, como 5-6 segundos para cargar un mapa de bits.
Terminé haciendo soluciones.

El "... dll" está integrado en el modo de lanzamiento es extraño. ¿Quizás comprobar si los archivos del proyecto son incoherentes? Con respecto al tiempo de compilación, sí, eso es un poco molesto, aunque ~ 1 minuto todavía está bien, WinUI tarda entre 5 y 10 minutos 😅

Sí, ni siquiera quiero pensar en eso :) No estoy seguro de a qué te refieres con que los archivos del proyecto son incoherentes.

Y sí, choques. VS se bloquea cada 10-20 carreras, me supera por qué.

Sí, eso es bastante molesto, aunque no creo que esto dependa realmente de UWP, sino solo de Visual Studio en general (¡sigue siendo un proceso de 32 bits por una razón!).

Creo que está relacionado con UWP. Esto nunca me sucedió cuando trataba con WPF: tenía 28 proyectos y nunca se bloqueó. En UWP tengo 15 proyectos (que porté desde WPF) y se bloquea. Y si miro en el Visor de eventos, hay algo sobre el bloqueo de la caja de arena, no lo recuerdo exactamente.

Parece que puede usar Win2D con WPF: microsoft / Win2D # 660

Ese fue mi primer intento. Es un completo no-go. Me encontré con tantos problemas que terminé rindiéndome. El código que se ocupa de win2d es bastante complejo, por lo que razoné que me tomaría mucho más tiempo escribirlo sobre WPF que usar UWP directamente.

Por mucho que deteste la configuración de UWP tal como está, estaba en lo cierto. Nunca hubiera podido hacerlo funcionar correctamente. Y supongo que conoce https://github.com/microsoft/Win2D/issues/731

Solo piense en eso: necesito pedirle a Windows que pase a pantalla completa, como una aplicación para UWP. Eso es más que una locura. Y para hacerlo aún más estúpido, eso solo se aplicará en la próxima ejecución.

Parece posible poner su aplicación para UWP en modo de pantalla completa, incluso al inicio: https://stackoverflow.com/questions/31758775/windows-10-universal-app-run-in-fullscreen-mode-by-default

Lo siento, quise decir "ir maximizado", lo siento.

Sí, obtiene una excepción, sin embargo, el hecho de que su aplicación no puede acceder a ella cuando no está enfocada se menciona en la documentación:

El problema es que tenemos un comportamiento diferente en Debug que en Release. Debe ser coherente.

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

Pero, ¿por qué necesita acceder al portapapeles cuando el usuario no está usando su aplicación? [...]

Lo curioso es esto: quería copiar algo en el portapapeles al inicio. Sin embargo, esto estaba en el constructor de MainPage, así que aparentemente, todavía no estaba en primer plano. Funcionó perfectamente en Debug, falló en Release, y con eso, me refiero exactamente al inicio, sin registrar nada.

Bien, mi punto es que la gente renuncia a las aplicaciones para UWP, los beneficios se ven superados por los muchos problemas que conlleva.

Quizás, pero también por el hecho de que es más fácil escribir un sitio web y empaquetarlo dentro de Electron y enviarlo a Mac, Linux y Windows en lugar de escribir aplicaciones separadas para todas las plataformas.

Cuando se trata de la independencia de la plataforma, ese es un tema completamente nuevo: a lo que me refería es al hecho de que muchos de los problemas que enfrentan las personas al desarrollar aplicaciones para UWP simplemente no deberían existir. Cambiar de WPF a UWP ha sido una experiencia muy mala.

@chingucoding

Pero, ¿por qué necesita acceder al portapapeles cuando el usuario no está usando su aplicación? Si intenta configurar el portapapeles cuando el usuario no está usando su aplicación, el usuario se irritará cuando interfiera con su copia / pegado. Y si lees el portapapeles cuando el usuario no le pide a tu aplicación que lo haga, lo estás espiando. A menos que ese sea su objetivo (en cuyo caso definitivamente no debería usar UWP), hay muy pocas razones para leer el portapapeles mientras su aplicación no está enfocada (si es que hay alguna).

En mi caso, mi aplicación de vez en cuando muestra una notificación cuando ocurre un evento que la aplicación está buscando. La notificación del brindis puede contener información que el usuario desea procesar más / usar en otro contexto, así que proporciono un botón de acción [copiar al portapapeles] que copia parte de la información mostrada. Dado que una notificación puede llegar en cualquier momento y la aplicación podría estar en segundo plano en ese momento, tengo que usar un proceso auxiliar de Win32 en ese caso.

El uso de Win32 fuera de la zona de pruebas de UWP no siempre se debe a que el desarrollador quiere lograr algo sin que el usuario lo sepa. Entonces, si bien en términos generales, la caja de arena nos brinda valor a los usuarios, aún debe lidiar con ella como un desarrollador en cualquier caso, incluso si no es un desarrollador malintencionado al que no le importa espiar al usuario o no tiene intención de pedir el consentimiento del usuario antes de cambiar algo en su sistema.

El hecho de que pueda usar un proceso de plena confianza de Win32 junto con su aplicación indica que MS es consciente de este dilema y nos brinda a los desarrolladores las herramientas para usar UWP y aún así poder disfrutar de la libertad de Win32 en buena medida.

No es. Lejos de ahi.

¿Se puede descargar la aplicación ahora? Si es así, ¿dónde puedo encontrarlo? 😅

Claramente, preferiría no estar en una caja de arena en absoluto, solo digo que la implementación actual es muy mala.

Supongo que, si no le gusta la zona de pruebas, tal vez cambiar a una alternativa de WPF podría ser la mejor opción, en lugar de simplemente intentar desarrollar sus aplicaciones en UWP, lo que dejó en claro, cree que es "imposible" o "increíblemente difícil" de desarrollar aplicaciones para. No creo que las alternativas de WPF sean tan malas en comparación con Win2D, eso justificaría que pases por todas tus luchas. Pero ese es solo mi punto de vista al respecto.

Además, la implementación actual es "mala" para las personas que están acostumbradas a no tener limitaciones con respecto a los archivos. Viniendo de una experiencia en desarrollo web, estoy muy bien con eso. Puedo ver su lugar, sobre todo porque la Web también tiene limitaciones cuyo propósito es proteger a los usuarios.

No estoy seguro de a qué te refieres con que los archivos del proyecto son incoherentes.

Tal vez los archivos del proyecto para la depuración sean incorrectos y se esté generando algún dll en la versión, aunque dudo que eso suceda si solo deja que Visual Studio se encargue de eso.

Creo que está relacionado con UWP. Esto nunca me sucedió cuando trataba con WPF: tenía 28 proyectos y nunca se bloqueó. En UWP tengo 15 proyectos (que porté desde WPF) y se bloquea. Y si miro en el Visor de eventos, hay algo sobre el bloqueo de la caja de arena, no lo recuerdo exactamente.

La confiabilidad de Visual Studio depende en gran medida del tamaño del proyecto para mí. UWP / NetCore / NetFramework pequeño / mediano siempre funciona bien. Los proyectos grandes hacen que Visual Studio no responda, se cuelgue o simplemente se cuelgue en el momento. Pero esa es solo mi experiencia.

Lo siento, quise decir "ir maximizado", lo siento.

En ese caso, sí, el cambio solo se aplicará en el próximo inicio, ya que usted establece el valor DESPUÉS de que se inicie la aplicación. No sé a qué te refieres con "tengo que preguntarle a Windows". ¿Te refieres al hecho de que tienes que configurarlo en código?

También hay una manera de establecer el tamaño preferido, que debería resultar en que la aplicación ocupe todo el espacio en la pantalla en la que se encuentra (similar a maximizada), aunque no es tan bueno como real maximizado:
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

Esto está mal. Esto simplemente asume que siempre llamaré desde el hilo de la interfaz de usuario. Quiero decir, seguro que esto está bien para cosas simples, pero puedo crear mis propios hilos y también puedo crear mis propias Tareas y hacer cosas allí.

Si ya está utilizando sus propios hilos, el uso de await no debería ser un problema para usted. Incluso si usa subprocesos separados, el controlador de eventos siempre se ejecuta en el subproceso de la interfaz de usuario, por lo que si realiza un cálculo extenso allí, la aplicación no responde.

Por mucho que deteste la configuración de UWP tal como está, estaba en lo cierto. Nunca hubiera podido hacerlo funcionar correctamente. Y supongo que conoce microsoft / Win2D # 731

No era consciente de eso, pensé que siendo el problema que mencioné de 2018, ya estaría bien resuelto.

El problema es que tenemos un comportamiento diferente en Debug que en Release. Debe ser coherente.

Hmm, eso es muy extraño. El comportamiento debe ser coherente.

Lo curioso es esto: quería copiar algo en el portapapeles al inicio.

También mencionan ese caso de uso en la documentación, y debe esperar a que CoreWindow.Activated se copie. Sin embargo, ¿por qué exactamente copiarías algo en el portapapeles cuando el usuario acaba de iniciar tu aplicación? ¿Algo similar a lo que @ Felix-Dev quiere lograr / lograr?

@ Felix-Dev Gracias por responder. No pensé en ese escenario. En ese caso, sí, necesitas acceder al portapapeles y esto definitivamente mejora la experiencia de los usuarios. Mi conjetura habría sido que dado que el brindis "tiene enfoque", esto habría funcionado. Pero supongo que no es el caso.

Entonces, si bien en términos generales, la caja de arena nos brinda valor a los usuarios, aún debe lidiar con ella como un desarrollador en cualquier caso, incluso si no es un desarrollador malintencionado al que no le importa espiar al usuario o no tiene intención de pedir el consentimiento del usuario antes de cambiar algo en su sistema.

Sí, tenemos que lidiar con eso, sin embargo, muchas aplicaciones no están limitadas por la caja de arena de tal manera que sería muy difícil encontrar una solución. Y una cosa que no debe olvidar es que si UWP no le funciona, todavía hay otras 2 opciones.

Con respecto a su último punto, sí, el hecho de que pueda usar procesos Win32 es una indicación de que hay casos en los que UWP lo está limitando.
Tal vez esta fue la solución más fácil / rápida disponible, o tal vez en realidad lo sea por diseño.

No es. Lejos de ahi.

¿Se puede descargar la aplicación ahora? Si es así, ¿dónde puedo encontrarlo? 😅

Aquí -> https://phot-awe.com

Supongo que, si no le gusta la zona de pruebas, tal vez cambiar a una alternativa de WPF podría ser la mejor opción, en lugar de simplemente intentar desarrollar sus aplicaciones en UWP, lo que dejó en claro, cree que es "imposible" o "increíblemente difícil" de desarrollar aplicaciones para. No creo que las alternativas de WPF sean tan malas en comparación con Win2D, eso justificaría que pases por todas tus luchas. Pero ese es solo mi punto de vista al respecto.

Esta fue una aplicación WPF. Sin embargo, debido a la naturaleza de la edición de video, llegué a los límites de WPF en términos de velocidad (básicamente, lidiar con DrawingVisual ). Créame, no habría hecho esto si hubiera tenido la opción.

Además, la implementación actual es "mala" para las personas que están acostumbradas a no tener limitaciones con respecto a los archivos. Viniendo de una experiencia en desarrollo web, estoy muy bien con eso. Puedo ver su lugar, sobre todo porque la Web también tiene limitaciones cuyo propósito es proteger a los usuarios.

Podría haber jurado que venías de un entorno web :)

Tal vez los archivos del proyecto para la depuración sean incorrectos y se esté generando algún dll en la versión, aunque dudo que eso suceda si solo deja que Visual Studio se encargue de eso.

Ese no es el caso, pero lo verifiqué dos veces, no es el caso.

La confiabilidad de Visual Studio depende en gran medida del tamaño del proyecto para mí. UWP / NetCore / NetFramework pequeño / mediano siempre funciona bien. Los proyectos grandes hacen que Visual Studio no responda, se cuelgue o simplemente se cuelgue en el momento. Pero esa es solo mi experiencia.

Sí, me he ocupado de eso en el pasado. No parece ser el caso de las últimas versiones de VS (2017,2019). De todos modos, en pocas palabras, esto acaba de pasar en UWP para mí. Puede que tenga que ver con el hecho de que estoy usando win2d, y tengo la sensación de que es una bestia bastante complicada.

En ese caso, sí, el cambio solo se aplicará en el próximo inicio, ya que usted establece el valor DESPUÉS de que se inicie la aplicación. No sé a qué te refieres con "tengo que preguntarle a Windows". ¿Te refieres al hecho de que tienes que configurarlo en código?

En WPF, simplemente configuro el tamaño de la ventana donde quiero que esté. Aquí, hay una API que necesita llamar -> ApplicationView.PreferredLaunchViewSize - que, como dicen los documentos, "funciona, excepto en los casos en que el sistema administra el tamaño de la ventana directamente". - y sí, solo funciona para el próximo inicio de la aplicación.

También hay una manera de establecer el tamaño preferido, que debería resultar en que la aplicación ocupe todo el espacio en la pantalla en la que se encuentra (similar a maximizada), aunque no es tan bueno como real maximizado:
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

Estoy usando otro código, que en realidad funciona correctamente.

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

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

Si ya está utilizando sus propios hilos, el uso de await no debería ser un problema para usted. Incluso si usa subprocesos separados, el controlador de eventos siempre se ejecuta en el subproceso de la interfaz de usuario, por lo que si realiza un cálculo extenso allí, la aplicación no responde.

Claramente, los controladores de eventos se ejecutan en el hilo de la interfaz de usuario. Me he acostumbrado un poco, tuve que modificar bastante mi aplicación, simplemente agregando async a las funciones ... Lo que todavía me molesta de verdad es que, para mí, parece que bastantes API han tomado esto al extremo, solo tener versiones de Async (), donde no tiene sentido.

No era consciente de eso, pensé que siendo el problema que mencioné de 2018, ya estaría bien resuelto.

No lo ha hecho, al menos la última vez que lo comprobé.

El problema es que tenemos un comportamiento diferente en Debug que en Release. Debe ser coherente.

Hmm, eso es muy extraño. El comportamiento debe ser coherente.

Sí, eso es lo que realmente me cabreó. Y claramente, al trabajar con el portapapeles durante un tiempo increíblemente largo en aplicaciones que no son de UWP, no pensé que tuviéramos estas limitaciones, así que sí, no leí sobre tener que esperar a CoreWindow. Habiendo dicho eso, es increíblemente engorroso tener que aprender todos estos detalles. Es como si tuviera que aprender un idioma completamente nuevo. En lugar de ser un proceso perfecto, parece que cada semana aprendo algo que me deja boquiabierto.

También mencionan ese caso de uso en la documentación, y debe esperar a que CoreWindow.Activated se copie. Sin embargo, ¿por qué exactamente copiarías algo en el portapapeles cuando el usuario acaba de iniciar tu aplicación? ¿Algo similar a lo que @ Felix-Dev quiere lograr / lograr?

Esto fue cuando estaba probando mi aplicación por primera vez, y solo quería dársela a un colega para que realizara más pruebas internas. Sin embargo, necesitaría modificar algunas configuraciones. Y la configuración se mantuvo en LocalFolder de la aplicación. Esto es diferente para cada usuario, así que mi opinión fue: déjame mantener esto simple y copiarlo en el portapapeles. Luego, cuando inicie la aplicación, irá a "Esta PC", pegará la ubicación y editará un archivo de configuración allí (ahora, sé cómo podría simplemente haber abierto la aplicación en el Explorador, pero en ese momento, No). Que terminó colapsando, y yo investigando y maldiciendo durante unas buenas horas.

Aquí -> https://phot-awe.com

¡Gracias!

Esta fue una aplicación WPF. Sin embargo, debido a la naturaleza de la edición de video, llegué a los límites de WPF en términos de velocidad (básicamente, al tratar con DrawingVisual). Créame, no habría hecho esto si hubiera tenido la opción.

No sabía que WPF tenía una desventaja de rendimiento tan grande en comparación con UWP.

Ese no es el caso, pero lo verifiqué dos veces, no es el caso.

Eso es raro. Hubiera esperado que hubiera algo mal. ¿Por qué VS hablaría de la versión dll cuando está ejecutando debug.

En WPF, simplemente configuro el tamaño de la ventana donde quiero que esté. Aquí, hay una API que debe llamar, ApplicationView.PreferredLaunchViewSize, que, como dicen los documentos, "funciona, excepto en los casos en que el sistema administra el tamaño de la ventana directamente".

Pero, ¿el código que está utilizando no es también una API para establecer el tamaño de la ventana?

• y sí, solo funciona para el próximo inicio de la aplicación.

No es sorprendente cuando se llama "PreferredLaunchViewSize" 😅
Un pequeño inconveniente es que no hay forma de configurar esto después del lanzamiento.

Sí, me he ocupado de eso en el pasado. No parece ser el caso de las últimas versiones de VS (2017,2019). De todos modos, en pocas palabras, esto acaba de pasar en UWP para mí.

Me alegra saber que no es tan malo como lo fue con las versiones anteriores de VS.

Puede que tenga que ver con el hecho de que estoy usando win2d, y tengo la sensación de que es una bestia bastante complicada.

No confío mucho en el diseñador, ya que comienza a fallar para los enlaces de plantillas. ¿Has probado Blend para Visual Studio? ¿Es eso más confiable con respecto al diseñador?

Sí, eso es lo que realmente me cabreó. Y claramente, al trabajar con el portapapeles durante un tiempo increíblemente largo en aplicaciones que no son de UWP, no pensé que tuviéramos estas limitaciones, así que sí, no leí sobre tener que esperar a CoreWindow. Habiendo dicho eso, es increíblemente engorroso tener que aprender todos estos detalles. Es como si tuviera que aprender un idioma completamente nuevo. En lugar de ser un proceso perfecto, parece que cada semana aprendo algo que me deja boquiabierto.

Sí, me lo puedo imaginar. Algo que podría ser bueno es una guía de transición de WPF a UWP. Si esto existiera, definitivamente ahorraría mucho tiempo a los nuevos desarrolladores de UWP y antiguos desarrolladores de WPF. Y esta no sería la primera vez que existe una guía de transición. Ya existe una guía de Java a C #, que ayuda mucho a los desarrolladores de Java.

Esto fue cuando estaba probando mi aplicación por primera vez, y solo quería dársela a un colega para que realizara más pruebas internas. Sin embargo, necesitaría modificar algunas configuraciones. Y la configuración se mantuvo en LocalFolder de la aplicación. Esto es diferente para cada usuario, así que mi opinión fue: déjame mantener esto simple y copiarlo en el portapapeles. Luego, cuando inicie la aplicación, irá a "Esta PC", pegará la ubicación y editará un archivo de configuración allí (ahora, sé cómo podría simplemente haber abierto la aplicación en el Explorador, pero en ese momento, No). Que terminó colapsando, y yo investigando y maldiciendo durante unas buenas horas.

Oh ya veo. Si uno no piensa en abrir la carpeta, copiar la ruta de la carpeta al portapapeles es una solución. Para propósitos de prueba, esto es bastante inteligente.

No sabía que WPF tenía una desventaja de rendimiento tan grande en comparación con UWP.

WPF no estaba optimizado para DirectX: cuando entran en juego los sombreadores de píxeles y las máscaras, termina siendo muy lento. La migración a UWP / win2d hizo que la aplicación fuera 3-4 veces más rápida. Eso es increíblemente notable.

Eso es raro. Hubiera esperado que hubiera algo mal. ¿Por qué VS hablaría de la versión dll cuando está ejecutando debug.

Sí, mi punto exactamente.

Pero, ¿el código que está utilizando no es también una API para establecer el tamaño de la ventana?

Lo que quiero decir es que usas Preferred ... Size, pero no tienes garantía de que suceda. Al igual que cuando usa WPF, tiene la garantía de que cuando establece la posición / tamaño, realmente sucederá.

No es sorprendente cuando se llama "PreferredLaunchViewSize" 😅
Un pequeño inconveniente es que no hay forma de configurar esto después del lanzamiento.

Esto es más que un inconveniente, es increíblemente inconveniente. Básicamente, no puedo cambiar el tamaño de mi aplicación una vez que se inició. Y sí, me gustaría que mi aplicación tuviera diferentes "modos" de operación (como, Básico / Avanzado). Basándome en eso, me gustaría ocupar más o menos espacio, no puedo hacerlo. ¿Crees que el usuario estará de acuerdo con "Los cambios se realizarán solo después de reiniciar"?

No confío mucho en el diseñador, ya que comienza a fallar para los enlaces de plantillas. ¿Has probado Blend para Visual Studio? ¿Es eso más confiable con respecto al diseñador?

Debería haber sido más específico: el VS no se bloquea al editar xaml, se bloquea al iniciar la aplicación; básicamente, supongo que sucede exactamente en la implementación, ya que solo ves la "x" grande en la aplicación (uwp) durante unos 10 segundos, y en ese momento sé que se cuelga. En ese momento, puedo esperar otros 45-60 segundos y ver que VS se bloqueará, o simplemente cerrar VS desde el Administrador de tareas.

Sí, me lo puedo imaginar. Algo que podría ser bueno es una guía de transición de WPF a UWP.

Sí, eso sería muy útil.

Oh ya veo. Si uno no piensa en abrir la carpeta, copiar la ruta de la carpeta al portapapeles es una solución. Para propósitos de prueba, esto es bastante inteligente.

Gracias;) Bueno, hubiera sido inteligente, si realmente hubiera funcionado :)

@chingucoding

A veces, async es un poco molesto, sin embargo, en la mayoría de los casos, los métodos async tienen una razón para ser async, ya que no desea bloquear la interfaz de usuario en operaciones como operaciones de red o archivos. Dicho esto, puede utilizar los siguientes métodos para ejecutar su método asincrónico de forma sincrónica

Déjame darte una razón más por la que odio la async: esto me acaba de pasar ahora (básicamente, es un informe de error de un usuario). Inicialmente, no pude resolverlo por mi vida.

En pocas palabras: al hacer clic en un botón, abro un selector de archivos. Lo cual, lo adivinaste, es asincrónico.

Entonces, el usuario hizo doble clic en él (con una pausa de aproximadamente 100 ms entre los clics). Seguramente, esto abrió 2 selectores de archivos.

Ahora, claramente puedo arreglar esto, pero esto nunca sucedería, si la función inicial fuera sincrónica (y por supuesto, esto nunca sucederá en WPF).

Esto es más que un inconveniente, es increíblemente inconveniente. Básicamente, no puedo cambiar el tamaño de mi aplicación una vez que se inició. Y sí, me gustaría que mi aplicación tuviera diferentes "modos" de operación (como, Básico / Avanzado). Basándome en eso, me gustaría ocupar más o menos espacio, no puedo hacerlo. ¿Crees que el usuario estará de acuerdo con "Los cambios se realizarán solo después de reiniciar"?

Bueno, "increíblemente inconveniente" puede ser para aplicaciones que necesitan hacer cumplir ciertos tamaños, pero en la mayoría de los casos las aplicaciones no necesitan cambiar su tamaño. ¿Cómo debe elegir una aplicación qué tamaño es actualmente apropiado para el caso de uso de los usuarios? Si el usuario tiene la necesidad de hacerlo más pequeño o más grande, entonces el usuario es el primero en notarlo. Sobre todo porque él sabe mejor dónde están otras ventanas abiertas y dónde habría espacio disponible para no bloquear otras ventanas para que no sean visibles.

Si tiene un modo básico y avanzado, puede cambiar el tamaño mínimo preferido si la aplicación definitivamente no funciona cuando es demasiado pequeña. Pero en mi opinión, sería muy irritante para mí si los programas comenzaran a cambiar de tamaño (y afortunadamente ningún programa lo hace hasta ahora).

No puedo hacerlo. ¿Crees que el usuario estará de acuerdo con "Los cambios se realizarán solo después de reiniciar"?

Si cambiar el tamaño es tan importante, un usuario puede hacerlo por sí mismo. Sin embargo, estos "cambios solo ocurrirán después de reiniciar" no es infrecuente, por lo que es parcialmente aceptable en mi opinión.

Entonces, el usuario hizo doble clic en él (con una pausa de aproximadamente 100 ms entre los clics). Seguramente, esto abrió 2 selectores de archivos.

¿Por qué exactamente abrió el selector de archivos dos veces? ¿Se activó el controlador de eventos dos veces? Entonces, esto no es un problema causado por async, sino por el hecho de que el controlador de eventos no bloqueó la interfaz de usuario para que no recibiera eventos adicionales desde el botón respectivo.

En pocas palabras: al hacer clic en un botón, abro un selector de archivos. Lo cual, lo adivinaste, es asincrónico.

Sí, es asincrónico porque no desea bloquear todo su hilo mientras el usuario navega por su disco y selecciona la carpeta. La llamada finaliza cuando el usuario ha terminado de seleccionar un archivo / carpeta y, como resultado, obtiene el archivo elegido.

En mi opinión, es mejor no bloquear el hilo en tales operaciones, ya que nunca se sabe cuánto tiempo tomarán realmente. Si bloquea el hilo de la interfaz de usuario debido a eso, su aplicación no responde siempre que haya un selector de archivos abierto, lo que en mi opinión no es una buena experiencia de usuario.

Permítanme comenzar diciendo respetuosamente esto: nunca nos pondremos de acuerdo en nada .

Claramente, está pensando desde una perspectiva web y simplemente no ve nada como "escritorio". Sé que tienes buenas intenciones, pero no estás pensando en "escritorio" hasta que hayas desarrollado algo complicado, cuando se trata de escritorio. Y creo que no lo has hecho.

Bueno, "increíblemente inconveniente" puede ser para aplicaciones que necesitan hacer cumplir ciertos tamaños, pero en la mayoría de los casos las aplicaciones no necesitan cambiar su tamaño. ¿Cómo debe elegir una aplicación qué tamaño es actualmente apropiado para el caso de uso de los usuarios? Si el usuario tiene la necesidad de hacerlo más pequeño o más grande, el usuario

¿Estás preguntando esto en serio? ¿No se supone que una aplicación ayuda al usuario? Y luego, si el usuario no está de acuerdo con el tamaño de la aplicación, puede cambiar el tamaño. Pero la aplicación debería poder decir, en función de lo que se supone que debe lograr, este es el tamaño en el que debería estar ejecutándose. Digamos, Photoshop - siempre preferirá ejecutarse en pantalla completa, porque tiene mucha información para mostrar al usuario.

Si tiene un modo básico y avanzado, puede cambiar el tamaño mínimo preferido si la aplicación definitivamente no funciona cuando es demasiado pequeña. Pero en mi opinión, sería muy irritante para mí si los programas comenzaran a cambiar de tamaño (y afortunadamente ningún programa lo hace hasta ahora).

Si lo hicieron, ni siquiera lo pensaste. Los asistentes a veces se ejecutan en tamaños más pequeños, y luego, cuando el asistente finaliza, la aplicación puede pasar a pantalla completa.

No puedo hacerlo. ¿Crees que el usuario estará de acuerdo con "Los cambios se realizarán solo después de reiniciar"?

Si cambiar el tamaño es tan importante, un usuario puede hacerlo por sí mismo. Sin embargo, estos "cambios solo ocurrirán después de reiniciar" no es infrecuente, por lo que es parcialmente aceptable en mi opinión.

Y tengo una mala experiencia de inicio, porque muestro una ventana que se ve bien solo de cierto tamaño, y Windows solo dice "Oh, pero mostraré la aplicación como quiero".

¿Por qué exactamente abrió el selector de archivos dos veces? ¿Se activó el controlador de eventos dos veces? Entonces, esto no es un problema causado por async, sino por el hecho de que el controlador de eventos no bloqueó la interfaz de usuario para que no recibiera eventos adicionales desde el botón respectivo.

¿Estás haciendo esto honestamente? Muéstrame cómo se recortó un código donde lo hiciste conscientemente.

En mi opinión, es mejor no bloquear el hilo en tales operaciones, ya que nunca se sabe cuánto tiempo tomarán realmente. Si bloquea el hilo de la interfaz de usuario debido a eso, su aplicación no responde siempre que haya un selector de archivos abierto, lo que en mi opinión no es una buena experiencia de usuario.

¿Cómo maneja WPF esto? Lo maneja correctamente. La interfaz de usuario no se bloquea, pero la aplicación se bloquea en esa llamada, por lo que lo anterior nunca sucedería en WPF

Permítanme comenzar diciendo respetuosamente esto: nunca nos pondremos de acuerdo en nada.

Si esta es su opinión sobre esta discusión, lo lamento.

Claramente, está pensando desde una perspectiva web y simplemente no ve nada como "escritorio". Sé que tienes buenas intenciones, pero no estás pensando en "escritorio" hasta que hayas desarrollado algo complicado, cuando se trata de escritorio. Y creo que no lo has hecho.

Creo que una descripción más precisa sería: vengo de un entorno en el que los desarrolladores no tienen acceso a nada y tú vienes de un entorno en el que los desarrolladores tienen acceso a todos los recursos del sistema operativo.

Si lo hicieron, ni siquiera lo pensaste. Los asistentes a veces se ejecutan en tamaños más pequeños, y luego, cuando el asistente finaliza, la aplicación puede pasar a pantalla completa.

Sí, los asistentes se ejecutan en tamaños más pequeños, PERO la mayoría de los asistentes (incluido el "Asistente" de inicio de Visual Studio 2019) se cierran y luego inician el programa real. No se "transforman" en la aplicación real.

Vale la pena señalar que algunos asistentes tampoco son ventanas nuevas, sino solo ventanas emergentes, con la aplicación real en segundo plano.

Y tengo una mala experiencia de inicio, porque muestro una ventana que se ve bien solo de cierto tamaño, y Windows solo dice "Oh, pero mostraré la aplicación como quiero".

Haces que parezca que Windows simplemente ignora tu código todo el tiempo, mientras que está claro cuándo lo ignorará (tomado de la documentación de "PreferredLaunchViewSize"):

Esta propiedad solo tiene efecto cuando la aplicación se inicia en un dispositivo de escritorio que no está en modo Tableta.

Por lo tanto, solo funciona en el escritorio en modo no tableta. Pero, ¿tiene sentido en otros dispositivos solicitar tamaños? ¿Espera que su aplicación se ejecute en X-Box o Holo Lens, y la ha optimizado para dichos dispositivos? Si no es así, esta limitación no debería molestarle tanto.

¿Estás haciendo esto honestamente? Muéstrame cómo se recortó un código donde lo hiciste conscientemente.

No, no lo soy, solo estaba tratando de señalar el hecho de que usted culpa a "async" por algo que no está relacionado con eso. Si los usuarios hacen clic en un botón dos veces, el evento en el que se hace clic se activa dos veces.

¿Cómo maneja WPF esto? Lo maneja correctamente. La interfaz de usuario no se bloquea, pero la aplicación se bloquea en esa llamada, por lo que lo anterior nunca sucedería en WPF

Estoy bastante seguro de que si ejecuta código en el subproceso de la interfaz de usuario y lleva tiempo completarlo, está bloqueando el subproceso de la interfaz de usuario en WPF.

Hola, soy el líder de desarrollo para el SDK de Windows y la infraestructura de tiempo de ejecución de Windows en el equipo del sistema operativo Windows.

Esta es una gran discusión con muchos detalles y conversación. Alguien trajo esta conversación hace unos días, y estoy ansioso por leerla, pero es posible que pasen algunos días antes de que llegue a ella. Sin embargo, lo leeré todo e intentaré darte algunas respuestas más detalladas o dar seguimiento lo mejor que pueda.

Probablemente este no sea el mejor lugar para los problemas generales de Winrt. Puede plantear problemas en los foros de desarrolladores de Microsoft, o para problemas de Windows Runtime específicamente, puede abrir un problema en https://github.com/microsoft/xlang. Nuestro equipo revisa los problemas entrantes allí de forma regular. Los problemas archivados en github llegarán a mi equipo más rápido, pero tendrán menos seguimiento. Si sus comentarios requieren cambios en el sistema operativo, mantener el sistema operativo sincronizado con un problema de github archivado es un proceso manual. Por otro lado, la retroalimentación del foro sigue el trabajo entre los equipos y la organización, y es menos probable que se desconecte del trabajo real realizado en base a la retroalimentación.

Gracias de nuevo por la animada discusión. Publicaré de nuevo sobre este problema pronto.

Ben Kuhn
Microsoft

Hola Ben,

Hola, soy el líder de desarrollo para el SDK de Windows y la infraestructura de tiempo de ejecución de Windows en el equipo del sistema operativo Windows.

Esta es una gran discusión con muchos detalles y conversación. Alguien trajo esta conversación hace unos días, y estoy ansioso por leerla, pero es posible que pasen algunos días antes de que llegue a ella. Sin embargo, lo leeré todo e intentaré darte algunas respuestas más detalladas o dar seguimiento lo mejor que pueda.

Impresionante: ¡esperamos su (s) respuesta (s)!

Como soy el póster original, si tiene alguna pregunta o algo no está claro, hágamelo saber y haré todo lo posible para aclararlo.

Probablemente este no sea el mejor lugar para los problemas generales de Winrt. Puede plantear problemas en los foros de desarrolladores de Microsoft, o para problemas de Windows Runtime específicamente, puede abrir un problema en https://github.com/microsoft/xlang.

Estoy de acuerdo en que no es el mejor lugar, el problema es que la gente no sabe dónde publicar.

Si dices que deberíamos publicar en https://github.com/microsoft/xlang , definitivamente publicaré allí a partir de ahora.

Mejor,
John

Primero, permítanme mencionar algunas cosas que no voy a abordar.

• Hay una gran discusión acerca de las ventanas, la posición de las ventanas, etc. cerca del final del hilo. Probablemente todavía esté un poco fuera de tema para WinUI, pero más cercano a casa. Me gustaría dejar que la gente de WinUI analice los comentarios sobre la posición de la ventana, pantalla completa, etc. y ayude a redirigir. @StephenLPeters , ¿puedes ayudar con esto?

• No voy a tocar los comentarios de VS. Existe un foro saludable para discutir la calidad y el rendimiento de VS. Aunque he tomado nota de la discusión de que la historia para desarrollar aplicaciones de Windows desde Visual Studio se ha vuelto un poco más compleja y confusa.

• WPF. Tengo una relación de amor y odio con WPF. Es útil y, en general, bueno. Sin embargo, cuando leí el comentario sobre los clics anidados en el selector de archivos, me hizo reír. Porque hay algunas peculiaridades en WPF que me han dado verdaderos dolores de cabeza. Como el hecho de que cuando arrastra en WPF, los mensajes de arrastre se envían dos veces en un mensaje anidado, por lo que en realidad está haciendo un arrastre modal dentro de un arrastre modal. Por lo general, nunca se da cuenta. Generalmente. Pero todavía me gusta WPF. 😉

Segundo, @verelpode : Esto me hizo reír. ¿Te importa si me quedo con este?
"Creo que no puedes manejar la verdad directa, por lo tanto, te manejaré con guantes gruesos de algodón esponjoso y te envolveré en plástico de burbujas".

Bien, ahora vamos a temas reales.

WinRT frente a UWP frente a .NET: algunos antecedentes

El tiempo de ejecución de Windows es realmente dos cosas en una, empaquetadas en otra y realmente incomprendidas.

El sistema de tipos de Windows Runtime es realmente, en cierto sentido, COM V2. Es el siguiente paso espiritual en la progresión desde la activación de interrupciones hasta la llamada a Win32 y la llamada a las API COM. El sistema de tipos es de alguna manera un poco menos expresivo en COM, pero en la mayoría de los casos es un superconjunto sustancial. Fue diseñado originalmente para abordar exactamente un problema: ¿cómo hacemos que sea más fácil para los desarrolladores que usan .NET u otros lenguajes llamar a las API de WinRT sin tener que esperar a que VS haga buenos envoltorios en el marco .NET?

Luego está la biblioteca API. Hicimos grandes cosas aquí y algunas tonterías. Es posible que nos hayamos dejado llevar un poco con algunas de las cosas asincrónicas. Si programa con C ++ / WinRT, puede mitigar esto significativamente. Si no está en el hilo de la interfaz de usuario, simplemente tome el resultado y se bloqueará y completará sincrónicamente. .NET también puede hacer esto más fácil ahora, pero escribo menos código .NET en estos días, y estoy menos seguro sobre el estado actual de las cosas. También hicimos algunas otras cosas que no funcionaron según lo planeado. No los enumeraré todos. Sin embargo, hemos realizado algunas mejoras.

El modelo de aplicación de UWP saltó a winrt con ambos pies. Significaba que podíamos escribir API de SO una vez y facilitar el acceso a ellas desde aplicaciones basadas en JS, aplicaciones .NET y aplicaciones nativas. Eso en sí mismo era bondad. Eliminar todas las demás API de Win32 no fue tan bueno. Todavía tenemos trabajo de documentación por hacer, pero ahora hay muchas más API clásicas de Win32 que se pueden usar en las aplicaciones de la tienda. En pocas palabras, creamos una plataforma de aplicaciones completamente nueva con una pequeña base de usuarios en dispositivos nuevos, no le permitimos traer su código existente y no apareció mucha gente. Sabemos. Por eso lo estamos arreglando poco a poco. También hicimos muchas cosas bien, y estamos avanzando lenta pero constantemente hacia el mejor enfoque de ambos mundos. Un sistema de instalación declarativo es, en muchos sentidos, algo maravilloso.

En este hilo también se abordó la portabilidad del código entre aplicaciones para UWP y aplicaciones de escritorio. Debido a que el modelo de UWP divergió tanto, existen varios puntos débiles. Los abordamos tan rápido como sea práctico. Algunos toman tiempo o requieren "descansos importantes". Por ejemplo, usamos diferentes nombres para las DLL de CRT. Creamos una mitigación, el paquete de reenviadores de VC, pero la solución real será eventualmente eliminar la distinción en una versión futura del CRT, que inherentemente requiere cambiar el nombre de los archivos y un cambio importante. Hacemos esto intencionalmente con poca frecuencia porque es perturbador.

WinRT en sí mismo está moviendo cada vez más sus herramientas de código abierto y, aunque no es muy conocido, la mayor parte de WinRT está disponible para aplicaciones de escritorio. XAML fue la gran brecha. Las islas XAML fueron un paso en la dirección correcta, pero estoy mucho más entusiasmado con WinUI.

Comentarios sobre API específicas

Para algunos de estos, le pediré que envíe sus comentarios si este es su problema. Ayudaré a promover el problema al equipo adecuado. Los diferentes equipos de Windows son cada uno responsable de sus propias API, y será más eficaz si lo presenta en el centro de comentarios. Esto conecta la retroalimentación con una historia y un ser humano real. También le permite realizar un seguimiento de los comentarios. Pueden ayudarse mutuamente un poco al agregar comentarios que otros presenten según corresponda. Intente elegir una categoría adecuada. Si no está claro, puede utilizar "comentarios del desarrollador" -> Comentarios de la API

Las API del sistema de archivos para aplicaciones modernas son dolorosa e inesperadamente lentas

https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
Hemos escuchado estos comentarios, tanto de los clientes como de nuestros propios equipos que crean aplicaciones. Ojalá tuviera más para compartir en este momento. Por ahora, lo único que puedo decir, lamentablemente, es "lo sabemos".

La capacidad / API BroadSystemAccess no es práctica tal como se implementó.

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
Envíe un elemento del centro de comentarios y envíeme el enlace. Lo promocionaré personalmente y se lo entregaré al propietario adecuado. Una tasa de caída del 80% no es buena. Entiendo el punto de que también sea una señal de alerta para los usuarios. SI, las API de archivos fueran lo suficientemente rápidas, parece que la lista de acceso futura mitigaría al menos parte del dolor, pero podría no ser tan 'hábil' como la que tiene ahora. Pero entonces, estás entre la espada y la pared. Para ser mágico de la forma en que lo está haciendo ahora, necesita que el usuario le permita ver todo. Su hoja de cálculo de contraseñas, su carpeta de correo, la caché de su navegador, etc. Puede que seas confiable, pero tu aplicación debe hacer que los usuarios se detengan y piensen cuánto confían en ti antes de entregar su mundo.

Entiendo que la idea de cerrar la aplicación y reiniciar es un paso incómodo. Este parece ser el tipo de cosas que al menos deberían resolverse en el primer lanzamiento. Envíe un elemento de comentarios por separado. Misma oferta. Promocionaré y cumpliré.

Con respecto a si la lista de acceso futura puede acceder a las subcarpetas, seguí adelante y creé un problema de documentación para la página. https://github.com/MicrosoftDocs/windows-uwp/issues/2322. Vale la pena señalar que, dado que las páginas de documentos están en github, también puede presentar problemas en documentos o proponer cambios en el contenido.

Arrastrar el archivo a las aplicaciones no permite el acceso de escritura: la misma oferta sobre el centro de comentarios. Preséntelo y lo enrutaré en consecuencia.

Creación de aplicaciones para descargar fuera de la tienda de MS

La conclusión que obtuve aquí es que la mayoría de la cuestión es una cuestión de documentación, pero toca otro aspecto clave. Como algunas de nuestras herramientas se han trasladado a proyectos de github y código abierto, la documentación se ha trasladado con él, y eso hace que sea más difícil usar la documentación de Windows como una ventanilla única para todo. Plantearé este problema internamente tanto en relación con el problema específico en torno al archivo .appinstaller como en un debate más general con nuestro equipo de contenido sobre cómo abordarlo mejor.

También notó un problema específico sobre la necesidad de enrutar a través del servidor para depurar. Que debe presentar como un problema contra el proyecto github existente.

Nueva emisión de certificados y distribución privada

Esto está un poco más cerca de mí (mi equipo más grande también se encarga de los aspectos de la instalación de la aplicación. Aún apreciaría un problema del centro de comentarios sobre esto con el que pueda trabajar.

El sistema de tipo WinRT afecta la capacidad de ofrecer excelentes API y bibliotecas

La incapacidad de sobrecargar el nombre del tipo es por diseño. Hasta que reconsideremos cómo las aplicaciones javscript (¿qué tal Node / V8? ¿Sería interesante?) Acceden a las API de WinRT, no estaremos listos para revisar esto. El otro problema en torno a las propiedades y NaN se encuentra en un tema separado que tiene una buena discusión, por lo que no lo abordaré en esta respuesta.

Feedback Hub debería avisar al abandonar para evitar la eliminación accidental de contenido

Sí, haré +1 en eso. Preséntelo. Hay una categoría en el centro de comentarios debajo de aplicaciones para ... centro de comentarios. Eso es tan meta.

Las API asíncronas todavía están fuera de control y parecen incómodas para cosas que no deberían ser asíncronas

Sí. Este también sigue siendo un tema de debate interno. Existe un delicado equilibrio entre la niñera y el fomento del buen comportamiento que aún no hemos logrado. Continúe enviando comentarios sobre API específicas que le encantaría ver sincrónicas.

No hay buenas API de audio en WinRT

No soy un experto en audio. Siéntase libre de presentar su solicitud en el centro de comentarios, pero también voy a llamar a un salvavidas aquí y hacer algunas preguntas.

Dolores del portapapeles

Tengo que empezar con una Mae Culpa aquí. Nuestro modelo de acceso al portapapeles fue diseñado en la era Win8, cuando estábamos siendo superprotectores con el usuario. Codifiqué la mayor parte. Hay buenas razones para proteger el portapapeles. Los usuarios colocan todo tipo de datos confidenciales en el portapapeles, mientras que una aplicación que puede sobrescribir el portapapeles también podría hacer daño al intentar aprovechar las debilidades en otras aplicaciones que podrían tener más acceso. Las API del portapapeles de Win32 también permiten algunos comportamientos bastante poderosos que podrían abusarse. Por lo tanto, el portapapeles limita el acceso a menos que su aplicación esté en primer plano o adjunta a un depurador, y ajusta un poco lo que puede poner en el portapapeles (de formas que nunca debería notar a menos que realmente lo esté intentando).

Dicho esto, una notificación con la que se está interactuando parece que debería tener acceso al portapapeles. Esto requeriría un manejo especial debido a cómo se cuentan Windows y el primer plano, creo, pero no parece más allá de lo razonable. Por favor, presente los comentarios de la API y también promoveré ese problema en la base de datos de errores.

Terminando

Espero que sea de ayuda. Seguiré el hilo y haré un seguimiento de los problemas anteriores como se indica si los archiva.

Por respeto al equipo de WinUI, que ya tiene mucho en sus manos, deje que este hilo se relaje y concéntrese solo en los aspectos de WinUI y Windowing que se plantean en este hilo. Dado que este es tan largo y serpenteante, puede ser útil dividirlos en problemas separados y más pequeños. Dejaré esto abierto durante unos días para que todos ustedes presenten sus comentarios y dejen comentarios con enlaces, luego cerraré este hilo.

Si desea sumergirse más en las discusiones del sistema de tipo WinRT, el proyecto xlang es un buen lugar para comenzar. Para comportamientos específicos de la API de Windows, el centro de comentarios es una mejor opción. Ahora también tiene un sistema de comentarios, así que espero que eso ayude.

Gracias nuevamente por una excelente discusión y todos los comentarios detallados sobre tantos temas.

Ben Kuhn
Microsoft

Su aplicación no se cerraría si presentara selectores de archivos que le permitan al usuario elegir a qué quiere dar acceso a su aplicación.

No puedo enfatizar lo suficiente lo importante que es esto como usuario. No quiero que ninguna aplicación tenga acceso a todo, pero si pides una ubicación extraña _y tiene_ sentido, te concederé el acceso.

@BenJKuhn Gracias por la respuesta detallada. ¡Muy, muy apreciado!

• WPF. Tengo una relación de amor y odio con WPF. Es útil y, en general, bueno. Sin embargo, cuando leí el comentario sobre los clics anidados en el selector de archivos, me hizo reír. Porque hay algunas peculiaridades en WPF que me han dado verdaderos dolores de cabeza. Como el hecho de que cuando arrastra en WPF, los mensajes de arrastre se envían dos veces en un mensaje anidado, por lo que en realidad está haciendo un arrastre modal dentro de un arrastre modal. Por lo general, nunca se da cuenta. Generalmente. Pero todavía me gusta WPF. 😉

Estoy totalmente de acuerdo. No soy un defensor de WPF, llegué a los límites de WPF hace mucho tiempo. Esa es la razón por la que me mudé a UWP. En cuanto a la estabilidad, WPF parece mucho más estable.

WinRT frente a UWP frente a .NET: algunos antecedentes

Luego está la biblioteca API. Hicimos grandes cosas aquí y algunas tonterías. Es posible que nos hayamos dejado llevar un poco con algunas de las cosas asincrónicas.

Puedes decir eso de nuevo :)

La portabilidad del código entre las aplicaciones para UWP y las aplicaciones de escritorio también se abordó en [...] este hilo, pero la solución real será eliminar eventualmente la distinción en una versión futura del CRT, que inherentemente requiere cambiar el nombre de los archivos y un cambio importante importante .

¿Alguna ETA? .Net 5?

Las API del sistema de archivos para aplicaciones modernas son dolorosa e inesperadamente lentas

https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
Hemos escuchado estos comentarios, tanto de los clientes como de nuestros propios equipos que crean aplicaciones. Ojalá tuviera más para compartir en este momento. Por ahora, lo único que puedo decir, lamentablemente, es "lo sabemos".

Hasta ahora, tengo una solución alternativa, lejos de ser ideal, pero por ahora estoy bien: https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

La capacidad / API BroadSystemAccess no es práctica tal como se implementó.

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
Envíe un elemento del centro de comentarios y envíeme el enlace. Lo promocionaré personalmente y se lo entregaré al propietario adecuado. Una tasa de caída del 80% no es buena. entiendo

Lo haré, espero poder hacerlo durante el fin de semana.

el punto de que también es una señal de alerta para los usuarios. SI las API de archivos fueran lo suficientemente rápidas, parece que la lista de acceso futura mitigaría al menos algunos de los

Sí, si StorageFile / Folder API fuera tan rápido como System.IO (o al menos comparable), lo mitigaría. No es por falta de intentos, he hecho todo lo que se describe en los documentos.

dolor, pero puede que no sea tan "resbaladizo" como lo que tiene ahora. Pero entonces, estás entre la espada y la pared. Para ser mágico de la forma en que lo está haciendo ahora, necesita que el usuario le permita ver todo. Su hoja de cálculo de contraseñas, su carpeta de correo, la caché de su navegador, etc. Puede que seas confiable, pero tu aplicación debe hacer que los usuarios se detengan y piensen cuánto confían en ti antes de entregar su mundo.

Entiendo totalmente todo esto. Y estoy de acuerdo contigo. Mi punto de dolor es la implementación actual de todo esto. Ya he reescrito la mayor parte de la interfaz de usuario relacionada con esto (varias veces).

Dicho esto, aquí están mis ideas para mejorar:

• "Seleccionar carpeta" podría ser un poco más útil: podría especificar los archivos que me interesan y podría resaltar al usuario las carpetas que lo contienen
• Portapapeles: si el usuario coloca algunos archivos / carpetas en el portapapeles y luego vuelve a mi aplicación, debería tener acceso automáticamente a ellos (tal vez pueda agregar una capacidad de "ClipboardFilesAndFolders")
• arrastrar y soltar archivos / carpetas: eso debería darme acceso automáticamente a esos archivos (de lo contrario, ¿por qué el usuario los soltaría en mi aplicación?)

Entiendo que la idea de cerrar la aplicación y reiniciar es un paso incómodo. Este parece ser el tipo de cosas que al menos deberían resolverse en el primer lanzamiento. Envíe un elemento de comentarios por separado. Misma oferta. Promocionaré y cumpliré.

Entendido, gracias, durante el fin de semana.

Arrastrar el archivo a las aplicaciones no permite el acceso de escritura: la misma oferta sobre el centro de comentarios. Preséntelo y lo enrutaré en consecuencia.

Bien, servirá, lo de arrastrar archivos a las aplicaciones. Todavía no lo he probado:

1. ¿Funciona tanto con archivos como con carpetas?
2. ¿Tengo acceso a .Path?
3. ¿Es persistente (supongo que no)?
4. ¿Debo aferrarme al StorageFile / Folder, o volver a crearlo más tarde desde .Path funcionará (asumiendo que la respuesta a 2. es SÍ)?

Creación de aplicaciones para descargar fuera de la tienda de MS

La conclusión que obtuve aquí es que la mayoría de la cuestión es una cuestión de documentación, pero toca otro aspecto clave. Como algunas de nuestras herramientas se han trasladado a proyectos de github y código abierto, la documentación se ha trasladado con él, y eso hace que sea más difícil usar la documentación de Windows como una ventanilla única para todo. Plantearé este problema internamente tanto en relación con el problema específico en torno al archivo .appinstaller como en un debate más general con nuestro equipo de contenido sobre cómo abordarlo mejor.

¡Sí, eso sería increíble!

Personalmente, lo he descubierto para mi aplicación. Me impide hacer otras cosas avanzadas que me gustaría hacer (como tener una aplicación win32 para iniciar, ya que me temo que debería cambiar todo el archivo .appinstaller).

Pero, para mí, esto debería ser parte del proceso de "Publicación" de Visual Studio. Debería crear un .appinstaller para mí (ya que obtener todos esos nombres de dependencia correctos está lejos de ser trivial, y cualquier actualización de las dependencias -> aquí vamos de nuevo). También debería crear un archivo readme.txt, en el que debería explicar lo que necesito cargar en mi servidor, y también decirme que no puedo usar el .appinstaller localmente, debe descargarse del servidor (al probar )

También notó un problema específico sobre la necesidad de enrutar a través del servidor para depurar. Que debe presentar como un problema contra el proyecto github existente.

No recuerdo cuál fue ese problema :)

Feedback Hub debería avisar al abandonar para evitar la eliminación accidental de contenido

Sí, haré +1 en eso. Preséntelo. Hay una categoría en el centro de comentarios debajo de aplicaciones para ... centro de comentarios. Eso es tan meta.

Derecha :)

Las API asíncronas todavía están fuera de control y parecen incómodas para cosas que no deberían ser asíncronas

Sí. Este también sigue siendo un tema de debate interno. Existe un delicado equilibrio entre la niñera y el fomento del buen comportamiento que aún no hemos logrado. Continúe enviando comentarios sobre API específicas que le encantaría ver sincrónicas.

Jeje, esa es una larga lista;)

1. Comienza con propiedades básicas en StorageFolder / File; StorageFile.GetFileFromPathAsync (+ similar para Carpeta).
2. Cargando miniaturas (StorageFile.GetThumbnailAsync
3. Carga de mapas de bits. Esto es especialmente doloroso, ya que se trasladó a otras bibliotecas (como win2d), y he alcanzado umbrales insanos, como la carga de un mapa de bits simple (que debería tomar <20ms), para que dure 5 segundos más o menos. Claramente hay algo de bloqueo detrás de escena, pero nadie sabe qué / por qué / cuándo. Y sí, mi computadora portátil es un cohete.

No he realizado un seguimiento de muchas otras API, una búsqueda rápida en mi proyecto muestra 326 usos; lo he recortado mucho, ya que muchas cosas en mi extremo deben ser sincrónicas.

Los anteriores son mis principales dolores de cabeza, desde lo alto de mi cabeza. De ahora en adelante, crearé un documento y lo agregaré :)

No hay buenas API de audio en WinRT

No soy un experto en audio. Siéntase libre de presentar su solicitud en el centro de comentarios, pero también voy a llamar a un salvavidas aquí y hacer algunas preguntas.

No estoy seguro de cómo se resolverá esto alguna vez. Lo más fácil sería relajar los requisitos o algo así, para que naudio (https://github.com/naudio/NAudio) se pueda portar correctamente a UWP. Para ser claros, se puede compilar en UWP de inmediato, pero es inútil porque la mayoría de las cosas útiles para el usuario se # ifdef-ed out.

Para ser claros, no me quejo de la API de sonido en UWP, lo cual está totalmente bien, pero necesito más. Es decir, la capacidad de interpretar ondas sonoras y similares (lo que permite naudio).

Hice un puerto de naudio, donde prácticamente eliminé todos los #ifdefs; funciona, pero mi aplicación nunca llegará a la tienda de MS, y estoy de acuerdo con eso.

Dolores del portapapeles

[...] Dicho esto, parece que se debería permitir el acceso al portapapeles a una notificación con la que se está interactuando. Esto requeriría un manejo especial debido a cómo se cuentan Windows y el primer plano, creo, pero no parece más allá de lo razonable. Por favor, presente los comentarios de la API y también promoveré ese problema en la base de datos de errores.

Suena bien, servirá.

¡Gracias!

@jtorjo ¿Sería tan amable de incluir también el problema # 1893 (Propuesta: Acceso al sistema de archivos: proporcione una forma fácil de usar para solicitar permiso para acceder a ubicaciones de archivos específicas) en los elementos del Centro de comentarios sobre el sistema de archivos (en caso de que no No planee eso ya, creo que enumeró el problema subyacente arriba). Me temo que ya tengo un montón de otros elementos para archivar, así que si pudieras cubrir este cuando abordes el sistema de archivos, sería genial :)

Por supuesto, aún lo archivaría si agregarlo al Centro de comentarios no fuera conveniente para usted.

@ Felix-Dev ¡Haré todo lo posible! ¡Te mantendré informado!

Arrastrar el archivo a las aplicaciones no permite el acceso de escritura: la misma oferta sobre el centro de comentarios. Preséntelo y lo enrutaré en consecuencia.

Bien, servirá, lo de arrastrar archivos a las aplicaciones.

En realidad, se suponía que esta era la nota sobre la apertura desde un menú contextual de shell. Perdón por la confusion.

@BenJKuhn En vista de que este repositorio de Github es un lugar mucho mejor para tener discusiones sobre propuestas específicas de WinRT que el lugar de Feedback Hub (basado en el sentimiento de los desarrolladores expresado varias veces en este repositorio durante los últimos 12 meses): ¿Estaría bien simplemente publicar un resumen de propuesta rápida en Feedback Hub con un enlace a la propuesta mucho más detallada ubicada en este repositorio (por ahora, ya que no hay una plataforma de retroalimentación de modelo de aplicación UWP específica que tenga la confianza de la comunidad de desarrolladores que conozco)? He visto propuestas que se refinan aún más con otras aportaciones de la comunidad aquí para que el equipo específico de Microsoft tenga un enlace directo a la propuesta en desarrollo.

@ Felix-Dev Para propuestas específicas, honestamente creo que es mejor comenzar a enviarlas al Centro de comentarios con la etiqueta "Plataforma de desarrollador> Comentarios de API".

Mirando los comentarios recientes archivados bajo ese filtro, parece que no se han agregado muchos comentarios específicos. Solo vi 30 elementos (como máximo) archivados bajo ese filtro. Sin embargo, los ingenieros han respondido a los comentarios allí recientemente.

Hago un llamado a la comunidad para que presente sus comentarios sobre la API a través del Centro de comentarios, como se indica arriba, y comenzaremos a verlo florecer como una opción para enviar comentarios sobre la API una vez que las propuestas mejoren.

Creo que @BenJKuhn estará de acuerdo conmigo.

Acabo de notar que mi respuesta se ha vuelto bastante larga, así que tómate esto como una advertencia 😅

@ duke7553 Tenemos una situación aquí en la que la comunidad debería usar dos plataformas diferentes para sus comentarios sobre la plataforma de UWP. Las solicitudes de API específicas como (agregue el parámetro x al método y, o agregue un método para hacer z) deben archivarse en el Centro de comentarios al menos (aunque probablemente también deberían publicarse en un lugar adicional). Sin embargo, los problemas / propuestas más complejos que eso (hasta llegar al núcleo mismo de la UWP) de la plataforma definitivamente deberían publicarse en otro lugar que no sea el Centro de comentarios en su forma actual. Está bien publicar un breve resumen en el Centro de comentarios, pero para cualquier otra cosa, el Centro de comentarios simplemente no es la plataforma en este momento. Lea a continuación para obtener más detalles sobre el motivo.

En su estado actual, los muchos miembros activos de la comunidad de desarrollo simplemente no ven positivamente el Centro de comentarios en función de su sentimiento expresado en este mismo repositorio y en otros lugares como Twitter una y otra vez . Los problemas que se destacan aquí, por ejemplo, son:

• La (percibida) falta de compromiso por parte de los equipos de desarrollo de Windows (también miré los comentarios de API presentados recientemente y aparecen muchos problemas con 0 comentarios y ninguna respuesta oficial a partir de ahora, especialmente con respecto a los problemas de 2 meses y más viejo).
• La participación de la comunidad en cuestiones / propuestas específicas es bastante baja (votos a favor, comentarios).
• La interfaz de usuario / UX general del Centro de comentarios, lo que realmente hace que sea bastante difícil tener discusiones de comentarios interesantes con el equipo y la comunidad. Sobre esto, algunas personas del equipo de WinUI declararon que también están de acuerdo con la comunidad aquí .
• Finalmente, es mucho más fácil en Github en este momento agregar archivos multimedia de soporte como imágenes o GIF a una propuesta para ayudar a visualizarla. Dejaré esta imagen aquí tomada directamente del Centro de comentarios cuando presente un problema:
  

No usé Feedback Hub antes para presentar problemas específicos de la plataforma de desarrollo y mirarlo ahora mismo, viendo cómo los problemas son recibidos por la comunidad (¡participación comunitaria casi nula!), Los equipos de desarrollo de Windows y su estructura general, tengo que decir este único repositorio de WinUI es superior al Feedback Hub en básicamente todos los aspectos (facilidad de creación de propuestas / participación de la comunidad / disponibilidad de desarrolladores de MS / ...).

Ni siquiera está cerca, honestamente.

Especialmente cuando se trata de participación comunitaria. No puedo enfatizar lo suficiente lo excepcional que ha sido la contribución de la comunidad en este repositorio aquí y ha impulsado y mejorado enormemente tantos problemas / propuestas. Toda esa gran contribución de la comunidad desaparecería si se archivara solo en el Centro de comentarios actual.

Y sobre las respuestas del equipo de desarrollo a los problemas de mi modelo de aplicación para UWP creados aquí, solo diré esto: en muchos casos como este , recibí comentarios oportunos con la nota de que un elemento de trabajo se ha creado internamente. ¿Qué más puedo pedir? Compare esto con el sentimiento de muchos desarrolladores que sienten que sus problemas no irán a ninguna parte si se archivan en el Centro de comentarios. Y puedo ver de dónde vienen con solo mirar el Centro de comentarios en este momento.

@BenJKuhn
Los equipos de MS deben intensificar seriamente su plataforma de comentarios de UWP y hasta que vea esas mejoras, siempre usaré este repositorio aquí también siempre que lo permita el equipo de WinUI. Feedback Hub actualmente tiene una posición muy baja a los ojos de muchos desarrolladores de Windows y una publicación de la noche a la mañana no cambiará repentinamente esa situación. Es un comienzo, pero se necesita mucho más para revertir fundamentalmente las impresiones negativas que muchos desarrolladores obtendrán cuando hablen sobre Feedback Hub (u otras plataformas de comentarios de desarrolladores específicas de MS como UserVoice para UWP, que se cerró anteriormente). Dadas las muchas experiencias decepcionantes que obtuvieron muchos desarrolladores de UWP / Windows al tratar con Feedback Hub u otras plataformas de retroalimentación anteriores, yo, en este asunto, creo firmemente que los equipos de retroalimentación y desarrollo de Windows deben dar un paso al frente en lugar de suplicar a los desarrolladores que volver (sin muchas, si las hay, mejoras visibles para mostrar). Reconozco que esta es una opinión bastante dura, pero si realmente observa las muchas respuestas de los desarrolladores en este repositorio y muchas otras plataformas de comentarios a lo largo de los años, verá fácilmente que hay una frustración real en la comunidad de desarrollo.

Sin embargo, no quiero ser solo duro aquí, ya que ambas partes se necesitarán mutuamente para crear una plataforma de comentarios vibrante y fructífera que proporcione altos valores de satisfacción tanto para Microsoft como para la comunidad de desarrolladores. Como compromiso, he sugerido en mi publicación anterior publicar problemas de UWP aquí en este repositorio, donde se pueden discutir activamente con la comunidad y publicar un breve resumen con un enlace al hilo de github incluido en el Centro de comentarios. Además de todas las ventajas que esto tendría para la comunidad que mencioné anteriormente, el enlace agregado también le dará a los equipos de desarrollo de Windows una mirada a las diferentes vistas presentes en esta comunidad e incluso captará muchas ideas pequeñas que probablemente nunca se archivarán. en el Centro de comentarios, pero se puede encontrar en muchos de los comentarios aquí .

Terminaré esta publicación con una captura de pantalla tomada de la plataforma para desarrolladores de Feedback Hub -> sección API Feedback:

PD: Usaré esta publicación para agradecer sinceramente al equipo de WinUI nuevamente que acordaron abrir su repositorio para problemas de host que no están relacionados con WinUI en absoluto, sino que tienen como objetivo abordar los problemas fundamentales que los desarrolladores están viendo en la UWP . ¡Gracias, equipo de WinUI!

@BenJKuhn

Estos son los problemas del centro de comentarios que he creado

La capacidad / API BroadSystemAccess no es práctica tal como se implementó. https://aka.ms/AA804aq

BroadSystemAccess API / no debe reiniciar la aplicación cuando el usuario permite un acceso amplio al sistema https://aka.ms/AA7zpe3

El portapapeles debería funcionar en todo momento. https://aka.ms/AA804ce

Acceso al sistema de archivos: proporcione una forma sencilla de solicitar permiso para acceder a ubicaciones de archivos específicas https://aka.ms/AA804cp (para @ Felix-Dev)

No hay buenas API de audio en WinRT https://aka.ms/AA804d0

Las API asíncronas todavía están fuera de control y parecen incómodas para cosas que no deberían ser asíncronas https://aka.ms/AA804d3

Otras cosas que he creado

Más detalles: debería permitir más caracteres https://aka.ms/AA7zws5

Elija una categoría - facilite esto https://aka.ms/AA804cd

Cosas de las que no estoy seguro

Arrastrar y soltar archivos / carpetas : no lo he probado personalmente. Es decir, no tengo curiosidad por la parte de arrastrar y soltar, que no es muy difícil de implementar. Tengo curiosidad por saber si realmente funciona cuando el usuario suelta archivos / carpetas en un control de UWP. ¿Tengo acceso de solo lectura (que sería suficiente para mí)? ¿Puedo agregar estos archivos / carpetas a FutureAccessList?

Tengo curiosidad por saber si alguien ha probado / usado esto con éxito, ya que no hay tanta información en línea.

Centro de comentarios

El centro de comentarios no es una experiencia agradable. Por un lado, los problemas que agrego no aparecen en "Mis comentarios" por un tiempo; necesito cerrar y reiniciar la aplicación. No recuerda mi última selección. No puedo escribir demasiado texto, no hay forma de soltar un archivo y / o imágenes del portapapeles. Estoy totalmente de acuerdo con @ Felix-Dev: es realmente difícil entender dónde publicar los problemas (aparte de, de ahora en adelante, los publicaré en xlang).

@BenJKuhn Aquí está el enlace del Centro de comentarios para el problema específico de la notificación del brindis que tiene acceso al portapapeles cuando el usuario interactúa con él: https://aka.ms/AA7zx69

Gracias a todos por la gran discusión. He enviado cada uno de los problemas de plataforma que ha presentado a los equipos correspondientes. Para establecer expectativas en consecuencia, permítanme hacer una analogía de la búsqueda de empleo: es un poco como pasar la selección y pasar directamente a la entrevista en el proceso de contratación. A partir de aquí, cada problema está en manos del equipo adecuado para investigar y priorizar.

Agradezco el esfuerzo que ha hecho para informar estos problemas y seguiré realizándolos a medida que los equipos los revisen. Espero que todos sigan colaborando con nosotros sobre los problemas que encuentren y haré todo lo posible para ayudarlos a mejorar la experiencia del desarrollador de aplicaciones en Windows.

Gracias,

Ben Kuhn

@jtorjo, ¿ podrías compartir el informe WACK para el puerto UWP de NAudio que construiste?

Estos datos nos ayudarían a evaluar qué restricciones tendríamos que relajar para que NAudio pudiera pasar la certificación de la tienda.

@mikebattista He adjuntado el WACK. Tenga en cuenta solo los problemas de naudio.

Claramente, los problemas de log4net también serían geniales para resolver, aunque supongo que al bifurcar log4net y eliminar esas llamadas, debería estar bien. Sin embargo, es extraño que aparezcan, ya que estoy bastante seguro de que nunca nos llaman. De todas formas...

FindFirstFileExFromApp - esto debería (y de hecho existe) - definitivamente no debería estar marcado.

Puede ignorar EnumChildWindows / EnumWindows; puedo #ifdef.

ValidationResult.zip

¡Gracias! Evaluaremos las fallas de API admitidas. Me comuniqué con el equipo de audio para obtener su opinión sobre la posible relajación de las restricciones aquí.

@mikebattista increíble, ¡gracias! Estoy deseando que llegue esto :)

@jtorjo con respecto al escenario de arrastrar y soltar:

1. ¿Funciona tanto con archivos como con carpetas?
   Debería y lo hace para muchas aplicaciones y pruebas, si encuentra lo contrario, presente un error al respecto.
2. ¿Tengo acceso a .Path?
   Quizás: si hay una ruta real del sistema de archivos para respaldar el elemento de almacenamiento, entonces sí. (cosas como las bibliotecas de shell en realidad no tienen una ruta de sistema de archivos real)
3. ¿Es persistente (supongo que no)?
   No, la aplicación puede hacerla persistente agregándola a la lista de Acceso futuro.
4. ¿Debo aferrarme al StorageFile / Folder, o volver a crearlo más tarde desde .Path funcionará (asumiendo que la respuesta a 2. es SÍ)?
   Debe agregarlo a la Lista de acceso futuro o a las listas de Usados ​​más recientemente; de ​​lo contrario, el ÚNICO acceso que tiene es a través de esa instancia de un objeto. Cuando libere esa instancia, el acceso desaparecerá.

Con respecto a agregar archivos de video desde ubicaciones arbitrarias, el sistema deliberadamente no permite el acceso arbitrario, sin embargo, aún es posible que una aplicación maneje el caso común de archivos colocados en ubicaciones alternativas y los usuarios no han actualizado la biblioteca para incluirlos. Los servicios de indexación y detección de almacenamiento contienen código para escanear periódicamente la unidad en busca de detalles (tamaños de archivos, etc.) y se aprovechan para localizar archivos de fotos y videos. Una aplicación puede usar las API de StorageLibrary para determinar si se encontró alguna de esas ubicaciones que aún no se encuentran en la biblioteca y, de ser así, solicitar al usuario que las agregue. (Esto mantiene al usuario a cargo y permite un escenario de caso común) Nada agregará automáticamente todas las ubicaciones que contienen archivos, ya que no hay forma de determinar si eso es lo correcto. [Utilizo varias herramientas de creación y renderizado de modelos 3D y tengo literalmente miles de imágenes de textura que no me gustaría que aparecieran en mi biblioteca de fotos, por ejemplo]

'FindFirstFileExFromApp - esto debería (y de hecho existe) - definitivamente no debería estar marcado.'
Totalmente de acuerdo que todas las API de * FromApp están diseñadas y destinadas para su uso en aplicaciones de contenedor de aplicaciones. Entonces, si las herramientas están marcando alguno de ellos, ese es un error que debemos solucionar.

@ smaillet-ms Gracias por responder aquí. ¿Se está trabajando para mejorar la velocidad de las API de Windows.Storage? Hemos estado esperando una respuesta durante mucho tiempo. Estaría dispuesto a firmar un acuerdo de confidencialidad para utilizar las API mejoradas en el escenario de mi aplicación.

Actualmente uso la implementación FromApp de FindFirstFile, pero es imposible obtener miniaturas de elementos usando una API FromApp.

Este nivel de secreto sobre el trabajo que se está realizando para mejorar el tiempo de ejecución de Windows contrasta con lo que los ingenieros de Microsoft habían compartido anteriormente en el hilo.

Enlace de comentarios ignorados relevantes: https://aka.ms/AA6dgqz

Solo para agregar aquí, los detalles específicos pueden estar protegidos detrás de un NDA, pero si se está trabajando en este tema internamente, tranquilizaría a muchos desarrolladores de UWP si MS declarara esto públicamente (junto con una perspectiva general cuando podemos esperar ver / escuchar más).

Se ha trabajado mucho para mejorar el rendimiento de las API de almacenamiento en varias versiones del sistema operativo. En este punto, el desafío para los desarrolladores consiste principalmente en saber qué API usar y cuándo.

Hay muchas formas de hacer las cosas y muchas de ellas son totalmente incorrectas para una aplicación determinada. Desafortunadamente, no existe ningún tipo de "una respuesta correcta y verdadera", ya que realmente depende de la aplicación y de lo que hará con la información que obtiene del sistema de archivos. Las API * FromApp ofrecerán actualmente el mayor rendimiento en relación con sus homólogos estándar de Win32. Aunque, como se señaló aquí, no tiene todos los datos de shell adicionales como miniaturas, etc. (que en realidad son costosos de adquirir si no están disponibles en un caché). Entonces, si su aplicación necesita encontrar archivos de interés según el nombre / ruta o extensión, puede hacerlo usando las API * FromApp, luego cree un StorageFile basado en el nombre para recuperar más detalles. Aunque hay una sobrecarga duplicada en eso, ya que las verificaciones de acceso se realizan dos veces en este caso. Si está tratando de encontrar solo un archivo, a menudo eso no es un problema, pero la redundancia a mayor escala puede costar. Si usa Storage WinRT Apis con Windows.Storage.Search.IndexerOption .OnlyUseIndexerAndOptimizeForIndexedProperties, puede obtener una enumeración REALMENTE rápida, que recurre a un elemento de almacenamiento completamente realizado debajo a pedido, que tiene un impacto de rendimiento pero es menor que crear un elemento de una ruta, ya que debe incluir comprobaciones de acceso adicionales. La desventaja es que no funciona si el usuario ha desactivado el indexador para la ubicación en cuestión.

Si está rellenando una interfaz de usuario, como una aplicación de tipo de fotos / medios, entonces las clases BulkAccess son probablemente su mejor opción, ya que están orientadas a escenarios de uso en la interfaz de usuario con virtualización, etc. para que puedan proporcionar datos a la interfaz de usuario rápidamente y proporcionar más datos. según sea necesario a medida que el usuario se desplaza por el contenido.

Como dije, muchas compensaciones. Obviamente, tenemos trabajo por hacer para descubrir cómo documentar el proceso de evaluación de cuál será la mejor opción para una aplicación determinada. También continuamos evaluando lugares donde podemos lograr las mayores mejoras generales sin romper las aplicaciones existentes.

WinRT es una gran superficie y no es propiedad de un solo equipo en MS, cada equipo evalúa sus prioridades para cada lanzamiento y puede o no publicar sus planes con anticipación. Personalmente, me encantaría ver que las cosas lleguen a donde tenemos Zero Overhead con respecto a las API de Win32 dentro o fuera del contenedor de la aplicación. Obviamente, no estamos en ese punto ahora y no puedo hacer ninguna promesa de que llegaremos allí, las prioridades comerciales y los planes en un proyecto tan grande como Windows con tantos usuarios finales como tenemos es un proceso complejo que involucra duro / difícil opciones en todos los niveles. (Sin mencionar varios desafíos técnicos que pueden interponerse en el camino ...)

@ smaillet-ms

@jtorjo con respecto al escenario de arrastrar y soltar:

1. ¿Funciona tanto con archivos como con carpetas?
   Debería y lo hace para muchas aplicaciones y pruebas, si encuentra lo contrario, presente un error al respecto.
2. ¿Tengo acceso a .Path?
   Quizás: si hay una ruta real del sistema de archivos para respaldar el elemento de almacenamiento, entonces sí. (cosas como las bibliotecas de shell en realidad no tienen una ruta de sistema de archivos real)
3. ¿Es persistente (supongo que no)?
   No, la aplicación puede hacerla persistente agregándola a la lista de Acceso futuro.
4. ¿Debo aferrarme al StorageFile / Folder, o volver a crearlo más tarde desde .Path funcionará (asumiendo que la respuesta a 2. es SÍ)?
   Debe agregarlo a la Lista de acceso futuro o a las listas de Usados ​​más recientemente; de ​​lo contrario, el ÚNICO acceso que tiene es a través de esa instancia de un objeto. Cuando libere esa instancia, el acceso desaparecerá.

Suena bien. Implementaré esto en mi aplicación en algún momento.

[...] Los servicios de indexación y detección de almacenamiento contienen código para escanear periódicamente la unidad en busca de detalles (tamaños de archivos, etc.) y se aprovechan para localizar archivos de fotos y videos. Una aplicación puede usar las API de StorageLibrary para determinar si se encontró alguna de esas ubicaciones que aún no se encuentran en la biblioteca y, de ser así, solicitar al usuario que las agregue.

No tengo nada en contra de esto, pero parece una complicación adicional para mi aplicación. ¿Has oído hablar de alguien que realmente use esto?

En este momento, necesito encontrar mil formas de lidiar con todo tipo de problemas cuando se trata de StorageFolder / File, y esta es solo una más. Simplemente pone la carga, una vez más, en mí, el desarrollador.

'FindFirstFileExFromApp - esto debería (y de hecho existe) - definitivamente no debería estar marcado.'
Totalmente de acuerdo que todas las API de * FromApp están diseñadas y destinadas para su uso en aplicaciones de contenedor de aplicaciones. Entonces, si las herramientas están marcando alguno de ellos, ese es un error que debemos solucionar.

Acordado.

@ smaillet-ms

Se ha trabajado mucho para mejorar el rendimiento de las API de almacenamiento en varias versiones del sistema operativo. En este punto, el desafío para los desarrolladores consiste principalmente en saber qué API usar y cuándo.

Lamento decirlo, pero esto no suena muy tranquilizador.

En los días de WPF, simplemente usaba System.IO, hacía cualquier consulta de archivo / carpeta que quisiera, de una manera increíblemente fácil, y no me preocupaba en absoluto por la velocidad. Solo lo sabría, funciona. 4000 archivos, 10000 archivos: simplemente funciona.

Hay muchas formas de hacer las cosas y muchas de ellas son totalmente incorrectas para una aplicación determinada.

Eso dice bastante: las API ni siquiera deberían existir en primer lugar.

Desafortunadamente, no existe ningún tipo de "una respuesta correcta y verdadera", ya que realmente depende de la aplicación y de lo que hará con la información que obtiene del sistema de archivos. Las API * FromApp ofrecerán actualmente el mayor rendimiento en relación con sus homólogos estándar de Win32.

Eso es cierto seguro. Si bien ya he incluido la API * FromApp en una clase agradable de usar (para mi propio escenario), esto es lo que MS debería hacer también: presentar esto en una API agradable y fácil de usar: una simple envoltura de C # que muy probablemente cubra el 98% de los casos de uso.

Lo haría yo mismo, pero no tengo tiempo. Puedo compartir felizmente mi clase simple y alguien puede tomarla desde allí.

Aunque, como se señaló aquí, no tiene todos los datos de shell adicionales como miniaturas, etc. (que en realidad son costosos de adquirir si no están disponibles en un caché).

De acuerdo - Ya estoy haciendo esto por separado (solicitando miniaturas en un hilo diferente) - Una API de consulta para esto haría maravillas. Básicamente, pediría miniaturas a granel. Y podría obtener un IAsyncEnumerable.

Una vez más, MS puede crear una API simple para esto y, por ahora, simplemente haga un .GetThumbnailAsync en cada archivo. Luego, danos la API y luego podrás mejorarla (su velocidad).

Entonces, si su aplicación necesita encontrar archivos de interés según el nombre / ruta o extensión, puede hacerlo usando las API * FromApp, luego cree un StorageFile basado en el nombre para recuperar más detalles. Aunque hay una sobrecarga duplicada en eso, ya que las verificaciones de acceso se realizan dos veces en este caso.

En el lado positivo, ya hay mucha información presente en la API * FromApp: hora de creación, hora del último acceso, hora de la última escritura, tamaño del archivo.

Si está tratando de encontrar solo un archivo, a menudo eso no es un problema, pero la redundancia a mayor escala puede costar. Si usa Storage WinRT Apis con Windows.Storage.Search.IndexerOption .OnlyUseIndexerAndOptimizeForIndexedProperties, puede obtener una enumeración REALMENTE rápida, que recurre a un elemento de almacenamiento completamente realizado debajo a pedido, que tiene un impacto de rendimiento pero es menor que crear un elemento de una ruta, ya que debe incluir comprobaciones de acceso adicionales. La desventaja es que no funciona si el usuario ha desactivado el indexador para la ubicación en cuestión.

Esto tiene varios inconvenientes: en primer lugar, en mis pruebas, fue más rápido que los archivos no indexados, pero no tan rápido. Creo que fue de 3 a 5 veces más rápido, pero sigue siendo entre 10 y 50 veces más lento que * FromApp. Eso es INCREÍBLEMENTE LENTO. Además de eso, realmente no puedo decirles a mis usuarios que marquen "Todos los archivos para tener un contexto indexado además de las propiedades del archivo", es simplemente su opción. Y probablemente muchos usuarios simplemente lo dejen sin marcar.

De hecho, Windows debería descubrir automáticamente los archivos usados ​​e indexar esas carpetas; es muy probable que sea muy importante para los archivos multimedia (video / foto / música) y para los documentos.

Si está rellenando una interfaz de usuario, como una aplicación de tipo de fotos / medios, entonces las clases BulkAccess son probablemente su mejor opción, ya que están orientadas a escenarios de uso en la interfaz de usuario con virtualización, etc. para que puedan proporcionar datos a la interfaz de usuario rápidamente y proporcionar más datos. según sea necesario a medida que el usuario se desplaza por el contenido.

Honestamente, ni siquiera sabía que esto existía, lo estoy viendo mientras hablamos.
Sin embargo, si entiendo esto correctamente, esto es solo un poco de azúcar sintáctico, ya que sufrirá los mismos problemas de rendimiento que IStorageQuery.

Y esos problemas de rendimiento son enormes. Son tan grandes que, básicamente, para aproximadamente 1000 archivos, el primer archivo se recupera después de 9-10 segundos. En otras palabras, una vez que comience a enumerar el resultado, se bloqueará durante 9-10 segundos antes de hacer nada. Supongo que lo mismo habría hecho con FileInformationFactory, solo que la interfaz de usuario responderá durante ese tiempo.

WinRT es una gran superficie y no es propiedad de un solo equipo en MS, cada equipo evalúa sus prioridades para cada lanzamiento y puede o no publicar sus planes con anticipación. Personalmente, me encantaría ver que las cosas lleguen a donde tenemos Zero Overhead con respecto a las API de Win32 dentro o fuera del contenedor de la aplicación.

Bueno, muchos de nosotros también;) Entiendo que WinRT es una gran parte de Windows y que las diferentes partes están dispersas en diferentes equipos.

No es muy reconfortante para nosotros no ver públicamente la visión que MS tiene de WinRT. No tener una línea de tiempo sobre qué / cuándo / si sucede.

Para mí, la velocidad de manejo de archivos / carpetas es simplemente primordial. ¿Cómo puede alguien confiar en WinRT / UWP, cuando hacer algo tan simple como enumerar los archivos en una carpeta puede llevar tanto tiempo? Y descubrir cómo mejorar eso se reduce a "¿tendré la suerte de que mi búsqueda de Google se encuentre con la API * FromApp"?

No quiero parecer ingrato. Realmente aprecio que se haya tomado el tiempo y nos haya explicado todo esto. ¡Gracias!

@BenJKuhn Alguien (https://docs.microsoft.com/answers/questions/6112/updating-existing-app-with-new-certificate-uwp.html?childToView=25297#comment-25297) presentó otro ticket sobre el Problema de "certificado nuevo" aquí -> https://aka.ms/AA8bw9v

En el lado realmente malo: intenté acceder a esto y me dice que no tengo acceso para ver este ticket. Esto realmente no ayuda con la credibilidad de "Feedback Hub".

¿Por qué permite la descarga lateral fuera de la tienda de MS, pero hace que sea casi imposible hacerlo?

De hecho, eso no es cierto. No puede cargar su aplicación en MS Store y usar el instalador de aplicaciones como una forma alternativa de instalar la aplicación. Mi aplicación fue prohibida por eso durante la certificación.
Políticas de MS Store:
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies?redirectedfrom=MSDN#101 -distinct-function - valor-precisa-representación

10.1.5
Su aplicación puede promocionar o distribuir software solo a través de Microsoft Store.

Después de haber tenido que eliminar el archivo de instalación de aplicaciones de mi servidor, los usuarios pueden usar MS Store nuevamente para instalar mi aplicación. Entiendo, las reglas son reglas, incluso yo no puedo encontrar una razón para ellas. Pero es realmente decepcionante, cuando conozco muchas aplicaciones, que se distribuyen a través de la tienda y el instalador de aplicaciones (Unigram) o chocolatey (nueva Terminal de MS).

¿Por qué permite la descarga lateral fuera de la tienda de MS, pero hace que sea casi imposible hacerlo?

De hecho, eso no es cierto. No puede cargar su aplicación en MS Store y usar el instalador de aplicaciones como una forma alternativa de instalar la aplicación. Mi aplicación fue prohibida por eso durante la certificación.
Políticas de MS Store:
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies?redirectedfrom=MSDN#101 -distinct-function - valor-precisa-representación

No estoy seguro de que estemos hablando de lo mismo aquí; en esta época, simplemente no puedo encontrar una sola razón para necesitar o querer MS Store. Mi problema fue que es increíblemente difícil desarrollar una aplicación y luego implementarla fuera de la tienda de MS.