2015-09-17 37 views
17

Abbiamo sviluppato un prodotto che è un addin VSTO standard (Word 2010 e Word 2013, solo x86). Per impostazione predefinita, quando è installato, viene installato per tutti gli utenti (ad esempio le voci del Registro di sistema addin vengono inserite in HKLM - HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Microsoft\Office\Word\Addins).MS Office Word VSTO "Load On Demand"

Quando il valore della chiave LoadBehavior reg è impostato 0x3 (cioè "Carica all'avvio"), il componente aggiuntivo funziona perfettamente soddisfacente, tuttavia quando abbiamo impostato il valore per LoadBehavior a 0x10 (cioè "Load on demand"), il componente aggiuntivo non funziona come ci si aspetterebbe:

causa di UAC (e che Word non viene eseguito elevato), il valore di LoadBehavior in HKLM non è cambiato 0x10-0x9 ma invece è sovrascritto con la creazione di una chiave LoadBehavior (con valore 0x9) nell'hive HKCU.

Purtroppo, abbiamo trovato che questo valore sottoposto a override HKCU non viene preso in considerazione senza la chiave manifesto è presente nel alveare HKCU con LoadBehavior). Ulteriori informazioni su questo thread corrispondenti https://social.msdn.microsoft.com/Forums/vstudio/en-US/3776734b-333e-423b-9c08-7c7a441c3e94/load-behavior-and-word-addin?forum=vsto

Il rimedio 'ovvio' per questo problema è quello di scrivere il Manifest in HKCU per ciascun utente (così come in HKLM) al momento dell'installazione O quando ogni utente esegue il modulo aggiuntivo la prima volta. Ci sono tuttavia alcuni gravi inconvenienti con questo approccio:

  • disinstallare il componente aggiuntivo richiede la rimozione ogni utente valori HKCU per impedire agli utenti verificano problemi di carico (questo non è raccomandato e pone altre questioni/complicazioni, come la necessità di utilizzare l'installazione Attivo - Remove registry keys under HKCU on a per machine installation).
  • Gli utenti che hanno questi valori nel proprio hive HKCU (in roaming), riscontrano problemi durante l'accesso a una macchina nello stesso dominio in cui non è installato il nostro addin.

Si tratta di un bug che il manifesto non è ottenuta dal HKLM dove il LoadBehavior è impostato in modo appropriato in HKCU? Penso che questo problema potrebbe essere risolto se lo LoadBehavior in HKLM potrebbe essere sovrascritto in HKCU senza che sia necessario sovrascrivere il valore Manifest.

Qualcuno conosce un modo per superare questo problema?

risposta

0

Il motivo che si sta utilizzando Load On Demand più probabile è quello di migliorare le prestazioni di avvio, come descritto nella MSDN. Tuttavia, il carico su richiesta viene fornito con un'intera serie di problemi (nessun supporto per lo stato dell'interfaccia della barra multifunzione dinamica, problemi con la distribuzione di HKLM, ecc.).

Come già detto, non ci sono problemi con Caricamento all'avvio. Pertanto, il metodo consigliato per caricare il componente aggiuntivo consiste nell'utilizzare un valore LoadBehavior di 0x3.

Se si riscontrano problemi con le prestazioni di caricamento dei componenti aggiuntivi, una soluzione potrebbe essere l'utilizzo di un componente aggiuntivo leggero che viene sempre caricato all'avvio e quindi questo componente aggiuntivo funge da caricatore per l'aggiunta effettiva -in.

+0

Grazie per questo @ dirk-vollmar. Giusto per chiarire, la ragione principale alla base del voler usare 'LoadOnDemand' non è perché abbiamo un lento add-on, ma è perché abbiamo molti e molti add-in che sono tutti business-critical. Questi competono per risorse e spesso "conflitto" ed errore se caricati contemporaneamente. Purtroppo dobbiamo vivere in un mondo in cui non possiamo cambiare i componenti aggiuntivi degli altri, e quando ne hai tanti come la maggior parte dei nostri clienti, non puoi chiedere a tutti di migliorare il loro carico. – RoKa

1

In mancanza dell'impostazione del controllo dell'account utente su "Mai notifica", non conosco un modo per superare direttamente i problemi.Tuttavia, suggerirò una soluzione alternativa che ti consenta essenzialmente di caricare su richiesta.

Suggerisco di modificare gli add-in di VSTO LoadBehavior a 0x0 (Non scaricato - Non caricare automaticamente) e quindi utilizzare un comando VBA in un modello caricato automaticamente per controllare quando viene caricato il componente aggiuntivo. Ecco uno schema dei passaggi da intraprendere:

  1. In Visual Studio verificare che la barra multifunzione nell'addin sia codificata come un file XML (non creato utilizzando Visual Designer). All'interno di questo nastro definisci uno spazio dei nomi personalizzato.
  2. Creazione di un modello di Word (.dotm). Utilizzando lo Custom UI Editor for Microsoft Office incorpora all'interno di questo modello l'XML per una scheda a nastro etichettata e posizionata come quella del componente aggiuntivo. Definisci lo spazio dei nomi nell'XML uguale a quello nel codice XML di Visual Studio in modo che condividano lo stesso spazio dei nomi. Inoltre, definisci un pulsante che caricherà il tuo componente aggiuntivo (e forse anche altre funzioni all'interno del tuo componente aggiuntivo).
  3. All'interno del vostro modello di scrivere un sub per caricare il tuo scaricato 0x0 componente aggiuntivo utilizzando questo codice:

    Application.COMAddIns(ProgID).Connect = True

    ProgID è o l'IDEX oggetto del vostro ProgID o il nome effettivo del ProgID tra virgolette.

  4. All'interno del modello scrivere una richiamata che chiamerà il codice per caricare l'addin dal pulsante.

  5. Posizionare il modello nella directory STARTUP di Word. Per Word 2010 che è C:\Program Files (x86)\Microsoft Office\Office14\STARTUP

Quello che vogliamo che accada è che quando viene lanciato Parola Addin VSTO è installato ma non è stato caricato. Il modello che hai creato viene caricato automaticamente dalla directory STARTUP e posiziona la scheda della barra multifunzione per la tua applicazione in Word. Perché l'addin VSTO non è caricato, quei controlli non sono attualmente visibili. Tuttavia, dopo aver implementato i passaggi precedenti, quando si fa clic sul pulsante dall'XML del modello, il componente aggiuntivo caricherà i suoi controlli sullo stesso nastro perché condividono uno spazio dei nomi. E quando Word viene chiuso e riavviato, viene reimpostato sul componente aggiuntivo VSTO che viene installato ma non caricato. questo

Facendo un ulteriore passo avanti, se si voleva evitare l'ulteriore click di caricare i controlli Addin VSTO, si potrebbe plausibilmente ricreare XML del componente aggiuntivo VSTO all'interno del modello e avere ogni codice di chiamata di controllo per caricare il componente aggiuntivo VSTO, nascondere il i controlli della barra multifunzione del modello ed eseguono le funzionalità del tuo addin. In questo modo avresti il ​​nastro segnaposto fornito dall'XML del modello e il componente aggiuntivo che carica e esegue azioni su richiesta.

Problemi correlati