Pues eso, que al crear un proyecto para .NET MAUI con Visual Studio 2022 (no preview), concretamente con Microsoft Visual Studio Community 2022 (64-bit) – Version 17.3.5, al intentar usar el proyecto (incluso sin modificar nada) me soltaba ese error: Platform version is not present for one or more target frameworks (concretamente para ios).
Buscando en la red de redes (internet) me topé con varias soluciones que no solucionaban nada (o yo no sabía cómo aplicar esas soluciones, todo hay que decirlo), y al final «trasteando» con el comando workload de dotnet (que en su día usé, sin éxito, para intentar instalar el workload de iOS), probé con una de las opciones o comandos que te da. Al usar dotnet workload -h te muestra esto:
Commands:
install <WORKLOAD_ID> Install one or more workloads.
update Update all installed workloads.
list List workloads available.
search <SEARCH_STRING> Search for available workloads.
uninstall <WORKLOAD_ID> Uninstall one or more workloads.
repair Repair workload installations.
restore <PROJECT | SOLUTION> Restore workloads required for a project.
Y de ahí la que he usado es la última, que suena bien…
Así que, te sitúas en el directorio en el que está el proyecto de .NET MAUI, y escribes (todo esto en la terminal, el shell o línea de comandos, como prefieras llamarlo):
dotnet workload restore "nombre del proyecto.csproj"
Por supuesto, debes sustituir «nombre del proyecto.csproj» por el nombre de tu proyecto y no es necesario ponerlo entre comillas.
Nota: Puede ser que a los workloads se le vaya la olla… sí… así que… lo mismo un dotnet workload repair puede que lo tengas que usar.
Pues eso… este post es para tener actualizada la utilidad CrearClaseTabla que en su día (allá por 2004) creé para generar o crear clases para acceder a una base de datos de SQL Server o de Access.
La idea de esta utilidad (la aplicación y la DLL que es la que hace el trabajo) es crear clases de Visual Basic o C# de cada tabla de la base de datos, con idea de facilitar el acceso por código a esas tablas.
En la última actualización de hoy 1 de octubre de 2022 se contempla, entre otras cosas, la definición de variables asignadas sin indicar el tipo (inferencia de tipos) además de convertir adecuadamente las conversiones de tipo de Visual Basic a C# (aunque en el código solo uso CInt).
Nota: He creado el proyecto para .NET 6.0 (Windows) y está disponible en GitHub: gsCrearClasesTablas. Por ahora el código es el mismo en este nuevo proyecto como en el que referencio en este post/artículo que es para .NET Framework 4.8.1
El código «base» que utilizo es el que yo uso con Visual Basic y la clase CrearClase apoyada de ConvLag se encarga de generar el código de Visual Basic o el de C#.
Por ejemplo, el código que te muestro primero, en el generador de clases lo defino como te muestro en el segundo bloque de código:
Este es el código en que me he basado:
cmd.Transaction = tran
cmd.ExecuteNonQuery()
' Si llega aquí es que todo fue bien,
' por tanto, llamamos al método Commit.
tran.Commit()
msg = "Se ha actualizado el Cliente correctamente."
Catch ex AsException
msg = $"ERROR: {ex.Message}"
' Si hay error, deshacemos lo que se haya hecho.
Try
If tran IsNotNothingThen
tran.Rollback()
EndIf
Catch ex2 AsException
msg = $" (ERROR RollBack: {ex.Message})"
EndTry
Finally
con.Close()
EndTry
EndUsing
Return msg
Este es el código interno que uso en el conversor (el método generarClase): En los comentarios está el código mostrado antes y el equivalente para generar el código de VB o de C#.
sb.AppendLine()
' cmd.Transaction = tran
sb.AppendFormat(" {0}{1}", ConvLang.Asigna("cmd.Transaction", "tran"), vbCrLf)
' cmd.ExecuteNonQuery()
sb.AppendFormat(" {0}{1}", ConvLang.Instruccion("cmd.ExecuteNonQuery()"), vbCrLf)
sb.AppendLine()
' ' Si llega aquí es que todo fue bien,
' ' por tanto, llamamos al método Commit
sb.AppendFormat(" {0}{1}", ConvLang.Comentario(" Si llega aquí es que todo fue bien,"), vbCrLf)
sb.AppendFormat(" {0}{1}", ConvLang.Comentario(" por tanto, llamamos al método Commit."), vbCrLf)
' tran.Commit()
sb.AppendFormat(" {0}{1}", ConvLang.Instruccion("tran.Commit()"), vbCrLf)
sb.AppendLine()
' msg = "Se ha actualizado el Cliente correctamente."
sb.AppendFormat(" {0}{1}", ConvLang.Asigna("msg", """Se ha actualizado un " & nombreClase & " correctamente."""), vbCrLf)
sb.AppendLine()
' Catch ex As Exception
sb.AppendFormat(" {0}{1}", ConvLang.Catch("ex", "Exception"), vbCrLf)
' msg = $"ERROR: {ex.Message}"
sb.AppendFormat(" {0}{1}", ConvLang.Asigna("msg", "$""ERROR: {ex.Message}"""), vbCrLf)
' ' Si hay error, deshacemos lo que se haya hecho
sb.AppendFormat(" {0}{1}", ConvLang.Comentario(" Si hay error, deshacemos lo que se haya hecho."), vbCrLf)
' Try
sb.AppendFormat(" {0}{1}", ConvLang.Try(), vbCrLf)
' Añadir comprobación de nulo en el objeto tran (17-abr-21)
' If tran IsNot Nothing Then
sb.AppendFormat(" {0}{1}", ConvLang.If("tran", "IsNot", "Nothing"), vbCrLf)
' tran.Rollback()
sb.AppendFormat(" {0}{1}", ConvLang.Instruccion("tran.Rollback()"), vbCrLf)
' End If
sb.AppendFormat(" {0}{1}", ConvLang.EndIf, vbCrLf)
' Catch ex2 As Exception
sb.AppendFormat(" {0}{1}", ConvLang.Catch("ex2", "Exception"), vbCrLf)
' msg &= $" (ERROR RollBack: {ex.Message})"
sb.AppendFormat(" {0}{1}", ConvLang.Asigna("msg", "$""ERROR RollBack: {ex2.Message}"""), vbCrLf)
' End Try
sb.AppendFormat(" {0}{1}", ConvLang.EndTry(), vbCrLf)
sb.AppendLine()
sb.AppendFormat(" {0}{1}", ConvLang.Finally, vbCrLf)
' If Not (con is nothing) then
sb.AppendFormat(" {0}{1}", ConvLang.If("", "Not", "(con Is Nothing)"), vbCrLf)
' con.Close()
sb.AppendFormat(" {0}{1}", ConvLang.Instruccion("con.Close()"), vbCrLf)
' End If
sb.AppendFormat(" {0}{1}", ConvLang.EndIf, vbCrLf)
' End Try
sb.AppendFormat(" {0}{1}", ConvLang.EndTry(), vbCrLf)
sb.AppendLine()
' End Using
sb.AppendFormat(" {0}{1}", ConvLang.EndUsing(), vbCrLf)
sb.AppendLine()
' Return msg
sb.AppendFormat(" {0}{1}", ConvLang.Return("msg"), vbCrLf)
Y el código generado de Visual Basic sería como te he mostrado arriba y el de C# sería más o menos este:
cmd.Transaction = tran;
cmd.ExecuteNonQuery();
// Si llega aquí es que todo fue bien,// por tanto, llamamos al método Commit.
tran.Commit();
msg = "Se ha actualizado un Producto correctamente.";
}catch(Exception ex){
msg = $"ERROR: {ex.Message}";
// Si hay error, deshacemos lo que se haya hecho.try{
if(tran != null ){
tran.Rollback();
}
}catch(Exception ex2){
msg = $"ERROR RollBack: {ex2.Message}";
}
finally{
if( ! (con == null )){
con.Close();
}
}
}
return msg;
Como ves, no está bien formateado, (es el código generado directamente) pero si lo pegas en Visual Studio te lo formateará bien y lo coloreará mejor 😉
Y para muestra, ese trozo de código en un fichero abierto en Visual Studio 2022: (Aunque todo hay que decirlo, en VB lo formatea bien, aunque solo sea un fichero abierto directamente (sin formar parte de ningún proyecto) mientras que en C# le he tenido casi que dar el formato manualmente, en fin…)
cmd.Transaction = tran;
cmd.ExecuteNonQuery();
// Si llega aquí es que todo fue bien,
// por tanto, llamamos al método Commit.
tran.Commit();
msg = "Se ha actualizado un Producto correctamente.";
}
catch(Exception ex)
{
msg = $"ERROR: {ex.Message}";
// Si hay error, deshacemos lo que se haya hecho.
try
{
if (tran != null)
{
tran.Rollback();
}
}
catch(Exception ex2)
{
msg = $"ERROR RollBack: {ex2.Message}";
}
finally
{
if (!(con == null))
{
con.Close();
}
}
}
Pero la idea es que te quedes con lo que la clase hace.
También es cierto que yo suelo generar el código para Visual Basic y es lo que realmente he probado más, hoy he estado viendo cómo lo generaría para C# y he estado haciendo algunas correcciones (que he indicado en el fichero Revisiones.md publicado con GitHub).
Una captura de la utilidad tal como la tengo a día 1 de octubre de 2022.
Figura 1. La utilidad en funcionamiento a día de hoy 1 de octubre de 2022
Y esto es todo amigo (o amiga), ya sabes, si quieres participar en el proyecto para mejorarlo, puedes hacerlo, creo que en algún sitio indico cómo avisarme de los errores que encuentres y cómo actualizar el fichero Revisiones.txt que ahora es Revisiones.md.
Y si quieres usarlo sin más aportaciones, estaría bien que hicieras una pequeña aportación monetaria en PayPal (no es obligatorio, pero es de agradecer).
En breve publicaré en GitHub el ejecutable compilado con .NET Framework 4.8.1.
Por cierto, en el proyecto (los dos) he incluido un fichero de nombre seguro (strong name) para firmar los ensamblados, ese fichero (elGuille_compartido.snk) lo puedes usar «libremente» (ya sabes todo está con la licencia MIT) para firmar los ensamblados con nombre seguro.
Espero que te sirva de utilidad.
Nos vemos. Guillermo
P.S. Sería interesante convertir el proyecto para .NET 6 (o 7) y también usando el código completamente en C#. Actualmente está creado para usar con .NET Framework 4.8.1 y escrito enteramente en Visual Basic.
P.S.2 Ya está creado el proyecto para .NET 6.0 (net6.0-windows) y publicado en GitHub (gsCrearClasesTablas).
Pues eso… ahora le toca lo de cambiar el tamaño de una ventana de Windows (WinUI que es como se llama la plataforma de Windows en .NET MAUI (en Xamarin es UWP), aquí solo te voy a mostrar el código de un tamaño fijo, ya que no me he puesto a experimentar cómo usar el tamaño predeterminado, ya que la forma de hacerlo es con otras APIs y… pues eso… que no me gusta demasiado el .NET MAUI como para dedicarle más tiempo de lo justo y necesario… 😉
Lo que si te quiero decir, es que precisamente me puse a mirar todo esto de cambiar el tamaño porque a diferencia de las aplicaciones con Xamarin.Forms, als de .NET MAUI «no recuerdan» el tamaño de la ventana en las siguientes veces que se use la aplicación, algo que en las de Xamarin sí hace, es decir, se muestra con el tamaño predeterminado y si cambias el tamaño de la ventana, la próxima vez que se utilice usará ese último tamaño.
Pero en las aplicaciones de .NET MAUI, siempre usa el tamaño «grande» y… pues como que no, por eso me puse a investigar, primero para hacerlo en .NET MAUI, y ya puestos me puse a mirar para Xamarin.
¿Cómo cambiar el tamaño de la ventana de Windows (WinUI) en un proyecto de .NET MAUI?
Es muy simple, el código se pone en el constructor de la clase App principal (no la del proyecto de Windows) y el código podría ser como este que te muestro para poner la ventana en un tamaño de 800 x 900 (ancho x alto).
namespace CambiarTamañoWindows_MAUI;
publicpartialclassApp : Application
{
publicApp()
{
InitializeComponent();
// Indicar el tamaño para la app de Windows.
Microsoft.Maui.Handlers.WindowHandler.Mapper.AppendToMapping(nameof(IWindow), (handler, view) =>
{
#if WINDOWS
// Asignar manualmente el tamaño.
int winWidth = 800;
int winHeight = 900;
var mauiWindow = handler.VirtualView;
var nativeWindow = handler.PlatformView;
nativeWindow.Activate();
IntPtr windowHandle = WinRT.Interop.WindowNative.GetWindowHandle(nativeWindow);
var windowId = Microsoft.UI.Win32Interop.GetWindowIdFromWindow(windowHandle);
var appWindow = Microsoft.UI.Windowing.AppWindow.GetFromWindowId(windowId);
appWindow.Resize(new Windows.Graphics.SizeInt32(winWidth, winHeight));
#endif
});
MainPage = newAppShell();
}
}
Y esto es todo lo que hay que hacer… simple, ¿verdad? pues sí, para qué engañarnos, aunque eso de tener que ponerlo en un condicional de compilación es un rollo, pero tiene sentido ya que solo es para un proyecto de Windows. El problema es que no te muestra nada el «intellisense» ni nada de esas monerías que tenía en el proyecto para Xamarin.
Una captura con el programa en funcionamiento.
Figura 1. La aplicación en funcionamiento.
Y esto es todo… ahora subiré el código (o parte de él) a GitHub y después te pondré el enlace.
Acuérdate de (si quieres) hacer un donativo en PayPal para poder seguir teniendo este sitio en funcionamiento, gracias.
Pues eso… ¡A la pila tiempo! A ver si me acuerdo de cómo se escriben los posts en el blog… que ya hace tiempo que no publico nada. Y en esta ocasión es para contarte cómo cambiar el tamaño de una aplicación de Windows (UWP) creada con Xamarin.Forms.
No me voy a enrollar demasiado porque quiero ponerte otro ejemplo para .NET MAUI, ya que, según he visto por la red (y lo que yo he probado) es que se hace de forma diferente.
Básicamente hay dos formas de hacerlo, una es dejando que sea el propio Windows el que se encargue del tamaño (y de recordar el último tamaño que el usuario ha puesto o, mejor dicho, el último tamaño asignado por el usuario (cambiando el tamaño de la ventana).
Para hacer esto en Xamarin.Forms, tenemos que hacerlo en el proyecto para UWP. Normalmente te dicen que en el método OnLaunched de la clase App (la del proyecto para UWP, no la del proyecto principal con la funcionalidad).
Pero en las pruebas que últimamente he hecho, también se puede hacer en el constructor de MainPage (la página principal del proyecto para UWP).
¿Por qué hacerlo en un sitio o en otro?
Si no vas a hacer nada especial, puedes ponerlo en el método OnLaunched (ahora te explico en qué parte de ese método).
Si quieres hacer algo, por ejemplo, usar valores que has asignado en la clase App del proyecto Xamarin, lo mejor es hacerlo en el constructor de MainPage, porque en ese constructor se instancia el objeto App del proyecto principal (en el que se define la funcionalidad de la aplicación y que está referenciado en el proyecto UWP o en los de Android, iOS, etc.). Y al hacerlo después de la llamada a LoadApplication(new EspacioDeNombres.App()); nos aseguramos que ese objeto esté instanciado y así poder acceder a los valores que tengas asignados, que pueden ser leídos de un fichero de configuración, una base de datos, asignados directamente, etc.
Un ejemplito, por favor
Vamos a suponer que quieres que tu aplicación (cuando se use en Windows) tenga, por ejemplo, un tamaño de 450×650 (ancho x alto). Creo que el ancho mínimo es 400, pero solo es una conjetura.
Este sería el código a utilizar en OnLaunched.
Aclararte que deberías poner una importación del espacio de nombres Windows.UI.ViewManagement para poder acceder a la clase ApplicationView y a la enumeración ApplicationViewWindowingMode. Por otro lado, el tamaño se asigna con un objeto Size que está definido en Windows.Foundation, por tanto, asegúrate que tengas esas dos importaciones.
using Windows.Foundation;
using Windows.UI.ViewManagement;
Repetimos: El siguiente código que te muestro es el método OnLaunched de la clase App del proyecto para UWP, solo he quitado la parte de #if DEBUG ya que, no nos interesa y así seguro que sabes exactamente dónde poner el código para cambiar o asignar el tamaño de la ventana de Windows (UWP).
/// Invoked when the application is launched normally by the end user. Other entry points
/// will be used such as when the application is launched to open a specific file.
///</summary>
///<paramname="e">Details about the launch request and process.</param>
protectedoverridevoid OnLaunched(LaunchActivatedEventArgs e)
{
Frame rootFrame = Window.Current.Content asFrame;
// Do not repeat app initialization when the Window already has content,
// just ensure that the window is active
if (rootFrame == null)
{
// Create a Frame to act as the navigation context and navigate to the first page
rootFrame = newFrame();
rootFrame.NavigationFailed += OnNavigationFailed;
Xamarin.Forms.Forms.Init(e);
if (e.PreviousExecutionState == ApplicationExecutionState.Terminated)
{
//TODO: Load state from previously suspended application
}
// Asignar manualmente el tamaño. (04/sep/22 17.50)
int winWidth = 450; // el mínimo creo que es 400 de ancho
int winHeight = 650;
//Xamarin.Forms.Forms.Init(e, assembliesToInclude);
ApplicationView.PreferredLaunchViewSize = newSize(winWidth, winHeight);
ApplicationView.PreferredLaunchWindowingMode = ApplicationViewWindowingMode.PreferredLaunchViewSize;
// Place the frame in the current Window
Window.Current.Content = rootFrame;
}
if (rootFrame.Content == null)
{
// When the navigation stack isn't restored navigate to the first page,
// configuring the new page by passing required information as a navigation
// parameter
rootFrame.Navigate(typeof(MainPage), e.Arguments);
}
// Ensure the current window is active
Window.Current.Activate();
}
Y esto es todo… al menos para que la aplicación se cargue con ese tamaño… aunque debes tener en cuenta una cosita que explican esta gente de Microsoft en la documentación de la propiedad ApplicationView.PreferredLaunchViewSize y es lo que te pongo en el siguiente «quote» (en inglés y la traducción):
This property only has an effect when the app is launched on a desktop device that is not in Tablet mode (Windows 10 only).
For the very first launch of an app the PreferredLaunchWindowingMode will always be Auto and the ApplicationView.PreferredLaunchViewSize will be determined by system policies. The API applies to the next launch of the app.
— … —
Esta propiedad solo tiene efecto cuando la aplicación se inicia en un dispositivo de escritorio que no está en modo tableta (solo Windows 10).
Para el primer lanzamiento de una aplicación, PreferredLaunchWindowingMode siempre será Auto y ApplicationView.PreferredLaunchViewSize estará determinado por las políticas del sistema. La API se aplica al próximo lanzamiento de la aplicación.
Es decir, que solo vale para UWP en escritorio (Desktop) y que la primera vez que se ejecute la aplicación usará el tamaño predeterminado, pero en las siguientes usará el tamaño que se asigne.
¿Queda claro?
Pues si no te ha quedado claro, prueba y lo comprenderás mejor 😉
Seguimos.
Si lo quieres hacer en el constructor de MainPage, este sería el código. En este ejemplo, se supone que la App (la de Xamarin, el proyecto con la funcionalidad) define un par de valores para el ancho y el alto y esos serán los valores que se asignarán a la aplicación (pero recuerda lo que se indica en la nota anterior, que la primera vez no tendrá efecto, si no, en las siguientes).
Veamos el código de ejemplo, con la definición de esas dos «propiedades» accedidas desde el proyecto de UWP.
Este sería el código de la clase App del proyecto principal de Xamarin.
Si te fijas en el código, he usado la definición del espacio de nombres al estilo de C# 10.0 (File-scoped namespace declaration) para poder hacer eso sin que te de error, debes indicar que usas la última versión de C#, esto lo haces en el proyecto poniendo lo de: <LangVersion>latest</LangVersion>.
namespace CambiarTamañoWindows.UWP
{
publicsealedpartialclassMainPage
{
publicMainPage()
{
this.InitializeComponent();
LoadApplication(new CambiarTamañoWindows.App());
// Asignar manualmente el tamaño según esté definido en la App del proyecto con la funcionalidad.double winWidth = CambiarTamañoWindows.App.WindowsWidth;
double winHeight = CambiarTamañoWindows.App.WindowsHeight;
ApplicationView.PreferredLaunchViewSize = newSize(winWidth, winHeight);
ApplicationView.PreferredLaunchWindowingMode = ApplicationViewWindowingMode.PreferredLaunchViewSize;
}
}
}
En este caso no he usado lo del «namespace file-scoped» en el proyecto de UWP porque es algo más lioso indicar la versión del C#. Pero… vale, te lo explico, pero antes te explico ese código.
El poner el cambio de la ventana después de LoadApplication es porque el parámetro que se le pasa es una llamada al constructor de la clase (es decir, se instancia esa clase) y si al instanciarla lees los valores de una base de datos, un fichero de configuración o lo que sea, debes usarlos solo después de haberlos asignados.
En este ejemplo los dos valores usados son «static», es decir, que no pertenecen a una instancia en particular, sino a toda la clase y a todas las instancias.
Si no te gusta trabajar con valores compartidos, puedes asignar esa instancia a una variable, usar esa variable en el método LoadApplication y después usar los valores desde ese objeto.
Para que no imagines nada, supón que la definición de esas dos propiedades está hecha de esta forma:
El código del constructor de MainPage sería este otreo:
namespace CambiarTamañoWindows.UWP
{
publicsealedpartialclassMainPage
{
publicMainPage()
{
this.InitializeComponent();
// Instanciamos la clase para que pueda asignar los valores.var laApp = new CambiarTamañoWindows.App();
LoadApplication(laApp);
// Asignar manualmente el tamaño según esté definido en la App del proyecto con la funcionalidad.double winWidth = laApp.WindowsWidth;
double winHeight = laApp.WindowsHeight;
ApplicationView.PreferredLaunchViewSize = newSize(winWidth, winHeight);
ApplicationView.PreferredLaunchWindowingMode = ApplicationViewWindowingMode.PreferredLaunchViewSize;
}
}
}
Después publicaré en github el proyecto para que te resulte más fácil probarlo y verlo al completo.
Cambiar la versión de C# en un proyecto Xamarin para Android, UWP (e incluso iOS, etc.)
Antes se podía hacer desde las propiedades del proyecto, en Build y seleccionando Avanzada, pero ya no, ya que dice que se selecciona automáticamente según la versión del «frameword», tal como puedes ver en esta captura:
Figura 1. Desde aquí ya no se puede indicar la versión de C#
La forma de hacerlo (estoy hablando de los proyectos de Android o de UWP, etc.) es la siguiente:
1- Elige el proyecto en el explorador de soluciones y pulsa en descargar (figura 2) 2- Una vez descargado, en ese mismo proyecto, selecciona Editar el archivo del proyecto (figura 3) 3- Añade <LangVersion>latest</LangVersion> después de la definición de PropertyGroup y lo guardas (figura 4). 4- Vuelve a cargar el proyecto (como en la figura 2, pero en vez de Unload será Reload). 5- Esto mismo lo puedes hacer en el de Android, etc.
Figura 2. Descargar el proyecto.Figura 3. Editar el proyecto.Figura 4. La versión a usar.
Y con esto y un bizcocho… ya casi son las 8…
En la figura 5 tienes la app funcionando con un tamaño de ventana de 650 x 700.
Figura 5. La app funcionando con un tamaño de 650×700
Ahora sí, esto es todo amigos… recuerda «invitarme» a un refresco virtual haciendo un donativo con Paypal 😉
Pues eso… actualmente utilizo el Visual Studio 2022 para los proyectos y anoche abrí uno que creé con el Visual Studio 2017 para .NET Framework, y vi que no me mostraba el contenido de los formularios, es decir, se mostraba como si no tuviesen controles dentro, así que… lo abrí el Visual Studio 2019 y… me mostró el aviso de que ya no tiene soporte (ver la captura) y que utilice el Visual Studio 2022… ¡ja! ¿Y qué hago con todos los proyectos que tengo para .NET Framework o para .NET 5?
Imagen 1. Visual Studio 2019 ya no tiene soporte
Así que… ¿qué hacemos con los proyectos creados para .NET Framework? (aparte de convertirlos para .NET 6.0 o posterior) o ¿qué hacemos con los proyectos para .NET 5 (y anteriores)? (aparte de convertirlos para .NET 6.0 o posterior)
Habrá que investigarlo… pero eso será en otra ocasión… que ahora tengo que empezar a currar… 😉
Pues eso… a pesar de los pesares, hay algo bueno al crear los proyectos para Visual C# desde Visual Studio que en Visual Basic (por aquello de que debemos estar protegidos de tocar donde no se debe, o eso supongo). Es algo muy simple, que introdujeron (creo) en Visual Studio 2005 y es lo de que el método Sub Main sea autogenerado por el Visual Studio y no te permita crear uno propio… o al menos eso me ha pasado con Visual Studio 2022 Version 17.2.0 Preview 1.0 y al final he tenido que crear el proyecto con C# para poder poner lo que me dé la gana en el método Main. En fin…
Y es que, aunque haya definido mi propio método Sub Main, el Visual Studio me daba error de compilación de que ya estaba definido (o estaba definido más de una vez), no recuerdo bien qué me dijo… pero corté por lo sano, descarté el proyecto de Visual Basic y lo creé con C# (para .NET 6.0 y Windows Desktop). Ese proyecto solo se encarga de llamar a otro que es el principal y por tanto, lo que necesitaba hacer es poder llamar al formulario adecuado para que se iniciara ahí la aplicación (el que tengo definido en otro proyecto diferente al de inicio). Esto es para poder tener proyectos de inicio diferentes para cada «cliente» que quiera usar mi aplicación. Y en esos proyectos asignar los parámetros personalizados de cada cliente. Todo esto último, solo para aclarar. 😉
Buscaré en la documentación si hay alguna forma de «pasar» de esta automatización (que, seguro que la hay, desde el propio Visual Studio, ya que creando el proyecto desde la línea de comandos con dotnet seguro que se puede). Y si la hay ya te lo contaré.
Nota: Antes de publicar esto, he probado a crear un proyecto con dotnet: He creado el directorio con el nombre del proyecto, he cambiado a ese directorio y he escrito esto en la línea de comandos: dotnet new winforms -lang VB -f net6.0 Y el proyecto se ha creado con el fichero Program.vb (con la definición de Sub Main) y un formulario Form1. Y ahora no dice nada el Visual Studio si lo cargo. Creo que el truco está en no crear los directorios ni asignaciones a My Project, etc. Lo probaré desde Visual Studio a ver…
Nota 2: Para solucionar esto en un proyecto creado desde Visual Studio. He seguido estos pasos: He comentado (también las puedes borrar) las secciones (cada una está dentro de <ItemGroup>) : <Compile Update="My Project\Application.Designer.vb"> y <None Update="My Project\Application.myapp">.
He comentado <MyType>WindowsForms</MyType> en el ItemGroup principal y de paso he eliminado la carpeta My Project. Y el fichero ApplicationEvents.vb. Esto realmente es lo que da el problema de que haya dos Sub Main.
Y finalmente he creado un fichero Program.vb con el código «personalizado» para Sub Main. En fin… complicaciones por intentar facilitar las cosas a los que preferimos Visual Basic.
Figura 1. Para quitar el error debes comentar MyType.
Nota 3: Aunque los proyectos de C# creados con Visual Studio también tienen código autogenerado… por ejemplo: ApplicationConfiguration.Initialize. Que lo que hace es lo que siempre (o casi) han hecho los métodos Main de las aplicaciones de Windows Forms: public static void Initialize() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.SetHighDpiMode(HighDpiMode.SystemAware); }
Pues eso… ¡peasso de título! y seguramente se me olvidará algo, por eso he puesto al final «y más». Pero la idea que tengo en mente hoy 24 de febrero de 2022 (con la guerra de Ucrania fresquita, aunque es algo que, lamentablemente no es tan fresca y que ya viene de largo), es explicarte en una serie de posts o entradas en el blog todo lo indicado en el título.
Sobre las expresiones lambda o métodos anónimos, he pensado en ponerte un par de videos que Héctor de León publicó a principios del año pasado en su canal de YouTube (HDELEON.NET), pero como el código que él utiliza es para C# .NET, te mostraré también el equivalente para VB.NET así, si eres de los que utilizan C# lo puedas entender mejor. Todo esto contando con que él me autorice mostrar su código de C# y el equivalente (en la medida de lo posible) de Visual Basic para punto NET. Actualización de las 17:33: Autorización que ya me ha dado 😉 ¡Gracias Héctor!
En cuanto a la programación asíncrona, te explicaré cómo crear tareas en otros hilos (principalmente con Task.Run) y el uso de async y await. Esas tareas se lanzarán o se procesarán también en el hilo principal de una aplicación de tipo Windows Forms (todo el código creado para .NET Core versiones 5 y/o 6) de forma que sepas qué cosas debes saber para el uso de controles, etc. entre hilos, cosa que solucionaré con InvokeRequired y la llamada a un delegado mediante Invoke. Por supuesto verás cómo definir delegados y cómo usarlos en el código. Con todo esto verás cómo acceder a parte del código que se ejecuta en el hilo principal (el creado para mostrar el formulario de inicio) desde otro hilo (o tarea).
También verás cómo cancelar esas tareas y cómo controlarlas, todo ellos mediante el uso de objetos CancellationTokenSource y CancellationToken (tanto en su forma normal y anulable). Y lo que debes hacer para comprobar en el código cuando se ha cancelado y cómo tratar esa cancelación, algo que harás pasándole a la tarea (Task) el objeto de tipo CancellationToken.
Y como algunas de las tareas (ya sean asíncronas o no) puede que tenga que acceder a objetos de una colección, verás algunos casos de cómo usar Parallel.For para repartir en tareas el proceso de comprobación del contenido de esa colección.
La mayoría de las cosas que se hará en el código de ejemplo requerirá de las expresiones lambda (o métodos anónimos) y su uso en expresiones de LINQ. Ya sabes: Where, Any, Select, etc.
Por último, parte del código de ejemplo lo haré usando un control DataGridView y en ese caso te mostraré cómo crearlo para usar una caché con los datos que manejará y todo ello usando el modo virtual de ese control, de esa forma, al menos en mi caso, he logrado agilizar (sobre todo acelerar) mostrar los datos en ese grid (o cuadrícula). La caché usada estará preparada para el tipo de datos que voy a usar en ese ejemplo.
Todo esto, lo iré publicando poco a poco, entre otras cosas, porque lo estoy usando en una aplicación que utiliza datos o tipos muy concretos. Si te sirve de algo, es una aplicación que estoy migrando de MS-DOS a Windows, y la mayoría de los datos los obtiene de ficheros de texto… ¡Sí, así de vieja es! 🙂 Pero haré que el código acceda a colecciones de datos más simples, que en principio no se obtendrá de una base de datos, pero no descarto que también haga alguna modificación para acceder a una base de datos, y si es remota, mejor. Pero eso ya lo veré en su momento.
Bueno, te dejo por ahora y ya iré poniendo cosas… seguramente pondré los enlaces en este mismo post, pero si se me olvida hacerlo… pues… ¡busca en fechas posteriores al 24 de febrero de 2022! 😉
Y ya sabes… si me quieres invitar a un cafelillo o refresco virtual, puedes usar el enlace de DONAR con PayPal. Gracias de antemano.
Pues eso… esto que te cuento ya lo publiqué en mi página de Facebook el pasado día 8 de noviembre (hoy es 23), pero «bicheando» en la WEB he visto que está expuesto este problema de forma más generalizada de lo que esperaba, y hasta gente de Microsoft han dicho que es bueno que esto se comparta para que haya menos gente que se encuentren con estos problemas (según parece esto lo han solucionado o lo van a solucionar en los instaladores de las nuevas versiones de Visual Studio 2022.
Pues eso… viendo las novedades de C# 10.0 me he topado con los detalles de la «novedad» Global using directives, dicho de esa forma parece algo «WOW!», y… es algo que siempre he querido que quitasen de forma predeterminada al crear un nuevo proyecto de Visual Basic para .NET: que haya importaciones implícitas de espacios de nombres al crear un nuevo proyecto.
Y eso es lo que es esa «nueva» característica de C# 10.0, crear definiciones «using» (ya que «Imports» es cosa de Visual Basic para .NET) de los espacios de nombres más habituales según el tipo de proyecto creado.
Que sí, que está muy bien, pero a mí nunca me ha gustado, de hecho, en la mayoría de los proyectos que creaba (sobre todo si era para compartirlo como parte de algún artículo), lo quitaba, con idea de así tener que escribir las importaciones de espacios de nombres en cada fichero (de código) de ese proyecto. Porque es la única forma de saber «a ciencia cierta» qué espacios de nombres se estaban usando en ese fichero de código.
Para que nos entendamos, a diferencia de C#, en Visual Basic el espacio de nombres System.Text nunca se importa de forma predeterminada, algo que sí ocurre en los proyectos de C#; por tanto, si quiero crear un nuevo objeto del tipo StringBuilder, o bien lo creo usando el nombre «completo» de la clase StringBuilder: System.Text.StringBuilder o bien declaro la importación del espacio de nombres System.Text y ya el compilador sabrá que StringBuilder está accesible (al revisar las clases contenidas en cada uno de los espacios de nombres que estén incluidos en las importaciones).
¡Eh! que no es una crítica, que me parece muy bien, y si ahora los del TEAM de C# lo están añadiendo como algo «predeterminado» será porque tampoco será tan malo, lo único que digo es que sigue siendo lo mismo que teníamos los «desarrollado-res» de Visual Basic desde hace ya casi 20 años… ¡NOVEDAD! WOW! 😉
Total, a lo que iba, que ya no hace falta seguir dando nuevas características a Visual Basic, porque al final C# será como era Visual Basic hace 20 años… eso sí, con (entre otras cosas) acabando la línea con un punto y coma.
Pero preferiría que Visual Basic evolucionara con las «nuevas características» realmente nuevas, para que a los que no nos gusta usar punto y coma para indicar que una instrucción ha finalizado o poner cosas entre llaves, etc., etc., y dejar de ver cómo C# evoluciona para hacer cosas que desde «siempre» ha hecho Visual Basic y, casi seguro, que era criticado por eso… Y si no me crees, échale un vistazo a las declaraciones sin tipos de variables (que, siempre al estilo de C#) en C# también lo añadieron en su día como novedad novedosa…
Pues eso… yo pensaba que era un BUG de Visual Studio 2022 y me dicen que es «by design».
El tema era que al seleccionar con ALT+SHIFT (para seleccionar un bloque de código en las posiciones que quieras) se quedaban varios cursores activos y al escribir se escribía en todas las posiciones en las que estaba el cursor. Y dicen que eso no es un BUG (sí lo es en la forma que ha ocurrido, ya que en Visual Studio 2019 no ocurre de esa forma), y el enlace que me han dado es el siguiente: Multi-caret selection.