Estoy considerando migrar mi programa de CPU con hambre de memoria de Windows Forms a Blazor. Requiere muchos recursos y consume habitualmente > 4 GiB de memoria. Esto impide que se ejecute en un espacio de direcciones de 32 bits.
Sin embargo, los componentes de la GUI claramente pueden consumir un modelo de vista que oculta este gran consumo de memoria de la persona que llama. El código de Windows Forms ya está dividido en una parte de "motor" y una parte de "interfaz de usuario". El motor casi no tiene interfaz de usuario, pero está vinculado a la CPU.
En el programa Windows Forms, podría generar un proceso de 64 bits que hospedara el motor. Este proceso podría exponer un modelo de vista que el programa Windows Forms podría consumir a través de algún protocolo IPC adecuado. El programa Windows Forms podría ser entonces un cliente de 32 bits del proceso de 64 bits.
Quiero que la aplicación Blazor se sienta como una aplicación de escritorio tradicional: SPA y sin servidor. Idealmente, los usuarios visitarían una página web, descargarían la aplicación Blazor y luego comenzarían a usarla sin tener que comunicarse con algún "servidor de cómputo"; el motor debería estar ejecutándose en la máquina del usuario. Sin embargo, no estoy seguro de cómo puedo generar el proceso del motor de 64 bits desde el programa Blazor.
¿Cómo diseñaría esto para eludir las limitaciones de wasm (espacio de direcciones de 32 bits)?
No creo que esto califique como una respuesta, pero al menos podría brindarle algunos puntos de partida y tal vez alguien con más experiencia en esta área pueda complementar una mejor respuesta más adelante.
Comencemos con la suposición de que dividirá lo que tiene en UI y procesos de motor, ya que no hay forma de que las tecnologías basadas en web cumplan con sus requisitos de rendimiento de manera significativa. Así que se trata de "cómo hacer una interfaz de usuario de Blazor con capacidades nativas". Tenga en cuenta que esto tiene implicaciones para su distribución/implementación: espero que el usuario final tenga que instalar el proceso del motor (nativo) y la interfaz de usuario antes de iniciarlos.
Hay muchos SPA que en realidad se envían como aplicaciones nativas. Esto generalmente se hace a través de un shell contenedor que es una aplicación nativa que arranca y ejecuta el SPA, de manera similar a como lo haría un navegador web (esto también se conoce como una aplicación híbrida). Un desarrollador generalmente tiene la capacidad de modificar el shell, incluida la integración de capacidades nativas. Sin embargo, dado que estos proyectiles suelen ser multiplataforma, tienden a estar limitados en sus capacidades al mínimo común denominador. Sin embargo, hay excepciones: Xamarin.Forms, por ejemplo, le permite crear ensamblajes específicos de la plataforma con capacidades de bajo nivel.
Sin embargo, estos envoltorios suelen tener algunas peculiaridades con respecto a la UX o el rendimiento: si alguna vez usó Slack o Postman durante períodos más largos o los movió entre pantallas, sabrá a lo que me refiero. Estas aplicaciones simplemente no se sienten nativas y, a veces, terminan consumiendo el 100% de uno de los núcleos de su CPU hasta que las reinicia.
Creo que pasará mucho tiempo para que la integración del contenedor funcione correctamente, especialmente si desea que el contenedor haga IPC por usted.
En esa luz:
¿Cómo diseñaría esto para eludir las limitaciones de wasm (espacio de direcciones de 32 bits)?
yo no lo haría Hay una razón por la cual WinForms y WPF aún son compatibles.
Estas son algunas de las tecnologías de envoltura que tengo en mente si todavía está interesado en investigarlas (con el riesgo de que lo marquen como fuera de tema):
EDITAR: También hay un control BlazorWebView para WinForms y WPF desde .NET 6 Preview 3 , es posible que desee intentarlo. El concepto es similar a otros contenedores, pero al poder usarlo directamente desde WinForms, puede experimentar con el uso de Blazor y migrar su aplicación sin interrumpir la continuidad del negocio.