2010-11-02 4 views
9

Ho creato un progetto di installazione di Visual Studio con Visual Studio 2008 (SP1) per un componente aggiuntivo di Office 2007. L'installazione copia solo i file in una posizione per utente (LocalAppData) e scrive solo le impostazioni del registro in HKEY_CURRENT_USER, ma quando viene eseguito su Windows 7, l'MSI richiede le credenziali di amministratore appena prima che inizi a copiare i file. Il programma di installazione funziona perfettamente con un account utente limitato su Windows XP, ma in Windows 7 i privilegi di amministratore sembrano essere obbligatori.Come eseguire un lavoro di installazione per utenti limitati (non amministratori)

Non sono stato in grado di trovare un modo per rimuovere il requisito di elevazione dell'amministratore e voglio sapere come fare questo o se non è possibile farlo con un progetto di installazione di Visual Studio.

** AGGIORNAMENTO 2010-11-03 (ulteriori dettagli) **

Quando genera il progetto di installazione di Visual Studio, si crea un setup.exe e un file MSI. Visual Studio 2008 non sembra darmi un controllo adeguato su come viene creato setup.exe o come viene creato il file MSI. Il file setup.exe sembra essere solo per l'installazione di eventuali prerequisiti che potrebbero richiedere il mio AddIn di Office 2007. È il file MSI, che può essere eseguito in modo indipendente, che installa l'AddIn di Office 2007 effettivo. Voglio imparare come contrassegnare il file MSI in modo che non chieda i privilegi di amministratore, perché il mio file MSI copia solo i file in una posizione per utente e scrive solo le impostazioni del registro in HKEY_CURRENT_USER.

+1

Perché questa domanda è contrassegnata come "lua"? – lhf

+0

L'ho taggato come LUA perché pensavo che LUA significasse "Account utente limitato" –

risposta

11

credo di aver trovato la risposta in questa pagina:

http://blogs.msdn.com/b/rflaming/archive/2006/09/30/778690.aspx


Come faccio a costruire un pacchetto utente standard?

Questo richiede un po 'di lavoro per fare installare un pacchetto solo alle posizioni che un utente standard ha permesso. Alcuni dei requisiti sono

  1. utilizzare un tipo di 51 un'azione personalizzata nella InstallUISequence per sempre disinserire l'ALLUSERS (l'opzione per utente)

  2. file deve essere scritto solo per le cartelle che l'utente standard ha accesso a Supponendo che ALLUSERS sia sempre impostato sull'impostazione per utente, è possibile utilizzare le proprietà della cartella redirectable ma non ProgramFilesFolder in quanto non reindirizza per utente.

  3. Installare l'app in un percorso in LocalAppDataFolder.

  4. Tutte le impostazioni del Registro di sistema devono essere scritte in HKCU, che è 1 nella colonna Root della tabella del Registro di sistema.

  5. Flip bit 3 della proprietà di conteggio parole nel flusso di informazioni di riepilogo per segnalare che non è richiesta alcuna richiesta di credenziali.

  6. Se si dispone di un bootstrapper (in genere denominato setup.exe), manifestare requestExecutionLevel per eseguire asInvoker.

  7. Passaggio Convalida ICE in quanto gli ICE dispongono di controlli per la miscelazione errata dello stato per utente e per macchina.

  8. Provare entrambi da un account utente standard e da un prompt dei comandi con privilegi elevati per confermare il comportamento.

  9. Fornire documentazione degli utenti sulla natura specifica dell'utente del pacchetto poiché questo è atipico nelle installazioni delle applicazioni di oggi.


NOTA: Passo 5 può essere fatto utilizzando Orca, strumento di editing di Microsoft MSI. Aprire il file MSI in Orca, selezionare Visualizza -> Informazioni di riepilogo ... quindi selezionare la casella di controllo "Conformità UAC".

NOTA 2: il passaggio 5 può essere eseguito utilizzando il file di script di esempio WiSumInf.vbs incluso in Microsoft SDK: C: \ Programmi \ Microsoft SDK \ Windows \ v7.0 \ Samples \ sysmgmt \ msi \ scripts \ WiSumInf.vbs

NOTA n. 3: il passaggio 1 sembra essere gestito in un progetto passo di Visual Studio facendo clic con il tasto destro del mouse sul progetto di installazione, selezionando Visualizza -> Interfaccia utente, ottenendo le proprietà per "Installa/Avvia/Cartella di installazione "pagina e impostazione" InstallAllUsersVisible "su False.

NOTA # 4: Un altro modo per eseguire il passaggio 5, utilizzare lo strumento Msiinfo.exe incluso nel "SDK componenti di Windows Installer per Windows sviluppatori" http://msdn.microsoft.com/en-us/library/aa370310(VS.85).aspx

Aggiunta alla nota # 4: Assumendo che si sta utilizzando nomi di file lunghi e supporti compressi (comportamento predefinito per un MSI) il comando PostBuildEvent sarebbe qualcosa di simile:

"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\MsiInfo.exe" "$(BuiltOuputPath)" /w 10 

noti che si dovrà cambiare il percorso del MsiInfo per abbinare quello che io t ha nel tuo sistema.

+1

Ottima risposta, ha funzionato come un fascino! –

0

Se il programma di installazione è denominato "setup.exe" o "install.exe", Win7 "sa" è un programma di installazione e lo eseguirà in modalità "richiede l'amministratore" per impostazione predefinita. Dovrai aggiungere un manifest al tuo programma di installazione (interno o esterno) per dirgli di eseguire con autorizzazioni minori.

Un manifest di esempio da MSDN è illustrato di seguito. Modificare il valore 'IsUserAdmin' al nome del programma, quindi salvarlo come 'nomeEseguo .exe.manifest' nella cartella a fianco dell'exe.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
    <assemblyIdentity version="1.0.0.0" 
    processorArchitecture="X86" 
    name="IsUserAdmin" 
    type="win32"/> 
    <description>Description of your application</description> 
    <!-- Identify the application security requirements. --> 
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> 
    <security> 
     <requestedPrivileges> 
     <requestedExecutionLevel 
      level="asInvoker" 
      uiAccess="false"/> 
     </requestedPrivileges> 
     </security> 
    </trustInfo> 
</assembly> 

Vedere l'articolo here per ulteriori informazioni.

+0

Non sono sicuro di poter applicare quella soluzione al mio scenario. Quando costruisco il mio progetto di installazione di Visual Studio, crea un file setup.exe e un file MSI. Inoltre, Visual Studio 2008 non sembra darmi un controllo adeguato sul modo in cui questi file vengono creati. Lo scopo di setup.exe sembra essere solo installare eventuali prerequisiti che potrebbero dover essere installati. Ma è il file MSI che esegue l'effettiva installazione dei file e delle chiavi di registro per il mio AddIn. Ho bisogno di capire cosa fare nel file MSI per farlo funzionare. –