none
Errori con regsvr32 in windows 7 64 Bit RRS feed

  • Domanda

  • Sto portando una applicazione da 32 a 64 in windows7, scritta in C# e ho una serie di problemi infiniti, ma quello più curioso e che non riesco a registrare in sistema a 64 gli ocx che nella versione a 32 erano OK.

     

    Ossia con regsvr32 mi vengono caricati perfettamente ma quando entro nel programma mi da un errore di Exception con la nota che non sono registrati.

     

    Qualcuno ha avuto il mio stesso problema  ??

     

    venerdì 28 ottobre 2011 12:32

Risposte

  • Ciao Alea, se il tuo componente AcitveX è di tipo in-process (OCX o DLL) ed è compilato a 32 bit allora non potrà mai essere caricato in un proesso a 64 bit. Per lo stesso motivo regsv32.exe a 64 bit (ignora in questo caso il 32 nel nome del file) non riesce a registrare il tuo componente nella parte di registry a 64 bit (per questo lo vedi tra le istanze COM a 32 bit e basta). Infatti dovresti incorrere in questo: http://support.microsoft.com/kb/282747

    Per aggirare problemi di questo tipo durante il porting di applicazioni da 32 a 64 bit per componenti non disponibili a 64 bit oppure non disponibili in sorgente per una ricompilazione/porting a 64 bit, quello che puoi fare è:

    1. Ospitare le componenti a 32 bit in un processo esterno e raggiungere le stesse con COM. Al cosiddetto down-thunking (64 bit -> 32 bit) ci pensa il sistema operativo (grazie al suo RPC nativo/di sistema = COM). L'invocazione, passando da in-process a out-of-process sarà un po' più lenta e quindi valuta bene questo aspetto. Se la componente ex-in-process fa molto I/O potresti non accorgerti della differenza. Se invece viene utilizzata in modo molto "chatty" allora potresti incorrere in penalità di performance non trascurabili. Spesso però grazie alla maggior scalabilità, con molta concorrenza potresti scoprire che è comunque la strada più giusta da seguire.

    2. Windows mette a disposizione processi surrogati per attività di questo tipo di prim'ordine: COM+. Durante un tour MSDN di qualche anno fa in cui mostravamo le N tecniche per portare codice VB, ASP e C++ da 32 a 64 bit con implicazioni del genere in cui ti sei imbattuta tu abbiamo mostrato come con una semplice registrazione in COM+ problematiche di questo tipo si azzeravano senza scrivere una sola riga di codice. Per il resto valgono tutte le considerazione del punto 1. In più COM+ ti mette a disposizione un "arsenale" di feature di tutto rispetto per fare pooling ecc che potresti pensare di sfruttare a tuo vantaggio grazie alla maggiore memoria, maggiore disponibilità del sistema a 64 bit ecc (insomma molto + scale-up).

    Attenzione: se la componente utilizza come parametri, tipi di dati non "ortodossi", ad esempio passa puntatori, callback a funzioni o cose del genere (purtroppo ci siamo imbattuti anche in questo :() allora 1 e 2 non sono applicabili perchè il puntatore verrebbe passato in uno spazio di memoria diverso (il processo surrogato out-of-process) e quindi non punterebbe allo stesso "oggetto". Otterresti un antipaticissimo errore di protezione appena questo verrebbe dereferenziato nel processo e componente chiamato.

    Per qualsiasi problema o delucidazione fatti sentire se il tuo problema è ancora attuale. Se vuoi possiamo organizzare (tempo permettendo) una brevissima conf-call con video per mostrarti tutte le implicazioni del caso e le tecniche che si possono utilizzare.

    Giuseppe Dimauro
    Microsoft MSDN Regional Director, Italia
    www.codearchitects.com
    www.vbmigration.com
     


    =dg=

    • Proposto come risposta Luigi BrunoMVP martedì 20 marzo 2012 10:22
    • Contrassegnato come risposta Irina Turcu mercoledì 18 aprile 2012 10:13
    martedì 20 marzo 2012 08:30

Tutte le risposte

  • Ciao Alea65 e benvenuto sul forum MSDN per i sviluppatori!

    Potresti per cortesia farci sapere se hai risolto il tuo scenario seguendo i suggerimenti di Luigi, oppure avresti ancora bisogno di qualche dritta?

     

    Grazie in anticipo per la tua risposta,


    Irina Turcu

    Questo contenuto è distribuito “as is” e non implica alcuna responsabilità da parte di Microsoft. L'azienda offre questo servizio gratuitamente, allo scopo di aiutare gli utenti e farli aumentare la conoscenza sui prodotti e le tecnologie Microsoft.

    LinkedIn

    martedì 1 novembre 2011 12:55
  • Ciao Irina e ciao Luigi, prima di tutto grazie per l'interessamento ma purtroppo non non si è risolto l'inghippo.

    Per essere più preciso il mio OCX è stato sviluppato in C 6.0 e deriva da un tool-kit per la gestione di driver Ethernet, su stazioni di controllo, e l a procedura di installazione  sia regsvr32 che altro da sempre in ambiente windows 64 un risultato positivo sulla sua registrazione ma poi quando vado ad usarlo all'interno del mio applicativo ne fuoriesce il messaggio ""Interfaccia non registrata. (Eccezione da HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))"} System.Exception {System.Runtime.InteropServices.COMException}".

    Le sto provando tutte ma ormai sto perdendo le speranze.

     

     

     

     

     


    Alea
    mercoledì 2 novembre 2011 10:31
  • Ciao Alea,

    credo che la tua applicazione abbia ragione nel dire che la libreria non è registata!

    Mi spiego meglio.

    Per rendere disponibile un oggetto COM a 32 bit ad un processo che gira a 64 bit, devi utilizzare C:\Windows\SysWOW64\regsvr32.exe e non C:\Windows\System32\regsvr32.exe

    In alternativa puoi modificare la configurazione del progetto c# "forzando" l'esecuzione del tuo programma a 32 bit (togli la configurazione AnyPlatform e usa x86).

    Antonello.

     


    Antonello
    venerdì 11 novembre 2011 00:01
  • Ciao Antonello 

    La registrazione tramite SysWow64 la avevo già provata ma con scarsi risultati, mentre l'applicativo gira bene in modalità 32BIT ho ricompilato in modalità x86 e tutto sembra OK.

     

    Una curiosità uso Visual studio 2010 e compilando con Windows XP Ok l'applicazione gira pure in modalità 64 con Windows7 Pro, mentre lo stesso compilatore e ovviamente lo stesso progetto non si compila sotto Windows7.

     

    Ho controllato e uso lo stesse FrameWork e le stesse impostazioni, mistero comunque per ora gira e il primo problema è risolto, ho bisogno di due macchine una per compilare e l'altra per provarlo ma non si può avere tutto.

     

    Una ultima curiosità è normale che il debuger non mi sia permesso lavorando in Windows 7-64 il compilatore è registrato e sempre quello originale Microsoft. ??

     

    Un grazie a  tutti per l'aiuto.

     

     


    Alea
    mercoledì 16 novembre 2011 07:55
  • ciao Antonello

    il problema è ancora attuale?

    hai pensato al fatto che il problema possa essere che compilando a 32bit ti trovi su windows7 con un sistema a 64 ed un'applicazione a 64bit che di fatto non vede la tua dll a 32??

    ricorda che in Windows Vista/7 è necessario avviare Visual Studio come amministratore per avere tutte le funzionalità attive

    a presto


    Antonio Esposito [MCT, MCPD, MCTS, MCP]
    dotnetlombardia.org | blog | web | @tonyexpo
    Italy
     

    lunedì 19 marzo 2012 23:37
    Postatore
  • Ciao Alea, se il tuo componente AcitveX è di tipo in-process (OCX o DLL) ed è compilato a 32 bit allora non potrà mai essere caricato in un proesso a 64 bit. Per lo stesso motivo regsv32.exe a 64 bit (ignora in questo caso il 32 nel nome del file) non riesce a registrare il tuo componente nella parte di registry a 64 bit (per questo lo vedi tra le istanze COM a 32 bit e basta). Infatti dovresti incorrere in questo: http://support.microsoft.com/kb/282747

    Per aggirare problemi di questo tipo durante il porting di applicazioni da 32 a 64 bit per componenti non disponibili a 64 bit oppure non disponibili in sorgente per una ricompilazione/porting a 64 bit, quello che puoi fare è:

    1. Ospitare le componenti a 32 bit in un processo esterno e raggiungere le stesse con COM. Al cosiddetto down-thunking (64 bit -> 32 bit) ci pensa il sistema operativo (grazie al suo RPC nativo/di sistema = COM). L'invocazione, passando da in-process a out-of-process sarà un po' più lenta e quindi valuta bene questo aspetto. Se la componente ex-in-process fa molto I/O potresti non accorgerti della differenza. Se invece viene utilizzata in modo molto "chatty" allora potresti incorrere in penalità di performance non trascurabili. Spesso però grazie alla maggior scalabilità, con molta concorrenza potresti scoprire che è comunque la strada più giusta da seguire.

    2. Windows mette a disposizione processi surrogati per attività di questo tipo di prim'ordine: COM+. Durante un tour MSDN di qualche anno fa in cui mostravamo le N tecniche per portare codice VB, ASP e C++ da 32 a 64 bit con implicazioni del genere in cui ti sei imbattuta tu abbiamo mostrato come con una semplice registrazione in COM+ problematiche di questo tipo si azzeravano senza scrivere una sola riga di codice. Per il resto valgono tutte le considerazione del punto 1. In più COM+ ti mette a disposizione un "arsenale" di feature di tutto rispetto per fare pooling ecc che potresti pensare di sfruttare a tuo vantaggio grazie alla maggiore memoria, maggiore disponibilità del sistema a 64 bit ecc (insomma molto + scale-up).

    Attenzione: se la componente utilizza come parametri, tipi di dati non "ortodossi", ad esempio passa puntatori, callback a funzioni o cose del genere (purtroppo ci siamo imbattuti anche in questo :() allora 1 e 2 non sono applicabili perchè il puntatore verrebbe passato in uno spazio di memoria diverso (il processo surrogato out-of-process) e quindi non punterebbe allo stesso "oggetto". Otterresti un antipaticissimo errore di protezione appena questo verrebbe dereferenziato nel processo e componente chiamato.

    Per qualsiasi problema o delucidazione fatti sentire se il tuo problema è ancora attuale. Se vuoi possiamo organizzare (tempo permettendo) una brevissima conf-call con video per mostrarti tutte le implicazioni del caso e le tecniche che si possono utilizzare.

    Giuseppe Dimauro
    Microsoft MSDN Regional Director, Italia
    www.codearchitects.com
    www.vbmigration.com
     


    =dg=

    • Proposto come risposta Luigi BrunoMVP martedì 20 marzo 2012 10:22
    • Contrassegnato come risposta Irina Turcu mercoledì 18 aprile 2012 10:13
    martedì 20 marzo 2012 08:30