Cientos de desarrolladores opinan sobre Visual Studio 2022

Basándose únicamente en un vistazo a la próxima versión preliminar, cientos de desarrolladores han expresado sus opiniones sobre lo que se avecina con el lanzamiento de Visual Studio 2022.

VS 2022 se presentó el 19 de abril, y Microsoft prometió un IDE más ágil, rápido y de 64 bits. La sorpresa de los 64 bits fue uno de los principales temas de discusión de los desarrolladores en los comentarios del anuncio, así como en los foros orientados a los desarrolladores de Reddit y Hacker News. Sólo en estos tres sitios se han sumado más de 700 comentarios (y se siguen sumando en el momento de escribir estas líneas).

Otros temas candentes fueron el apoyo (o la percepción de la falta de apoyo) de Azure DevOps, junto con Linux, el legado de .NET Framework, e incluso los iconos renovados.

He aquí una muestra de lo que los lectores tenían que decir.

64 bits
Los comentarios sobre este tema fueron principalmente de naturaleza «por qué ha tardado tanto». Muchos también estaban preocupados por las extensiones de VS que tendrían que ser actualizadas.

Estoy seguro de que mucha gente estará contenta con la versión de 64 bits de VS. Pero eso significa que ninguna de las extensiones existentes que tenemos funcionará ya, lo que significa una probable larga espera para que los autores de las extensiones actualicen (si es que alguna vez lo hacen). También me preocupa que MS haya dedicado mucho tiempo a mover las cargas de trabajo fuera del proceso para resolver los problemas de memoria a costa de la velocidad y la fiabilidad. El cambio a x64 significa que mis instancias de VS (de las cuales puedo ejecutar varias) pueden crecer fácilmente fuera de control, pero si eso significa más estabilidad debido a menos trabajo fuera de proceso, entonces genial.

Un desarrollador de Microsoft respondió: «Somos conscientes de que todos los autores de extensiones tendrán que migrar sus extensiones a 64 bits para poder utilizarlas con éxito en esa versión. Actualmente estamos trabajando en una guía para que los autores de extensiones puedan migrar con éxito y rápidamente a tiempo para el lanzamiento general de VS de 64 bits.»
64bit no puede suceder lo suficientemente pronto. Tengo que reiniciar VS 2019 múltiples veces al día trabajando con Blazor WASM y sin extensiones porque VS se congela mientras depura y la memoria de devenv.exe ronda los 2gb.

Comentando un GIF/vídeo que muestra una solución que se abre con 1600 proyectos y 300000 archivos: Eso es lo que da miedo en realidad… En lugar de trabajar muy duro para reducir ese uso de memoria, digamos en un 20% o más, simplemente se hace trampa proporcionando más espacio de memoria.
VS 2022 abriendo 1.600 proyectos y 300k archivos.
VS 2022 abriendo 1.600 proyectos y 300.000 archivos (fuente: Microsoft).

Atrás quedaron los tiempos en los que los desarrolladores de Microsoft intentaban hacer que su software hiciera más en un hardware mucho menos potente, eran capaces de hacerlo, ¡y todo podía funcionar con sólo ~100 MB de memoria!
Enhorabuena por haber dado finalmente el salto a los 64 bits. Sólo han tenido que pasar 18 años desde la primera versión de 64 bits de Windows en 2003. Lo siento, no pude resistirme a esa pequeña indirecta. Estoy realmente agradecido y emocionado de que las cosas estén progresando en la dirección correcta 😀 .

Iconos/UI
El anuncio de Microsoft decía:

Estamos refrescando la interfaz de usuario para mantenerte mejor en tu flujo. Algunos de los cambios son sutiles toques cosméticos que modernizan la interfaz de usuario o reducen el hacinamiento. En general, nuestro objetivo es reducir la complejidad y disminuir la carga cognitiva para que puedas concentrarte y permanecer en la zona. Además, hacer que Visual Studio sea más accesible ofrece una mejor usabilidad para todos: la próxima versión de Visual Studio incluirá:

