Le scelte di aggiornamento automatico dei componenti aggiuntivi sono codificate in addin.defCosa mi ha ispirato a fare questa richiesta di lista dei desideri? Con JMP19 in azione, ho notato una funzionalità di aggiornamento automatico per i componenti aggiuntivi, grazie alla quale JMP cerca gli aggiornamenti ai file da una "cartella di installazione". L'implementazione era un po' "macchinosa" e ha finito per compromettere una serie di infrastrutture che avevamo già creato.
Qual è il miglioramento che vorresti vedere? Invece di limitarti alle impostazioni di Viste > Componenti aggiuntivi, queste scelte dovrebbero essere codificate nel file addin.def di cui hanno bisogno tutti i componenti aggiuntivi. Questo renderà più semplice la gestione per chi ha infrastrutture esistenti e renderà più semplice implementare iterativamente parte delle interessanti funzionalità di JMP.
Perché questa idea è importante? Voglio portare questa funzionalità a un livello superiore. È un'idea fantastica, ma la sua attuale implementazione può facilmente causare problemi ad altri. Nella mia infrastruttura attuale, gli aggiornamenti vengono confrontati con un elenco principale per sapere quando vengono rilasciate nuove versioni. La funzionalità di JMP potrebbe rendere superflue alcune di queste funzionalità, ma necessita di maggiore precisione nella sua struttura. Alcuni esempi:
1. Componente aggiuntivo installato dalla posizione corretta, tutto a posto... in seguito l'utente non riesce ad accedere alla posizione e ha bisogno dell'aggiornamento. Inoltro loro il file jmpaddin in modo che possano continuare. Lo trascinano in JMP... ora è possibile che la sorgente di installazione sia ora la cartella dei download e che non ricevano notifiche sugli aggiornamenti a causa di questa modifica... codificare la sorgente corretta nel file def consentirebbe il funzionamento a prescindere.
2. Componenti aggiuntivi di test. Simile al punto 1, se si dispone di una cartella in cui si trovano i test, l'installazione di un file di test modificherebbe la posizione di installazione nella posizione di test e non verrebbe notificata quando viene rilasciata una nuova versione di produzione. E a seconda di come vengono denominati i file, potrebbero essere notificati o meno delle nuove versioni di test... poiché le versioni di test vengono spesso "consegnate", includono la versione nel nome del file... quindi non è possibile una corrispondenza esatta del nome del file per i controlli degli aggiornamenti.
In entrambi gli esempi, ci sono aspetti di ciò che JMP ha fatto che potrebbero essere utili, ma il team di distribuzione ha bisogno di un maggiore controllo su come i propri componenti aggiuntivi devono essere contrassegnati per l'aggiornamento. Probabilmente ci sono altri esempi, ma penso che questo sia sufficiente per far partire il processo affinché il "materiale" di aggiornamento faccia parte del file addin.def con una o più variabili.
Grazie!
Automazione e scriptingRe: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defGrazie @nathan-clark per aver evidenziato i problemi.
Qual è la velocità del nuovo approccio rispetto a " gli aggiornamenti vengono controllati in base a un elenco principale" [come in Gestore componenti aggiuntivi di @Justin_Chilton ]?
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defNon ho ancora eseguito alcun test di velocità, @hogi . Principalmente mi ha infastidito perché ha creato problemi con le mie altre distribuzioni. Immagino che la velocità sarebbe complessivamente maggiore, dato che JMP sembra controllare solo una nuova modifica del nome di un file, rispetto al mio confronto con le date di rilascio effettive della build. La velocità sarà determinata anche in base alla cartella "sorgente" a cui JMP fa riferimento.
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.def - Stato modificato in: RiconosciutoGrazie per aver dedicato del tempo a condividere questa richiesta! È un feedback fantastico.
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.def@nathan-clark Puoi indicare la documentazione di questa funzionalità e dell'implementazione attuale? Non capisco cosa comporti questa implementazione e non riesco a trovare nulla al riguardo. Stai dicendo che JMP cerca nella cartella da cui l'utente ha originariamente aperto il file .jmpaddin? E poi cosa cerca lì? File .jmpaddin con nomi diversi ma lo stesso ID del componente aggiuntivo nella definizione del componente aggiuntivo? O qualcosa sulla versione del componente aggiuntivo nella definizione del componente aggiuntivo? O lo stesso nome file ma qualche modifica al contenuto?
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.def@hardner Non sono sicuro che ci sia documentazione. Le informazioni in mio possesso provengono dai miei test/osservazioni personali e da una discussione con il supporto JMP, quando ho notato che JMP 19 mi poneva domande sulla verifica degli aggiornamenti per alcuni dei miei componenti aggiuntivi.
E sì, se vai su Visualizza > Componenti aggiuntivi dovresti riuscire a vedere alcuni degli elementi che ho descritto... dovresti vedere una sezione "Sorgente di installazione" e un elenco a discesa "Aggiorna"... se l'elenco a discesa è impostato su "controlla aggiornamenti..." JMP monitorerà la cartella di installazione elencata e non è facile o possibile modificarla, per ora.
Non sono sicuro di come JMP esegua il monitoraggio. Immagino che sia un file .jmpaddin con lo stesso nome ma con una data di modifica più recente? Ma potrei sbagliarmi... La mia richiesta principale riguarda il controllo di alcuni componenti.
1. Ho già un'infrastruttura di aggiornamento automatico, quindi non voglio che JMP monitori nulla e voglio che venga impostata dal componente aggiuntivo stesso, senza possibilità di scelta da parte dell'utente.
2. Se voglio che JMP esegua il monitoraggio, voglio controllare come JMP monitora gli aggiornamenti, ad esempio forzando il monitoraggio di una cartella PROD che consentirebbe all'utente di caricare file di test .jmpaddin senza influire sul monitoraggio PROD
Poter codificare questo tramite addin.def mi sembra la soluzione più sensata... e se un utente vuole davvero sovrascrivere, View>Addins è ancora disponibile. Tuttavia, l'implementazione attuale, qualunque siano le regole di base, compromette aspetti dell'infrastruttura che ho già creato e utilizzato per la distribuzione della mia suite di addin.
Ti è d'aiuto?
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defL'attivazione automatica dell'aggiornamento per impostazione predefinita (tramite un'impostazione nell'AddIn) per gli AddIn aziendali sarà una vera svolta!
È così rischioso che un utente si dimentichi di attivare la funzione di aggiornamento e si ritrovi quindi bloccato con una vecchia versione.
Un'impostazione nell'Add-In è molto meglio di un'impostazione nelle preferenze locali. Come garantire che 100 utenti su 100 attivino la funzionalità nelle preferenze locali.
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defDalla nostra esperienza:
- viene monitorato un file con lo stesso nome
- l'aggiornamento viene attivato quando il file è nuovo (anche se la versione non è stata modificata)
- la modifica di altri file nella cartella non influisce sul meccanismo
vantaggio rispetto a UpdateCheck@AddInManager:
-più componenti aggiuntivi possono essere aggiornati in modo sincrono
- modalità silenziosa (anche se non oso - è bello sapere quale componente aggiuntivo viene aggiornato)
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defAl contrario, voglio che 0 persone utilizzino la funzione di aggiornamento automatico... finché non avrò il controllo al 100% sugli altri aspetti dell'aggiornamento automatico 
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defGrazie @nathan-clark e @hogi . Ho inviato una richiesta di supporto per maggiori dettagli su questo argomento. Sono pienamente d'accordo nel voler avere il controllo sulle opzioni relative a questo comportamento.
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defquindi, se @nathan-clark vuole riprendere il controllo, impedendo la selezione manuale dell'opzione, allora "forzare le impostazioni" sarà utile.
Nel mio caso, sarà sufficiente selezionare alcune impostazioni predefinite.
Quando i componenti aggiuntivi vengono installati da SharePoint e sincronizzati con OneDrive locale, ogni utente avrà il proprio percorso di installazione.
Se installato da un'unità di rete, potrebbe essere utile forzare l'aggiornamento automatico a seguire un percorso predefinito.
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defSono d'accordo! Questo è uno dei motivi per cui voglio che sia codificabile tramite addin.def.
La cosa che più non mi piace è la modifica della sorgente di installazione... come il tuo sharepoint @hogi , se installi una versione beta, quella sorgente potrebbe essere modificata nella posizione beta... quindi non verrebbero avvisati se fosse stato creato un nuovo PROD.
Piccole cose come queste possono potenzialmente danneggiare le infrastrutture/i percorsi esistenti Per fortuna non credo che l'"ascensore" sia molto difficile da supportare su più percorsi.
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defSe hai scaricato il file da SharePoint e poi lo hai aperto da "Download", l'aggiornamento automatico non farà nulla, supponendo che stia utilizzando quella posizione come percorso di installazione. Credo che il cliente con cui lavoravo sperasse che questo avrebbe consentito di specificare una posizione remota per verificare la presenza di un aggiornamento (il loro server aziendale, SharePoint o altro) - indipendentemente da come l'utente avesse aperto il file, questa posizione ufficiale sarebbe stata specificata, ad esempio in addin.def, come posizione in cui cercare gli aggiornamenti. E non ci sarebbero stati errori se quella posizione fosse stata inaccessibile.
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.def@hardner, puoi sincronizzare SharePoint in modo che la cartella venga visualizzata in Esplora risorse come se fosse locale. All'interno di una cartella SharePoint è spesso presente un pulsante "Sincronizza" che la converte in una cartella locale sincronizzata, accessibile come qualsiasi altra cartella sul tuo disco.
Se scaricano il file direttamente, hai ragione, anche questo può "interrompere" il percorso previsto.
Non posso dire con certezza al 100% che questo sia un comportamento comune tra le aziende, ma almeno la nostra funziona così... potrebbe esserci anche un pulsante "crea collegamento a OneDrive". Funziona in modo simile, ma cerco di non usarlo (ne parlerò in un altro articolo).
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defCapito. Uso Sync, ma appartengo anche a SharePoint che non mi consente di sincronizzare. Il mio primo pensiero sarebbe quello di scaricare qualcosa del genere solo per "avere" il file. In ogni caso, volevo principalmente notare che questa logica funziona solo se gli utenti aprono il file .jmpaddin direttamente dalla posizione ufficiale in cui appariranno gli aggiornamenti e non mi è chiaro se si possa imporre loro di farlo anziché scaricarlo, inviarlo via email o altro.
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defSì, ha senso. Penso che ciò che JMP sta cercando di fare abbia molto senso e possa semplificare molti grattacapi... La mia più grande spinta al cambiamento è stata quando la loro implementazione ha interrotto la mia Ma con i giusti controlli potrei essere in grado di deprecare parte della mia infrastruttura per affidarmi all'implementazione di JMP!
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defche ne dici di: AddinLoad.jsl ?
- sovrascrivere il file di installazione in Standard aziendale
- se Test-Dir: mostra un avviso che è installata una versione di prova - suggerisce all'utente di installare la versione ufficiale dalla fonte ufficiale
- se InstallationDir=Download -> disabilita l'aggiornamento
Dobbiamo solo scoprire dove sono salvate le informazioni, quindi leggerle, recuperarle e modificarle.
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defI file addinload possono essere difficili da usare, a seconda di come li si utilizza e dell'ordine in cui JMP installa i programmi. Ho creato il mio sistema basandomi su librerie che sono incluse quando mi servono... ma in passato ho usato addinload. Per il resto, il mio sistema è solido come una roccia, finché JMP non ha restituito le opzioni all'utente 
In conclusione, per me, userò le cose di JMP se sono migliori delle mie, ma non voglio essere costretto a usare cose di JMP.
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defah, eccolo qui:
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 )
);
Basta rimuovere il tag autoUpdate e i tuoi colleghi dovranno affidarsi alla tua solida implementazione.
Forse dovresti installare un componente aggiuntivo UpdateCheck che controlli le impostazioni, le modifichi e segnali se sono errate.
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defOh, interessante @hogi ! Sembra proprio una soluzione alternativa con cui dovrei fare qualche prova Il supporto JMP mi ha anche fornito del JSL che potrei usare per disattivare l'impostazione quando si verificano aggiornamenti, e devo provarci anch'io.
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>
Re: Scelte di aggiornamento automatico dei componenti aggiuntivi codificate in addin.defah, meraviglioso!
Ideale per impostare uno script batch per aggiornare l'aggiornamento:
eseguire tutti gli installatori di componenti aggiuntivi e regolare le impostazioni.
