Nuestro propio Main en WPF

Como sabemos el método Main es el punto de entrada de un programa en C#. Cuando creamos una nueva aplicación de WinForms por defecto crea un fichero Program.cs en el cual encontramos dicho método y donde podemos realizar las tareas que creamos oportunas antes de iniciar la aplicación. Sin embargo, en WPF en lugar de dicho fichero encontramos un fichero App.xaml (ApplicationDefinition) en el cual no encontraremos el método Main, siendo el compilador el que generará dicho método, y únicamente podemos indicar la ventana que se mostrará al iniciar la aplicación.

En nuestro caso necesitamos realizar una serie de tareas antes de iniciar la aplicación, como son la búsqueda de la base de datos y mostrar una ventana Splash mientras se realiza dicha búsqueda y la carga de la aplicación. De esta forma necesitábamos crear nuestro propio método Main, para ello crearemos nuestra clase App que heredará de System.Windows.Application y en la cual definiremos el método Main, indicandole al compilador que use el nuevo fichero App.cs como objeto de inicio y eliminaremos el fichero App.xaml (si tenemos algún recurso definido en el fichero debemos moverlo a un nuevo fichero y añadirlo a los diccionarios de la aplicación en el Main).

En la siguiente web podemos ver los pasos a seguir para mostrar una ventana Splash antes de cargar la aplicación.

Primer contacto serio con Linq

He hecho mi primer proyectito con Linq to SQL, se trata de una pasarela de sincronización entre 2 sistemas: nuestra BD en SQL y un AS/400 que nos genera archivos de texto. Os cuento mi experiencia, la principal conclusión es que no me ofrece un buen rendimiento (y eso que he conseguido mejorarlo varias veces, pero aún así no es suficiente) y por eso quiero compartirlo por si hay algo que se pueda hacer de otra forma (no con SqlCommand, eso ya sé hacerlo, he probado en este proyecto con Linq por aprender y porque realmente el rendimiento no es necesario, se ejecuta durante la noche).
Veréis: para la prueba de fuego he hecho una carga de 125.000 artículos que se escribían en 2 tablas. Pues bien, la principal pregunta es: ¿se hace todo con un DataContext abierto, o voy cerrando y abriendo para cada artículo? Es que mantengo en memoria muchas entidades para acelerar las búsquedas, y si establezco una de esas entidades en un nuevo artículo, como se guarda en otro DataContext distinto a donde se cargó, pues dice que no es aplicable. Así que sólo me funciona manteniendo abierto el mismo DataContext desde el principio. Lo cual no sería problemático si no fuera porque el rendimiento se va degradando conforme más se usa el DataContext, parece que al llevar el seguimiento de tantas entidades se ralentiza. Comienza a actualizar a más de 30 artículos por segundo, y cuando lleva 40.000 artículos escritos va por 3 artículos por segundo, lo cual es de pena (cada artículo son 2 INSERT).
La otra cuestión es acerca de los INSERT que genera Linq: es especialmente lento porque el comando Insert espera a recibir la respuesta de la identidad del nuevo registro insertado. ¿Hay alguna forma en Linq de generar nuevas entidades pero no recuperar su Id? Esto lo veo mucho más improbable, y no he encontrado nada al respecto, sólo críticas a la falta de procesos por lote en Linq pero no referentes a esta cuestión puntual (sino a UPDATEs de múltiples registros).

Mientras no resolvamos la cuestión de si uno o varios DataContext, y en el segundo caso de cómo usar una entidad de un DataContext sobre otro, no veo viable utilizar Linq para otros proyectos de mayor envergadura. Supongo que todas estas cuestiones serán equivalentes en Linq to Entities, que es lo que realmente aspiramos a utilizar.

Publicar una aplicación WPF

Hay un problema en algunos casos al publicar una aplicación hecha en WPF. Dice que no puede generar la aplicación porque no encuentra los archivos xxx.g.i.cs (lo dice una vez por cada XAML). He encontrado que es un error reconocido por Microsoft, y que se solucionará en SP1, pero mientras no puedo generar la versión de la Pasarela Domlez con Motorwin. Ya la original me costó mucho generarla, por fallos como este, pero tras mucho probar lo conseguí.
En los comentarios a ese informe de fallo, alguien cuenta en español que matando las instancias del proyecto que estés compilando (en el taskmgr) sí tira, pero a mí no me sirve.
Tras muchas pruebas con otros más de los rodeos que dan en la página, sólo consigo que me publique en modo Debug, no en Release. Y además esa publicación no tira, porque al ejecutar da un error que depurando descubro que es: No se encuentra App.xaml. Así que como tampoco soy capaz de instalar la Beta de VS 2008 SP1, paso del tema y me genero un RAR autoextraíble de toda la vida.

Tengo otro problema y es que una aplicación instalada desde una publicación a) no sé en qué carpeta está; b) no puedo machacarla porque el manifiesto de la aplicación no será válido para los nuevos archivos; y c) no sé cómo generar una actualización, así que tengo que desinstalar y volver a instalar siempre. Este problema con el RAR también me lo quito. Así que en esas estamos, tecnología punta ClickOnce... RAR.