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).