Die Optionen für automatische Add-in-Updates sind in addin.def kodiert.Was hat diesen Wunsch geweckt? Mit der Veröffentlichung von JMP19 fiel mir die automatische Update-Funktion für Add-Ins auf, bei der JMP in einem Installationsordner nach Dateiaktualisierungen sucht. Die Implementierung war etwas umständlich und führte dazu, dass ein Teil unserer bestehenden Infrastruktur beschädigt wurde.
Welche Verbesserung würden Sie sich wünschen? Anstatt die Einstellungen unter „Ansichten > Add-Ins“ zu finden, sollten diese Optionen in der Datei „addin.def“ festgelegt werden, die jedes Add-In benötigt. Dies erleichtert die Verwaltung für Nutzer mit bestehender Infrastruktur und die schrittweise Implementierung der neuen JMP-Funktionen.
Warum ist diese Idee wichtig? Ich möchte diese Funktion weiterentwickeln. Es ist eine großartige Idee, aber die aktuelle Umsetzung kann leicht Probleme verursachen. In meiner derzeitigen Infrastruktur werden Updates anhand einer Masterliste geprüft, um zu erkennen, wann neue Versionen veröffentlicht werden. Die Funktion von JMP könnte dies teilweise überflüssig machen, benötigt aber noch etwas Feinschliff in der Implementierung. Einige Beispiele:
1. Das Add-in wurde vom korrekten Speicherort installiert, alles funktioniert einwandfrei. Später kann der Benutzer jedoch nicht mehr auf den Speicherort zugreifen und benötigt das Update. Ich leite ihm die jmpaddin-Datei weiter, damit er weiterarbeiten kann. Er zieht sie in JMP. Nun ist es möglich, dass sich der Installationsort im Download-Ordner befindet und er aufgrund dieser Änderung keine Update-Benachrichtigungen erhält. Durch die feste Angabe des korrekten Speicherorts in der def-Datei würde dies in jedem Fall funktionieren.
2. Add-Ins testen. Ähnlich wie bei Punkt 1: Wenn Sie einen Ordner für Ihre Tests haben, würde die Installation einer Testdatei den Installationsort in den Testordner ändern, und die Tester würden nicht über neue Produktionsversionen benachrichtigt. Je nach Dateibenennung werden sie möglicherweise auch nicht über neue Testversionen informiert, da Testversionen oft weitergegeben werden und die Versionsnummer im Dateinamen enthalten ist. Daher ist eine exakte Übereinstimmung des Dateinamens für die Update-Prüfungen nicht möglich.
In beiden Beispielen gibt es Aspekte der JMP-Implementierung, die nützlich sein könnten. Das Deployment-Team benötigt jedoch mehr Kontrolle darüber, wie Add-Ins für Updates markiert werden. Es gäbe wahrscheinlich weitere Beispiele, aber ich denke, dies genügt, um den Anstoß zu geben, die Update-Funktionen mit einer oder mehreren Variablen in die addin.def-Datei zu integrieren.
Danke!
Automatisierung und SkripterstellungBetreff: Auswahlmöglichkeiten für die automatische Add-In-Aktualisierung in addin.def kodifiziertDanke @nathan-clark für das Hervorheben der Probleme.
Wie ist die Geschwindigkeit des neuen Ansatzes im Vergleich zu „ Updates werden anhand einer Masterliste überprüft“ [wie im Add-In-Manager von @Justin_Chilton ]?
Betreff: Auswahlmöglichkeiten für die automatische Add-In-Aktualisierung in addin.def kodifiziertIch habe noch keine Geschwindigkeitstests durchgeführt, @hogi . Ich war hauptsächlich genervt, weil es bei meinen anderen Bereitstellungen Probleme verursacht hat. Ich vermute, die Geschwindigkeit wäre insgesamt höher, da JMP anscheinend nur auf eine neue Änderung eines Dateinamens prüft, anstatt mit den tatsächlichen Release-Daten der Builds zu vergleichen. Die Geschwindigkeit wird auch anhand des von JMP referenzierten Quellordners bestimmt.
Betreff: Optionen für automatische Add-in-Aktualisierungen in addin.def kodiert – Status geändert in: BestätigtVielen Dank, dass Sie sich die Zeit genommen haben, diese Anfrage zu teilen! Das ist ein tolles Feedback.
Betreff: In addin.def kodierte Optionen für automatische Add-in-Updates@nathan-clark Könnten Sie mir bitte die Dokumentation zu dieser Funktion und ihrer aktuellen Implementierung nennen? Ich verstehe die Implementierung nicht und konnte bisher keine Informationen dazu finden. Meinen Sie, dass JMP in dem Ordner sucht, aus dem der Benutzer die .jmpaddin-Datei ursprünglich geöffnet hat? Und wonach sucht JMP dort genau? Nach .jmpaddin-Dateien mit unterschiedlichen Dateinamen, aber derselben Add-in-ID in der Add-in-Definition? Oder nach der Add-in-Version in der Add-in-Definition? Oder nach Dateien mit demselben Dateinamen, aber geändertem Inhalt?
Betreff: In addin.def kodierte Optionen für automatische Add-in-Updates@hardner Ich bin mir nicht sicher, ob es dazu eine Dokumentation gibt. Meine Informationen stammen aus eigenen Tests und Beobachtungen sowie aus einem Support-Thread mit dem JMP-Support, als mir JMP 19 Fragen zur Update-Prüfung einiger meiner Add-Ins stellte.
Und ja, wenn Sie auf Ansicht > Add-Ins gehen, sollten Sie einige der von mir beschriebenen Elemente sehen können ... Sie sollten einen Abschnitt "Installationsquelle" sowie eine Dropdown-Liste "Aktualisieren" sehen ... wenn die Dropdown-Liste auf "Nach Updates suchen..." eingestellt ist, überwacht JMP den angegebenen Installationsordner, und es ist derzeit weder einfach noch möglich, dies zu ändern.
Wie JMP das genau überwacht, weiß ich nicht. Ich vermute, es wird eine gleichnamige .jmpaddin-Datei mit einem neueren Änderungsdatum verwendet? Aber ich könnte mich irren… Mir geht es hauptsächlich darum, einige dieser Komponenten zu steuern.
1. Ich habe bereits eine Infrastruktur für automatische Updates eingerichtet, daher soll JMP nichts überwachen. Die Einstellungen sollen vom Add-in selbst vorgenommen werden, ohne dass der Benutzer eine Wahlmöglichkeit hat.
2. Falls JMP die Überwachung übernehmen soll, möchte ich steuern können, wie JMP auf Aktualisierungen überwacht – beispielsweise durch die erzwungene Überwachung eines PROD-Ordners, sodass Benutzer Testdateien im .jmpaddin-Format hochladen können, ohne die Überwachung des PROD-Ordners zu beeinträchtigen.
Die Möglichkeit, dies über die addin.def-Datei zu kodifizieren, erscheint mir am sinnvollsten. Und falls ein Benutzer die Einstellungen wirklich überschreiben möchte, steht ihm die Option „Ansicht > Add-ins“ weiterhin zur Verfügung. Die aktuelle Implementierung, unabhängig von den zugrundeliegenden Regeln, beeinträchtigt jedoch Aspekte der Infrastruktur, die ich bereits für die Bereitstellung meiner Add-in-Suite entwickelt und verwendet habe.
Hilft das weiter?
Betreff: In addin.def kodierte Optionen für automatische Add-in-UpdatesDie automatische Aktivierung des Updates als Standardeinstellung (über eine Einstellung im Add-In) für Firmen-Add-Ins wird bahnbrechend sein!
So riskant, dass ein Benutzer vergisst, die Update-Funktion zu aktivieren – und dadurch mit einer alten Version festsitzt.
Eine Einstellung im Add-In ist deutlich besser als eine Einstellung in den lokalen Einstellungen. Wie kann man sicherstellen, dass 100 von 100 Benutzern die Funktion in den lokalen Einstellungen aktivieren?
Betreff: In addin.def kodierte Optionen für automatische Add-in-UpdatesAus unserer Erfahrung:
- Eine Datei mit demselben Namen wird überwacht
- Ein Update wird ausgelöst, wenn die Datei neu ist (auch wenn sich die Version nicht ändert).
Das Ändern anderer Dateien im Ordner hat keinen Einfluss auf den Mechanismus.
Vorteil im Vergleich zu UpdateCheck@AddInManager:
-Mehrere Add-Ins können synchron aktualisiert werden
- stiller Modus (obwohl ich mich nicht traue – schön zu wissen, welches Add-In aktualisiert wird)
Betreff: In addin.def kodierte Optionen für automatische Add-in-UpdatesUmgekehrt möchte ich, dass niemand die automatische Update-Funktion nutzt ... bis ich die anderen Aspekte der automatischen Aktualisierung vollständig unter Kontrolle habe.
Betreff: In addin.def kodierte Optionen für automatische Add-in-UpdatesDanke @nathan-clark und @hogi . Ich habe selbst eine Supportanfrage mit weiteren Details dazu gestellt. Ich stimme vollkommen zu, dass wir die Optionen für dieses Verhalten selbst bestimmen möchten.
Betreff: In addin.def kodierte Optionen für automatische Add-in-UpdatesWenn @nathan-clark also die Kontrolle zurückgewinnen möchte – indem er die manuelle Auswahl der Option unterbindet –, dann wäre eine „erzwungene Einstellung“ hilfreich.
Für meinen Fall genügt eine Auswahlmöglichkeit für die Standardeinstellung.
Wenn Add-Ins von SharePoint installiert und mit dem lokalen OneDrive synchronisiert werden, hat jeder Benutzer seinen eigenen Installationspfad.
Bei der Installation von einem Netzlaufwerk kann es von Vorteil sein, die automatische Aktualisierung so zu erzwingen, dass sie einen Standardpfad verwendet.
Betreff: In addin.def kodierte Optionen für automatische Add-in-UpdatesEinverstanden! Das ist mit ein Grund, warum ich es über die addin.def kodifizierbar machen möchte.
Was mir am meisten missfällt, ist die Änderung der Installationsquelle... wie bei deinem SharePoint @hogi , wenn eine Betaversion installiert wird, kann diese Quelle auf den Beta-Speicherort geändert werden... sodass sie nicht benachrichtigt würden, wenn eine neue Produktionsversion erstellt wird.
Solche Kleinigkeiten können unter Umständen bestehende Infrastrukturen/Verbindungen unterbrechen. Glücklicherweise glaube ich nicht, dass es besonders schwierig ist, mehrere Wege zu unterstützen.
Betreff: In addin.def kodierte Optionen für automatische Add-in-UpdatesWenn Sie die Datei von SharePoint heruntergeladen und anschließend aus Ihrem Download-Ordner geöffnet haben, wird die automatische Aktualisierung nicht durchgeführt, da sie davon ausgeht, dass der Installationsort der richtige ist. Der Kunde, mit dem ich zusammengearbeitet habe, hatte gehofft, dadurch einen externen Speicherort für die Update-Suche angeben zu können (seinen Unternehmensserver, SharePoint oder Ähnliches). Unabhängig davon, wie der Benutzer die Datei geöffnet hat, wäre dieser offizielle Speicherort beispielsweise in der Datei „addin.def“ als Ziel für die Update-Suche festgelegt worden. Und es würden keine Fehler auftreten, wenn dieser Speicherort nicht erreichbar wäre.
Betreff: In addin.def kodierte Optionen für automatische Add-in-Updates@hardner Du kannst deinen SharePoint synchronisieren, sodass der Ordner im Datei-Explorer wie ein lokaler Ordner angezeigt wird. In SharePoint gibt es oft eine Schaltfläche „Synchronisieren“, die den Ordner als lokalen Ordner synchronisiert, auf den du wie auf jeden anderen Ordner auf deinem Laufwerk zugreifen kannst.
Wenn sie die Datei direkt herunterladen, haben Sie Recht, dass dies ebenfalls den beabsichtigten Pfad unterbrechen kann.
Ich kann nicht mit Sicherheit sagen, ob das in allen Unternehmen so üblich ist, aber bei uns funktioniert es zumindest so. Es gibt möglicherweise auch eine Schaltfläche zum Erstellen einer OneDrive-Verknüpfung. Die bewirkt etwas Ähnliches, aber ich versuche, sie nicht zu benutzen (dazu später mehr).
Betreff: In addin.def kodierte Optionen für automatische Add-in-UpdatesVerstanden. Ich nutze Sync, bin aber auch Mitglied von SharePoint-Gruppen, die Sync nicht zulassen. Mein erster Gedanke wäre, so etwas herunterzuladen, nur um die Datei zu haben. Mir ging es aber hauptsächlich darum, dass diese Logik nur dann sinnvoll funktioniert, wenn Benutzer die .jmpaddin-Datei direkt von der offiziellen Seite öffnen, wo die Updates erscheinen. Mir ist nicht klar, wie man das erzwingen kann, anstatt die Datei herunterzuladen, per E-Mail zu versenden oder Ähnliches.
Betreff: In addin.def kodierte Optionen für automatische Add-in-UpdatesJa, das leuchtet ein. Ich denke, JMP verfolgt einen sehr sinnvollen Ansatz, der viele Probleme lösen kann. Mein Hauptgrund für die Änderung war, dass deren Implementierung meine eigene beeinträchtigt. Mit den richtigen Kontrollmechanismen könnte ich aber Teile meiner Infrastruktur möglicherweise durch die JMP-Implementierung ersetzen!
Betreff: In addin.def kodierte Optionen für automatische Add-in-UpdatesWie wäre es mit: AddinLoad.jsl ?
- Installationsdatei mit Firmenstandard überschreiben
- Falls Testverzeichnis: Eine Warnung anzeigen, dass eine Testversion installiert ist - dem Benutzer empfehlen, die offizielle Version von der offiziellen Quelle zu installieren
- wenn Installationsverzeichnis=Download -> Update deaktivieren
Wir müssen nur herausfinden, wo die Informationen gespeichert sind – und sie dann lesen, abrufen und ändern.
Betreff: In addin.def kodierte Optionen für automatische Add-in-UpdatesAddinload-Dateien können etwas knifflig sein, je nachdem, wie man sie verwendet und in welcher Reihenfolge JMP die Pakete installiert. Ich habe meine Systeme auf Bibliotheken aufgebaut, die nur bei Bedarf eingebunden werden … aber ich habe Addinload in der Vergangenheit auch schon verwendet. Mein System läuft ansonsten absolut stabil – bis JMP dem Benutzer wieder mehr Wahlmöglichkeiten gab.
Letztendlich werde ich die Produkte von JMP nutzen, wenn sie besser sind als meine eigenen, aber ich möchte nicht dazu gezwungen werden, die Produkte von JMP zu verwenden.
Betreff: In addin.def kodierte Optionen für automatische Add-in-UpdatesAh, hier ist es:
Open(
"$USER_APPDATA_ALL/addinRegistryV2.xml",
XML Settings(
Stack( 0 ),
Row( "/AddinReg/Addins/Addin/@id" ),
Col(
"/AddinReg/Addins/Addin/@id",
Column Name( "Addin.id" ),
Fill( "Use Once" ),
Type( "Character" ),
Format( {"Best", Use thousands separator( 0 ), 15} ),
Modeling Type( "Continuous" )
),
Col(
"/AddinReg/Addins/Addin/@timeStamp",
Column Name( "Addin.timeStamp" ),
Fill( "Use Once" ),
Type( "Numeric" ),
Format( {"Best", Use thousands separator( 0 ), 15} ),
Modeling Type( "Continuous" )
),
Col(
"/AddinReg/Addins/Addin/@installSource",
Column Name( "Addin.installSource" ),
Fill( "Use Once" ),
Type( "Numeric" ),
Format( {"Best", Use thousands separator( 0 ), 15} ),
Modeling Type( "Continuous" )
),
Col(
"/AddinReg/Addins/Addin/@installSourceTimeStamp",
Column Name( "Addin.installSourceTimeStamp" ),
Fill( "Use Once" ),
Type( "Numeric" ),
Format( {"Best", Use thousands separator( 0 ), 15} ),
Modeling Type( "Continuous" )
),
Col(
"/AddinReg/Addins/Addin/@autoUpdate",
Column Name( "Addin.autoUpdate" ),
Fill( "Use Once" ),
Type( "Numeric" ),
Format( {"Best", Use thousands separator( 0 ), 15} ),
Modeling Type( "Continuous" )
),
Col(
"/AddinReg/Addins/Addin/@updatePrompt",
Column Name( "Addin.updatePrompt" ),
Fill( "Use Once" ),
Type( "Character" ),
Format( {"Best", Use thousands separator( 0 ), 15} ),
Modeling Type( "Continuous" )
)
),
XML Wizard( 0 )
);
Entfernen Sie einfach das autoUpdate-Tag, und Ihre Kollegen müssen sich auf Ihre absolut zuverlässige Implementierung verlassen.
Vielleicht sollte man ein UpdateCheck-Add-In installieren, das die Einstellungen überprüft, sie anpasst und eine Fehlermeldung ausgibt, wenn die Einstellungen falsch sind.
Betreff: In addin.def kodierte Optionen für automatische Add-in-UpdatesOh, interessant, @hogi ! Das sieht definitiv nach einem Workaround aus, mit dem ich mal experimentieren sollte. 
Der JMP-Support hat mir auch etwas JSL-Code gegeben, mit dem ich die Einstellung bei Updates deaktivieren kann. Damit muss ich auch noch mal herumspielen.
Names Default To Here( 1 );
/* Installing Add-In:
Open( Add-In to open,
<CHECK for="" updates="">
, // "always" will check for updates at startup and while jmp is running
<UPDATE prompt="">
) // whether or not the add-in will silently update or prompt first */ Open( \\NetworkLocation\addins\test.jmpaddin, Check For Updates( "never" ), Update Prompt( 0 ) );
</UPDATE>
</CHECK>
Betreff: In addin.def kodierte Optionen für automatische Add-in-UpdatesAh, wunderbar!
Ideal zum Einrichten eines Batch-Skripts zum Aktualisieren des Updates:
Führen Sie alle Add-In-Installationsprogramme aus und passen Sie die Einstellungen an.
