Per part de la configuració del mosquitto caldrà establir aquests valors al conf, els certificats estarien al mateix directori però el correcte seria posar-los en un altre:
Es requereix afegir una interconnexió amb una aplicació que els seus mètodes públics estan en un format antic, en aquest cas, ActiveX.
Aquests controls són exclusivament en 32-bits.
La aplicació que els ha de consumir és multi-plataforma i no pot ser condicionada per connectar-se amb aquesta aplicació, el qual és accessòria.
Possibles solucions d’arquitectura:
Crear diferents compilacions (no desitjable, complica el codi i obliga a publicar-ne diferents versions)
Crear una aplicació en servei del sistema operatiu (malauradament en aquest cas queda descartat ja que el control de ActiveX ens obliga a tenir accés al System.Windows.Forms)
Crear una aplicació instanciada des la aplicació principal
Al final he triat la última solució a la qual ens trobem doncs que la intercomunicació entre els processos la podem fer amb diferents mètodes12:
Utilitzar un fitxer d’entrada i un altre de sortida entre les aplicacions: potser un mètode eficaç i ràpid, fàcil de transmetre a través de parametrització i lectura de sortida estàndard.
Pipes/Canonades(anònims i anomenats)34: ens obligaria a establir un protocol degut a les poques dimensions dels missatges capaços de ser retransmesos per canonades/pipes.
Sockets (a través de WCF o Remoting5): complica el codi i ens obliga a establir protocol de funcionament.
Per la consola: és el mètode més a pic i pala però el que podem garantir una prova de concepte. El problema és que a major quantitat de dades més lent es torna, mètode lent ja de per si.
Memòria compartida67: aquesta es pot fer a través de fitxers mapejats en memòria, el qual també ens facilita la interconnexió i a més a més amb mutex podem establir un nivell de seguretat bastant alta de orde de processament.
La transmissió de dades es pot fer per classes (després fer marshalling) o per serialització (tant JSON com XML). He triat JSON perquè és la que menys ocuparà i en part, perquè si es fan registres d’entrada i sortida ja disposem d’eines per llegir-los i analitzar-los.
Un punt clau són els mutex. Encara que l’ordre de execució dels processos és seqüencial, això ens donarà possibilitat de que evitar que es llegeixin posicions abans de que s’hagin acabat de escriure.
Tant els fitxers com els pipes serà essencial què siguin creats per la aplicació principal: això ens donarà l’avantatge de controlar quan la memòria ha de ser creada i netejada.
La crida a la aplicació que contindrà els accessos a ActiveX es fa mitjançant System.Diagnostics8 aquesta API ens permet a través de StartInfo de aportar paràmetres a la aplicació (propietat arguments), com redirigir el input i output estàndard (propietat StandardOutput.ReadToEnd() per a obtenir el string de sortida).
I use NSwag also to generate the API Clients in VS (using the VS extension REST API Code Generator for VS).
My approach was to override SendAsync using DelegatingHandler. In this handle is possible to catch the response of SendAsync and then manage to refresh the token. I found a kind of implementation in the docs, but in this answer you can find the source of my approach to implement the handle:
I used a global/static variable to store the refresh tokens and other authentication data required.
In my case I had no chance to use dependency injection (DI) as the answer I linked before. Then, before using the service, I create a HttpClient and I assign the CustomDelegatingHandler to this HttpClient.
Les crides fins ara es feien des PInvoke a la llibreria de ghostscript de windows. Amb linux no farà falta en si descarregar-afegir la llibreria. També el PInvoke amb linux hi ha unes particularitats 1.
Directoris
Els directoris també canvien. Per a tenir una generació de noms de directoris neta sense directoris a mà, hem de revisar les carpetes especials que fem ús a la API de Path de NET2
Llibreries d’imatges
El fet de no comptar amb System.Drawing dificulta molts dels procesaments de imatge dels que es feia us d’aquesta llibreria de sistema. Cal utilitzar alternatives com Imagesharp o Skiasharp3
Dependències terceres
L’entorn és amb docker/debian per a poder fer el PInvoke a Ghostscript correctament cal instal·lar totes les llibreries següents des el dockerfile:
Selecciona Azure Active Directory i registres d’aplicacions a l’esquerra
Selecciona New registration
Introdueix un nom per a la aplicació i selecciona Register
Aneu a Permisos de l’API per concedir permisos a la aplicació, seleccioneu “Add a permission”, tria SharePoint, Delegated permissions i selecciona AllSites.Manage
Selecciona Concedir consentiment de l’administrador per consentir els permisos sol·licitats per l’aplicació
Si no hem seguit el pas 8 ens pot ocórrer que el usuari tingui que donar manualment accés a l’aplicació. Si ho fem, el exemple no està preparat per a fer-ho (no fa prompt de la pàgina sol·licitant-lo).
El usuari no és vàlid, o no te renovada la contrasenya, o està inactiu: aquestes gestions no seràn possibles ja que no tenim previst fer prompt de la pàgina de AD per fer canvi de contrasenya, etc.
Després cal personalitzar la classe AuthenticationManager que donen al exemple ja que està pensada per a Net Core o superiors, però no NET Framework cal fer un seguit d’adaptacions. Aquí fetes, res del altre món:
Fent servir part del codi d’exemple amb de desplegament de una aplicació NET6 WPF com aquest luncher he fet una llibreria tipificant les constants del desplegament que més fem servir així com simular el update silenciós de clickonce que en realitat no és un altre cosa que instal·lar per enrere i apagar la aplicació un cop està instal·lada la nova versió (el restart de NET Framework ara no funcionarà):
La preferència de les aplicacions amb NET6 és preferible utilitzar la comanda dotnet msbuild el problema més important en aquest cas és que clickonce es fonamenta bàsicament en NET Framework 3.5 així que haurem d’utilitzar MSBuild.
Com passava ja amb MSBuild i clickonce, els perfils o les ordes de publicació es comporten diferent amb Visual Studio que executades des MSBuild. A més a més, tenim el handicap de que les eines de msbuildtasks de loresoft no acaben de funcionar bé.
Per aquesta raó utilitzant els perfils de publicació (Propierties/PublicationProfiles/ClickOnceProfile.pubxml) amb paràmetres postcompilació afegirem la tasca què:
Separi els fitxers de desplegament (setup.exe, xxxxx.application, launcher.exe i carpeta ApplicationFiles)
Copi un template del index.html per personalitzar-lo (de nou MSBuild no és capaç de fer-lo posant-hi el WebPageFileName a true)
4. Provar que funciona correctament arrancant-lo des CMD
.\mosquitto.exe -c .\mosquitto.conf -v
Per a comprovar la connexió i el estat del servidor de MQTT podem fer servir un client bàsic de MQTT fet amb HTML. Com per configuració hem activat els websockets no ens farà falta res més que executar aquesta pàgina des el navegador (les llibreries Javascript és consulten a un CDN):
Amb el codi anterior i els paràmetres de connexió que al ser per web sockets haurem de especificar protocol (wb) i port a l’adreça tal així: wb://localhost:9001. El resultat de enviar un missatge a la subscripció que triem hauria de ser aquesta:
5.- Feta la prova amb la configuració parem el terminal, farem que sigui un servei i així no necessitem tenir una sessió activa. Per a fer-lo cal executar el mosquito.exe install. En el cas que ja estigui instal·lat és recomanable desinstal·lar-lo executant mosquito.exe uninstall . Per a revisar el estat del servei ho podem fer des Control+Alt+Spr, pestanya Serveis i veure tots els serveis buscant el servei Mosquitto Broker:
Si el servei no funcionés reviseu que a les variables de entorn el MOSQUITTO_DIR és el de instal·lació.
Amb això ja podem iniciar les proves de MQTT amb aquest i altres entorns, recordant que els següents passos amb el servidor haurien de ser dotar-lo de seguretat (autenticació i encriptació del canal).
Tenir l’aplicació ben enroutada no significa què després el enllaç amigable sigui funcional al 100%: si no es dins del context de la aplicació React. Per a aquesta raó s’haurà de dir al servidor HTTP que redireccioni qualsevol petició diferent a la ruta de index a la mateixa què el propi index que executa la aplicació.
En alguns casos com pot ser ASP MVC amb l’extensió de SPA, el propi host IIS o autohost de NET Core es configura per redireccionar aquestes peticions. En NodeJS passa exactament el mateix al desplegar-lo com una aplicació React Client.
En altres entorns no es ben bé així, com pot ser Apache o Azure Static Web Apps.
Apache:
Caldrà crear un fitxer .htaccess pròpi a la carpeta on es situï el build i dins caldrà especificar les següents línies