2013-02-12 11 views
16

Sto usando WiX 3.5. Recentemente, il seguente errore WiX si è verificato frequentemente sul server di generazione:Errore LGHT0301: impossibile aprire il database

light.exe (,): errore LGHT0301: Impossibile aprire il database. Durante la convalida, questo accade più comunemente quando si tenta di aprire un database utilizzando una tabella codici non supportata o un file che non è un database di Windows Installer valido. Utilizzare una diversa tabella codici in Module/@ Codepage, Package/@ SummaryCodepage, Product/@ Codepage o WixLocalization/@ Codepage; o assicurarsi di fornire il percorso di un database di Windows Installer valido.

A quale "database" fa riferimento l'errore? (Nessuno dei file sorgente WiX è cambiato da molto tempo, quindi dubito che sia un problema di code page.)

Other people hanno segnalato che questo errore potrebbe essere causato da Trend Micro Office Scan, che è effettivamente installato sul costruire server. Ho chiesto all'amministratore di sistema di escludere le directory di compilazione dalla scansione, ma questo errore si verifica ancora. Come posso determinare se il virus è il colpevole? (L'errore non si verifica sempre, quindi se disattivo lo scanner antivirus e la successiva build riesce, non so ancora se l'errore è andato via definitivamente.)

+0

Vedere anche: http://stackoverflow.com/q/1064580/130352 –

risposta

13

Dopo aver studiato il codice sorgente WiX ed eseguito Process Monitor, ho scoperto che escludere le directory di costruzione dalla scansione antivirus è insufficiente.

Spiegazione: Quando light.exe è in esecuzione, crea il file MSI di destinazione in una directory temporanea. (Questo file è il database a cui fa riferimento il messaggio di errore LGHT0301.) Dopo che light.exe chiude il file MSI, ntrtscan.exe apre il file MSI per l'accesso in lettura e la condivisione di sola lettura. Successivamente, nel passaggio di convalida del database, light.exe tenta di riaprire il file MSI per l'accesso in lettura/scrittura e si verifica una violazione della condivisione.

Soluzione: Escludere la directory temporanea dalla scansione dei virus in tempo reale. Su Windows Server 2008, ad esempio, questa directory è C:\Users\«username»\AppData\Local\Temp.

+4

L'esclusione della directory temporanea dalla scansione antivirus è molto controproducente e un incubo dal punto di vista della sicurezza. Dopo tutto, la directory temp è solitamente scrivibile da qualsiasi processo. Inoltre, disabilitare lo scanner antivirus o modificarne le impostazioni potrebbe non essere facilmente possibile (ad esempio in un ambiente aziendale) – knittl

+1

Nota: è possibile utilizzare la variabile d'ambiente WIX_TEMP per specificare una directory temporanea personalizzata che si può essere più felici di escludere dal virus in tempo reale scansione. –

3

Questo è un problema comune con i processi di compilazione e antivirus. Lo scanner rileverà il nuovo pacchetto MSI e proverà a scansionarlo. Nel frattempo, il processo di compilazione tenta anche di convalidarlo eseguendo la suite Internal Consistency Evaluators (ICE) e si verifica un errore perché il database ha un mutex su di esso.

È sufficiente rimuovere la scansione antivirus dalle cartelle di output della build. In alternativa, disaccoppia la convalida dal comando Light in modo che la scansione antivirus rinunci all'handle MSI prima di eseguire la convalida ICE.

+1

Le cartelle di compilazione vengono già escluse dalla scansione (presumibilmente). –

+1

Buon punto: spesso l'AV esegue anche la scansione della cartella temporanea. Potrebbe valere la pena controllare i parametri che si passano al comando della luce. IIRC è possibile specificare la cartella che utilizza per gli artefatti temporanei. Non suggerirei blanket disattivare AV nella cartella temp in quanto potrebbe essere un rischio per la sicurezza. Potrebbe anche valere la pena di suggerire al team Wix di inserire un ciclo di tentativi nella fase di convalida per far fronte a situazioni in cui l'AV afferra il file per un breve periodo, il che non è affatto insolito. –

3

Ho avuto lo stesso problema che in realtà riguardava realmente le codepage e le impostazioni della lingua del mio sistema.

L'aggiunta della lingua di input inglese nelle impostazioni internazionali di Windows ha risolto il problema nell'installazione di Windows in tedesco.

2

La vera causa era Trend Micro real time scanning!

(Il seguente è soltanto per riferimento storico)

ho seguito @ Michael Liu risposta e risolto il problema


Ho avuto lo stesso problema.

Non mi riferisco a Codepage (o SummaryCodepage) in nessuno di questi tag, o in realtà in qualsiasi punto del WXS. Putting Codepage = "1252" non ha cambiato nulla.

Infine, ho provato ad aggiungere

encoding="utf-8" 

al tag XML che in precedenza aveva solo una versione = '1.0' attributo. Ciò risolve il problema, come descritto in "Failed to open the database" error. - SOLVED

1

Era anche il programma antivirus per me.

Un modo semplice per verificare se il problema è correlato al programma antivirus è disattivare la convalida ICE nelle impostazioni del progetto WiX (utilizzando la versione 3.7). Questo ha funzionato per me, ed ora è un ambiente permanente, poiché nella nostra azienda non è possibile modificare le impostazioni del software antivirus.

17

Il "Disabilitare la convalida ICE" ha funzionato per me, solo un'impostazione di Visual Studio 2012 in .Setup.

+3

Questo ha risolto lo stesso problema per me. Vai alle proprietà del progetto wix, Impostazioni dello strumento, quindi seleziona "Elimina convalida ICE" – Contisma

+0

Ho riscontrato questo problema anche con la versione 3.8. I passaggi precedenti hanno risolto il problema. – estebro

+0

per me non era sufficiente Sopprimere la convalida ICE solo per la configurazione attiva (debug), ho dovuto sopprimere la convalida ICE per tutte le configurazioni e questo ha fatto il trucco. – nlv

-1

Questo è l'errore più comune riscontrato durante l'utilizzo di WiX. La soluzione più semplice è andare su Proprietà del progetto → Impostazioni strumento → (Controllare) Sopprimere convalida ICE.