connessione del servizio WCF con terze parti DLL con IIS

sto lavorando con Windows 7, VS2010, SqlServer 2008.connessione del servizio WCF con terze parti DLL con IIS

La mia applicazione prende i dati formano una DLL di terze parti (che prende i dati da un altro processo che deve essere eseguito in sfondo) e elabora i dati e li invia su un servizio WCF al front-end.

L'applicazione è terminata e fa ciò che dovrebbe fare. Ora quando voglio distribuirlo ed eseguirlo in IIS. Sto affrontando uno strano problema. L'applicazione recupera i dati da una DLL quando la eseguo in IIS e fallisce e dà un errore durante la connessione alla DLL.

Retrieving the COM class factory for component with CLSID {FCEC6861-5866-4F9E9A09-7CC868C30A8B} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).

Dopo alcune ricerche ho scoperto andando a servizio dei componenti e all'interno DCOM config posso cambiare la sicurezza della DLL a tutti. L'errore si è fermato.

Ma ora non ottengo l'errore ma non ottengo i dati come quando il software che fornisce i dati è chiuso. Ma funziona bene con il mio server di sviluppo ASP.net.

Inoltre ho scoperto che quando eseguo Visual Studio in modalità amministratore, devo eseguire anche il software di dati di terze parti in modalità amministrativa.

Il riferimento dll non viene copiato automaticamente nella cartella bin, viene inserito nella cartella obj e l'ho copiato manualmente ma non funziona.

fonte

2011-10-26 thewayman

Non sono sicuro che dare l'accesso a tutti sia la soluzione più saggia qui. Quello che dovresti probabilmente fare è determinare quale account è in esecuzione il sito in IIS, e quindi dare anche il permesso per la DLL di terze parti a quell'account. A seconda della natura dell'app, è possibile anche prendere in considerazione la creazione di un account di servizio, assegnarlo a un pool di app che esegue l'app e fornire le autorizzazioni appropriate. – Tim

Grazie. so che non è una buona idea, sappi che voglio scoprire il problema. provando tutto e niente :) – thewayman

Quello che penso succede è che il componente COM è in esecuzione nello stesso contesto del chiamante e ha bisogno di autorizzazioni elevate per eseguire il suo lavoro.

Quindi:

VS in modalità amministratore, COM in modalità amministratore, funziona perché entrambi stanno avendo i permessi di larghezza di sistema per svolgere il loro lavoro.
IIS in esecuzione sotto l'account del pool di app (non sono sicuro quale), COM si troverà anche sotto quell'account, ma non è un amministratore, quindi le autorizzazioni troppo basse per eseguire il lavoro correttamente.

Il mio suggerimento per la risoluzione dei problemi sarebbe di fare in modo che il pool di applicazioni IIS in esecuzione sia cambiato con l'amministratore locale. Se funziona, ripristinare i diritti di accesso sul DCOM ai valori predefiniti (prima di passare a tutti) e riprovare. Si potrebbe anche provare a eseguire il pool di app sotto l'account di sistema locale per vedere cosa succede. Se funziona ancora, hai confermato che questo comportamento è il problema.

fonte

2011-11-06 20:58:34 kroonwijk

Il pool di applicazioni IIS in cui è in esecuzione la tua app è stato modificato come amministratore locale come faccio? – thewayman

Leggete http://technet.microsoft.com/en-us/library/cc771170(WS.10).aspx – kroonwijk

Quindi Punti -VS e COM possono funzionare entrambi in modalità utente. ma uno in utente e un altro in amministratore non funzionano. Quando eseguo l'app come amministratore – thewayman

connessione del servizio WCF con terze parti DLL con IIS

risposta

Problemi correlati