Iconos actualizados para una mayor claridad, legibilidad y contraste.
Código Cascadia, una nueva fuente de ancho fijo para mejorar la legibilidad y la compatibilidad con ligaduras. (¡Si quieres, puedes probar Cascadia Code hoy mismo! https://aka.ms/CascadiaCode)
Temas de producto renovados y mejorados. Integración con Accessibility Insights para detectar problemas de accesibilidad antes de que lleguen a los usuarios finales.

Actualización de iconos
Icon Refresh (fuente: Microsoft).

Como era de esperar (los desarrolladores adoran sus iconos), los iconos estaban en la mente de muchos desarrolladores:

Los nuevos iconos tienen un aspecto aún peor. Mejor claridad, legibilidad y contraste tenían los iconos de VS2010, eran perfectos.
De hecho, creo que los iconos de 2010 son un poco anticuados y prefiero los de 2019, pero definitivamente podemos estar de acuerdo en que los nuevos iconos de 2022 son horribles.
Estoy de acuerdo. Los nuevos iconos tienen peor contraste que los existentes, y parecen «borrosos» en comparación.
Sin embargo, me gusta la renovación de los iconos y el diseño, y siempre aprecio que os ocupéis de estos pequeños detalles. También tengo ganas de ver qué opciones de personalización de la interfaz de usuario estarán disponibles en la próxima versión. Me encantaría ver una forma de cambiar los colores sin tener que usar una extensión.

Velocidad, rendimiento y fiabilidad frente a nuevas características
Muchos desarrolladores dijeron que preferían centrarse en mejorar y arreglar la funcionalidad existente en lugar de concentrarse en introducir nuevas características:

Tengo sentimientos encontrados al respecto. Todo suena bien, sin embargo, siento que podría ser tan buggy como VS2019 o peor. Para mí sería suficiente con ofrecer una experiencia sólida de edición de código.
Después del lanzamiento, sería bueno que se detuviera todo el nuevo desarrollo y se tomara un descanso. Realmente no necesitamos tantas características nuevas. Céntrate en arreglar todos los bugs de la lista de pendientes durante un par de meses. Todos ellos. De alta y baja prioridad. Todas las mejoras de productividad conseguidas por las nuevas funcionalidades quedan anuladas por todos los bugs y las veces que tengo que reiniciar VS o incluso la máquina.
Desgraciadamente se centran en añadir funciones (con errores y lentas), ya que esta es la razón principal para cobrar dinero por la «nueva versión».
Todo esto es excelente, pero por favor pongan un poco más de esfuerzo en el rendimiento. Habéis hecho un gran trabajo haciendo que las soluciones de apertura sean más rápidas, seguid trabajando en ello y haced lo mismo con todas las acciones.
No creo que necesitemos tantas características nuevas todo el tiempo. El rendimiento y la estabilidad son las principales características necesarias en este momento.

Azure DevOps
Se discutió mucho sobre este comentario:

«‘Visual Studio 2022 incluirá un nuevo y potente soporte para Git y GitHub’. Pero hemos perdido el soporte para Azure DevOps…»

Eso dio lugar a comentarios como:

Yo iba a comentar lo mismo, me encanta el soporte de GitHub, pero también amamos y usamos Azure DevOps, VS no puede apartar toda la atención de Azure DevOps (con GIT)
Lo triste es que muchos no podemos movernos a Git sin impactar muchos años de procesos y herramientas. No puedo imaginar que una pequeña inversión para hacer que Source Link funcione (cuando imagino que la mayor parte del código necesario ya existe desde la tarea de construcción de Azure DevOps Index Sources) sea una petición poco razonable.
¡Perder el soporte para Azure DevOps sería horrible! ¿Es esto realmente cierto?

Microsoft respondió: «¡Eso no es cierto! Seguimos apoyando a nuestros desarrolladores y escenarios que utilizan Azure DevOps. Ya tiene y seguirá teniendo una gran integración de Git en VS. Puedes ver cómo estamos apoyando los repositorios de Azure DevOps en nuestras nuevas experiencias Git. En el pasado, el soporte de GitHub ha estado ausente en el IDE y es por eso que estás escuchando más noticias sobre el aumento de la funcionalidad de GitHub de nosotros a medida que lo construimos. También puedes echar un vistazo a la hoja de ruta de Azure DevOps».

Marco .NET
Varios comentarios sobre el antiguo marco de trabajo exclusivo de Windows se referían a si seguía siendo compatible (la respuesta, muchas veces, fue «Sí»). También, sorprendente para este reportero, fue la declaración de Mad Kristensen de Microsoft en respuesta a esta pregunta:

«¿Será una aplicación .Net 6 o seguirá siendo tecnología antigua? Sería bueno que utilizara el nuevo .net 6 para aprovechar la mejora de la velocidad y un poco de alimentación de perros. ¿Usando WPF? ¿O .net MAUI?»

Kristensen respondió: «Visual Studio 2022 seguirá funcionando con .NET Framework utilizando principalmente WPF». Los lectores comentaron:

MS prácticamente ha anunciado que NF está muerto y que .NET 5 es una transición «sin fisuras» que las aplicaciones NF existentes deberían utilizar a menos que dependan de una tecnología no soportada como WCF Server. Es sorprendente que VS no vaya a apuntar a .NET 6, ya que eso significa que se está ejecutando en una tecnología obsoleta. Creo que sería un blog muy interesante si alguien del equipo quisiera explicar los retos de mover VS a NET 6 y por qué VS no lo va a hacer. Estoy seguro de que muchos equipos se preguntan lo mismo que el equipo de VS: el tamaño de la aplicación, los riesgos de las conversiones, el retorno de la inversión, las características no soportadas, etc. Me interesa aún más la respuesta del equipo de NET a estas cuestiones y lo que van a hacer (y el calendario) para facilitar la migración de VS. Dado que las versiones de VS tienen una duración de 2 a 3 años, eso significaría que VS se va a saltar NET 5/6 y probablemente 7.
¿Qué impide a Visual Studio pasar de .NET Framework a .NET 6? Si se trata de la compatibilidad con versiones anteriores, yo personalmente me conformaría con utilizar las versiones anteriores de VS para los tipos de proyectos más antiguos. Con el soporte oficial de WPF en .NET 6, es una barrera menos. Además, con todas las mejoras de rendimiento implementadas en .NET Core a lo largo de los años, parece algo obvio. ¿Será la siguiente gran prioridad después de la versión 2022?
Dado que Visual Studio 2022 se está moviendo a 64 bits, ¿por qué no pasar a .NET 6 para aprovechar las mejoras de rendimiento y sobrecarga? Además, .NET 6 es una versión LTS y ya tiene soporte para .NET Standard, C++/CLI y WPF, así que creo que la compatibilidad no será un problema. He creado una solicitud de función en la Comunidad de Desarrolladores: https://developercommunity.visualstudio.com/t/Move-Visual-Studio-2022-to-NET-6/1402400

Linux
Linux sólo se menciona una vez en el anuncio, en la sección de C++: «También estamos integrando el soporte para CMake, Linux y WSL para facilitar la creación, edición, construcción y depuración de aplicaciones multiplataforma».

Los desarrolladores lo mencionaron muchas veces al comentar el post y en Reddit:

Un comentario decía: «Según http://www.statista.com el 48% de los desarrolladores de software utilizan linux. La falta de soporte de Visual Studio para linux está perjudicando enormemente a Microsoft».

Tim Heuer, de Microsoft, respondió: «Hemos añadido un nuevo soporte para aprovechar los contenedores WSL y Linux para permitirte hacer cosas como depurar en Linux desde tu entorno Windows, o ejecutar suites de prueba dirigidas a Linux, todo desde Visual Studio».

Otros comentarios incluyen:

Puedes ejecutar Visual Studio Code en Linux, puedes desarrollar aplicaciones .NET 5/.NET 6 con el SDK de .NET y la extensión VS Code C#.
La versión para Windows, la versión para Mac…
Y la versión para Linux
¿Visual Studio 2025 tal vez?
Está bien que pueda construir para objetivos Linux, pero me pregunto si alguna vez van a lanzar una versión Linux de VS
Me pregunto si van a permitir la depuración remota en Linux. Con Azure siendo Linux principalmente puede ser difícil lidiar con la falta de depuración remota.

Soporte para ARM
Esto fue mencionado por varios desarrolladores comentando en el post de anuncio y en Hacker News:

Sería bueno saber si el 2022 es a prueba de futuro para ARM64.
Espero que esto sea un paso más hacia la compatibilidad con ARM64.
Asegúrese de que se ejecutará de forma nativa en Windows en ARM.

En respuesta a este último comentario, Andy Sterland de Microsoft respondió: «Hay una sugerencia de la comunidad de desarrolladores para el soporte nativo de ARM: https://developercommunity.visualstudio.com/t/native-arm-support-for-visual-studio/1161018. Por favor, voten por ella, y por cualquier otra persona que lea esto y que necesite un VS nativo para ARM».

Dichos votos, así como otros comentarios, pueden enviarse a la Comunidad de Desarrolladores de Microsoft.