Recherche avancée

Sur d’autres sites (5540)

• ClickOnce Deployment looking for manifest signature on an nuget sourced .exe (FFMPEG #) as if it is a .csproj output. Deployment fails

  9 octobre 2019, par M_Ryce

  I have a C# forms app which utilizes the nuget package "FFMPEG Sharp" (Nuget Github) to generate video from a sequence of images.

  Unlike most nuget packages which simply pull in a .dll, installing FFMPEG Sharp places an "FFMPEG" folder into the .csproj root directory, in addition to bringing the appropriate .dll into "packages"

  Inside this folder are a few FFMPEG artifacts and a /bin folder containing FFMPEG executables. According to the project’s Github readme, this /bin directory needs to be specified in the app.config.

  From Github Readme example :

  <appsettings>
  
    <add key="ffmpegRoot" value="C:\ffmpeg\bin\"></add>
  
  </appsettings>`

  Adjusting the above to work in alignment with the default location Nuget placed the dependency artifacts :

  <appsettings>
  
    <add key="ffmpegRoot" value="..\..\FFMPEG\bin"></add>
  
  </appsettings>`

  Everything related to this dev effort has been smooth sailing, until I tried to utilize the existing Clickonce deployment for the app. The FFMPEG folder in my .csproj root wasn’t making it to the build output and therefore the application’s call to the FFMPEG .exe was throwing a null reference error. Understandable result, given that I had not set up any method of ensuring the FFMPEG artifacts made it to the build output with the same folder structure as existed on my local dev box.

  To counter this, I set a POST-build command to XCOPY....

  XCOPY "$(SolutionDir)MyApp\FFMPEG" "$(TargetDir)FFMPEG" /S /Y /I

  ...the nuget-provisioned FFMPEG artifacts into the build output root, and adjusted the config setting accordingly (see below)

  <appsettings>
  
    <add key="ffmpegRoot" value=".\FFMPEG\bin"></add>
  
  </appsettings>`

  This worked like a dream when building/running locally. The XCOPY succeeded in placing FFMPEG folder contents into the compiled solution’s Debug/Release bin and the updated config referenced them. No errors.

  Attempting to deploy with the .NET ClickOnce tool has created a rather befuddling error though.

  (Apologies for formatting ugliness below. I tried but didn’t succeed. The important parts are in bold)

  ERROR SUMMARY
  Below is a summary of the errors, details of these errors are listed later in the log.
  Activation of https://MySite/MyApp/Install/MyApp.application resulted in exception. Following failure messages were detected :
  + Downloading https://MySite/MyApp/Install/Application Files/MyApp/FFMPEG/bin/x86/ffmpeg.exe.deploy did not succeed.
  + The remote server returned an error : (404) Not Found.
  COMPONENT STORE TRANSACTION FAILURE SUMMARY
  No transaction error was detected.
  WARNINGS
  The manifest for this application does not have a signature. Signature validation will be ignored.
  * The manifest for this application does not have a signature. Signature validation will be ignored.
  OPERATION PROGRESS STATUS
  * [10/8/2019 2:03:37 PM] : Activation of https://MySite/MyApp/Install/MyApp.application has started.
  * [10/8/2019 2:03:37 PM] : Processing of deployment manifest has successfully completed.
  * [10/8/2019 2:03:37 PM] : Installation of the application has started.
  * [10/8/2019 2:03:37 PM] : Processing of application manifest has successfully completed.
  * [10/8/2019 2:03:40 PM] : Found compatible runtime version 4.0.30319.
  * [10/8/2019 2:03:40 PM] : Request of trust and detection of platform is complete.
  ERROR DETAILS
  Following errors were detected during this operation.
  * [10/8/2019 2:03:40 PM] System.Deployment.Application.DeploymentDownloadException (Unknown subtype)
  - Downloading https://MySite/MyApp/Install/Application Files/MyApp/FFMPEG/bin/x86/ffmpeg.exe.deploy did not succeed.*

  ...

  My interpretation of this is that the ClickOnce deployment is treating the Nuget-sourced .exe’s as if they are compiled code from this very project, and checking for a signed manifest.

  This ClickOnce deployment was not set up by me, and had not needed to account for such external artifacts existing in the output previously. I do not believe turning off signed assemblies is an option for me, for security reasons.

  Is there a way to make ClickOnce deployments ignore a specific .exe when checking for signed manifests ? I think the "correct" intended usage is for FFMPEG to be pre-installed on the machine as a stand-alone application, but This is not an option for me at this time. I will need FFMPEG to be brought in by the ClickOnce.

• Anomalie #4639 (Nouveau) : la constante _LEGACY_ACTIVE_IMG_DOC_EMB nécessite des modèles em...

  27 janvier 2021, par cy_altern -

  La constante _LEGACY_ACTIVE_IMG_DOC_EMB qui a été introduite par https://git.spip.net/spip/medias/commit/af1ba6cce5a5c8760e682e8b7fc872d076a87729 permet de faire l’appel direct aux modèle , et à la place de l’aiguillage selon le champs media qui le remplace en 3.3.
  ...sauf que le commit "fondateur" du nouveau système, https://git.spip.net/spip/medias/commit/fa13018a9ef63c633e78da253106867d6bac8a78, avait supprimé les fichiers modeles\doc.html, modeles\img.html et modeles\emb.html du plugin medias.
  Donc à moins d’apporter ces modèles via un plugin/squelette, l’activation de cette constante fait planter les raccourcis , et (ils ne sont tout simplement pas interprétés comme n’importe quel appel de modèle n’existant pas)

  Faut il restaurer les fichier doc.html, img.html et emb.html dans le plugin medias tant que cette constante existe (à priori au moins pour la version 3.3) ou faut il simplement le signaler dans la doc de la constante (avec éventuellement indication d’aller récupérer ces fichiers dans le dépot de la version 3.2) ?

• Evolution #4655 (Nouveau) : Permettre l’admin et l’édition de compagnons

  9 février 2021, par RastaPopoulos ♥

  Peut-être dans un sous-plugin, je ne sais pas, mais ça pourrait être fournit d’office.

  Avoir une interface humaine pour ajouter éditorialement des blocs d’aides dans différentes zones connues du plugin. L’idée étant que les "zones d’aide" ne sont pas toujours que les pipelines existants du privé (insere_milieu, etc).

  Donc il faudrait un concept "zone d’aide", sans avoir besoin de table pour ça, juste une fonction d’API et un pipeline éponyme pour en déclarer de nouvelles. Chaque zone doit avoir au moins un identifiant unique, et un label humain.

  Ces zones on va les insérer où on veut, soit en PHP avec une fonction (compagnon_zone(’identifiant’) par exemple) soit en squelette avec une balise (#COMPAGNON_ZONEidentifiant par exemple).

  Le plugin insérerait déjà des zones dans tous les pipelines connus de l’interface d’admin, comme actuellement, sauf que ça n’insérerait pas les compagnons directement mais la zone. La fonction actuelle "compagnonage" peut être rediriger pour utiliser le concept de zone d’aide car c’est très proche, et donc ne rien casser.

  Comme ces zones vont être déclarées explicitement avec un label humain ça va permettre de produire une interface d’admin éditoriale ("je veux ajouter une aide dans la zone Enfants des objets Rubriques", par ex). Une fois cette API de zone d’aide en place, on peut faire une interface avec une unique table éditoriale des compagnons et donc permettre d’en ajouter des nouveaux, sur telles pages, dans telles zones.