Come richiamare una DLL a 32 bit da un'applicazione a 64 bit?
Alessandro Pulvirenti
debbo utilizzare una DLL che � di terze parti, quindi non la posso
modificare.
Questa DLL � a 32 bit mentre la mia applicazione � a 64 bit (C# .NET 3.5
sp1).
E' possibile farlo? e come?
Grazie
Alex P.
![Mauro Servienti [MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Mauro Servienti [MVP]
You wrote on 22/07/2009 :
> Salve,
>
> debbo utilizzare una DLL che ￜ di terze parti, quindi non la posso
> modificare.
> Questa DLL ￜ a 32 bit mentre la mia applicazione ￜ a 64 bit (C# .NET 3.5
> sp1).
>
> E' possibile farlo? e come?
>
se la dll di terze parti ￜ una dll .net non hai problemi, in realtￜ, se
non in casi sporadici, non hai realmente in mano un qualcosa a 32 o 64
bit finchpￜ non vai in esecuzione sulla macchina di destinazione eil
jitter fa il suo lavoro.
l'inghippo c'ￜ se la dll ￜ una dll COM o fa uso di roba com
specificamente a 32bit e tu sei in esecuzione su una macchina a
64bit... a questo punto l'unica ￜ forzare la compilazione del tuo
prodotto a 32bit.
> Grazie
> Alex P.
.m
--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it
Alessandro Pulvirenti
"Mauro Servienti [MVP]" <maurose...@online.nospam> ha scritto nel
messaggio news:mn.b35b7d974...@online.nospam...
> Ciao Alessandro Pulvirenti,
>
> You wrote on 22/07/2009 :
>> Salve,
>>
>> modificare.
>> Questa DLL � a 32 bit mentre la mia applicazione � a 64 bit (C# .NET 3.5
>>
>> E' possibile farlo? e come?
>>
>
> il suo lavoro.
>
> l'inghippo c'� se la dll � una dll COM o fa uso di roba com specificamente
La DLL non � .NET, ma � COM.
Non � possibile richiamare la DLL facendola eseguire in un altro Application
Domain...
credo che questo sia il problema, oppure mi sono un p� confuso le idee...
Alex P.
![Lorenzo Barbieri [MS]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjX3gtW6sACaBnHNp7W7kGwBSYwcDdLn50wp3hE3paGdae92XA=s40-c)
Lorenzo Barbieri [MS]
> La DLL non ￜ .NET, ma ￜ COM.
> Non ￜ possibile richiamare la DLL facendola eseguire in un altro Application
> Domain...
> credo che questo sia il problema, oppure mi sono un pￜ confuso le idee...
la tua applicazione deve PER FORZA essere eseguita a 64 bit? allora
l'unica soluzione ￜ WCF con qualcosa di Out of Process
se la tua applicazione puￜ essere eseguita a 32 bit, basta che
sostituisci AnyCpu con x86 e sei a posto
puoi anche farlo "dopo" aver compilato con un tool del .NET Fx SDK
io l'ho fatto con il tool per salvare le impostazioni del WLW che non
andava su macchine a 64 bit per il problema dell'"anycpu"
Lorenzo
--
Lorenzo Barbieri
Developer Evangelist - Microsoft Italia
Blog: http://www.geniodelmale.info
Blog VSTS: http://www.lorenzobarbieri.info (in Inglese)
Alessandro Pulvirenti
"Lorenzo Barbieri [MS]" <lorenzo....@microsoft.com> ha scritto nel
messaggio news:mn.b3bb7d972...@microsoft.com...
> Alessandro Pulvirenti pretended :
>> La DLL non � .NET, ma � COM.
>> Non � possibile richiamare la DLL facendola eseguire in un altro
>> Application Domain...
>> credo che questo sia il problema, oppure mi sono un p� confuso le idee...
>
> la tua applicazione deve PER FORZA essere eseguita a 64 bit? allora
Voglio che l'applicazione venga eseguita a 64 bit per sfruttare tutto quello
che questo ne consegue (molta pi� memoria, ecc.).
Sicuramente c'� una comunicazione tra due processi distinti che dovrebbe
avvenire.
Un processo a 64 bit deve comunicare con un altro processo a 32 bit e
passarsi le informazioni.
Vorrei trovare il modo pi� semplice per fare questo.
Anche perch� questa DLL deve essere richiamata una sola volta e ritornarmi
delle informazioni da utilizzare solo in fase di partenza.
Lorenzo Barbieri [MS]
> Vorrei trovare il modo piￜ semplice per fare questo.
WCF... senza web services :-)
Mauro Servienti [MVP]
You wrote on 22/07/2009 :
> Voglio che l'applicazione venga eseguita a 64 bit per sfruttare tutto quello
> che questo ne consegue (molta piￜ memoria, ecc.).
valuta molto bene perchￜ a meno che tu non faccia cose particolari
allaa fine della fiera non hai un plus vero e proprio... se ￜ lecito:
cosa fa l'applicazione?
> Sicuramente c'ￜ una comunicazione tra due processi distinti che dovrebbe
> avvenire.
> Un processo a 64 bit deve comunicare con un altro processo a 32 bit e
> passarsi le informazioni.
> Vorrei trovare il modo piￜ semplice per fare questo.
> Anche perchￜ questa DLL deve essere richiamata una sola volta e ritornarmi
> delle informazioni da utilizzare solo in fase di partenza.
devi necessariamente hostare la parte a 32bit in un processo diverso e
comunicarci ad esempio via WCF, come ti ha detto Lorenzo
Alessandro Pulvirenti
> Alessandro Pulvirenti explained on 22/07/2009 :
>
> WCF... senza web services :-)
Ottimo!...
solo che...
WCF ancora non l'ho mai usato! :-(((
Devo andare vedere qualche webcast registrato su questo argomento.
Spero di riuscire a fare qualcosa velocemente.
Concettualmente dovrebbe fare questo:
l'applicazione a 64 bit richiama "qualcosa" a 32 bit che collegato alla DLL
a 32 bit prende le informazioni e poi le restituisce all'applicazione a 64
bit.
Alessandro Pulvirenti
"Mauro Servienti [MVP]" <maurose...@online.nospam> ha scritto nel
messaggio news:mn.b4067d976...@online.nospam...
> Ciao Alessandro,
>
> You wrote on 22/07/2009 :
>> Voglio che l'applicazione venga eseguita a 64 bit per sfruttare tutto
>
> valuta molto bene perch� a meno che tu non faccia cose particolari allaa
Dell'applicazione ne viene fornita gi� una versione a 32 bit e una a 64 bit.
Quindi il cliente che non ha esigenze particolari utilizza quella a 32 bit,
mentre, quello che ha esigenze particolari vuole usare quella a 64 bit,
solo che se questa applicazione non comunica con una DLL a 32 bit
(saltuariamente),
non � possibile utilizzarla.
Quindi, la persona che lancia la versione a 64 bit � perch� ha esigenze
particolari e vuole eseguire quella a 64 bit.
> se � lecito: cosa fa l'applicazione?
Gestisce vettori di dimensioni, in alcuni casi, enormi (occupano anche pi�
GB di memoria) e a scelta dell'utente,
questi dati possono risiedere su disco (tempi un p� pi� lunghi) o in memoria
RAM (maggiore velocit�).
> devi necessariamente hostare la parte a 32bit in un processo diverso e
> comunicarci ad esempio via WCF, come ti ha detto Lorenzo
Capito...
solo che c'� un piccolo dettaglio...
ancora non s� come si f�! :-(
Raffaele Rialdi [MVP]
> l'applicazione a 64 bit richiama "qualcosa" a 32 bit che collegato alla DLL a
> 32 bit prende le informazioni e poi le restituisce all'applicazione a 64 bit.
Guardati qualche esempio di WCF con binding di tipo named pipes.
I vantaggi nell'uso di questo binding sono:
- configurazione piￜ semplice in quanto non c'ￜ la sicurezza di mezzo
(funziona solo su macchina locale)
- ￜ il binding piￜ performante disponibile in WCF
Se ti servissero piￜ performance dovresti passare a remoting, cosa che
ti sconsiglio se non in casi estremi.
--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -
http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://blogs.ugidotnet.org/raffaele
Mauro Servienti [MVP]
You wrote on 22/07/2009 :
> "Mauro Servienti [MVP]" <maurose...@online.nospam> ha scritto nel
> messaggio news:mn.b4067d976...@online.nospam...
>> Ciao Alessandro,
>>
>> You wrote on 22/07/2009 :
>>> Voglio che l'applicazione venga eseguita a 64 bit per sfruttare tutto
>>> quello che questo ne consegue (molta piￜ memoria, ecc.).
>>
>> valuta molto bene perchￜ a meno che tu non faccia cose particolari allaa
>> fine della fiera non hai un plus vero e proprio...
>
> Dell'applicazione ne viene fornita giￜ una versione a 32 bit e una a 64 bit.
> Quindi il cliente che non ha esigenze particolari utilizza quella a 32 bit,
> mentre, quello che ha esigenze particolari vuole usare quella a 64 bit,
> solo che se questa applicazione non comunica con una DLL a 32 bit
> (saltuariamente),
> non ￜ possibile utilizzarla.
ok, sempre per curiositￜ mia, perchￜ la distinzione tra 32 e 64bit?
solo per compatibilitￜ con la dll com?
> Gestisce vettori di dimensioni, in alcuni casi, enormi (occupano anche piￜ GB
> di memoria) e a scelta dell'utente,
> questi dati possono risiedere su disco (tempi un pￜ piￜ lunghi) o in memoria
> RAM (maggiore velocitￜ).
>
ok chiarissimo
>
> Capito...
> solo che c'ￜ un piccolo dettaglio...
> ancora non sￜ come si fￜ! :-(
Nulla di difficile, anzi, soprattutto se devi farlo one-time all'avvio.
Che tipo di dati devono passare dal componente verso la tua
applicazione?
Alessandro Pulvirenti
"Mauro Servienti [MVP]" <maurose...@online.nospam> ha scritto nel
messaggio news:mn.b9817d97c...@online.nospam...
>> Dell'applicazione ne viene fornita gi� una versione a 32 bit e una a 64
>> bit.
>> Quindi il cliente che non ha esigenze particolari utilizza quella a 32
>> bit,
>> mentre, quello che ha esigenze particolari vuole usare quella a 64 bit,
>> solo che se questa applicazione non comunica con una DLL a 32 bit
>> (saltuariamente),
>> non � possibile utilizzarla.
>
> ok, sempre per curiosit� mia, perch� la distinzione tra 32 e 64bit? solo
> per compatibilit� con la dll com?
semplicemente per essere sicuro che giri a 32 o 64 bit.
Non vorrei che l'applicazione, dovendo accedere a una DLL a 32 bit,
venga eseguita sempre a 32 bit.
>> Capito...
>> solo che c'� un piccolo dettaglio...
>> ancora non s� come si f�! :-(
>
> Nulla di difficile, anzi, soprattutto se devi farlo one-time all'avvio.
> Che tipo di dati devono passare dal componente verso la tua applicazione?
I dati da passare sono solo qualche stringa e qualche numero intero, dati
semplici,
non sono necessarie strutture o classi.
Leggendo un p� di documentazione, articoli e vedendo qualche esempio,
sono riuscito a realizzare un'applicazione console che mi fornisce il
servizio,
(accedere alla DLL quando necessario).
Ora il problema � che:
1) il binding avviene tramite "wsHttpBinding" mentre mi consigliavano named
pipes, come cambiarlo?
2) posso evitare che si apra la finestra dell'applicazione console? mi
conviene fare qualche altro formato (WinForm senza finestra ?).
Il metodo che utilizzo � il seguente:
1) viene lanciata l'applicazione a 64 bit;
2) quest'ultima lancia l'applicazione console a 32 bit che fornisce il
servio (accedere alla DLL);
3) viene richiesto l'accesso alla DLL tramite l'applicazione console;
4) i dati vengono restituiti tramite binding "wsHttpBinding";
5) l'applicazione console deve restare aperta per tutto il tempo che
l'applicazione a 64 bit viene eseguita, in quanto ogni tanto ne viene
effettuato un accesso.
Grazie a tutti per l'aiuto che mi state dando.
Alex P.
Mauro Servienti [MVP]
You wrote on 23/07/2009 :
> semplicemente per essere sicuro che giri a 32 o 64 bit.
> Non vorrei che l'applicazione, dovendo accedere a una DLL a 32 bit,
> venga eseguita sempre a 32 bit.
ok, quindi la soluzione Wcf/quello che vuoi ti potrebbe anche sgravare
dal mantenere le 2 build.
> Ora il problema ￜ che:
> 1) il binding avviene tramite "wsHttpBinding" mentre mi consigliavano named
> pipes, come cambiarlo?
parti da qui:
http://msdn.microsoft.com/en-us/library/ms730879.aspx
> 2) posso evitare che si apra la finestra dell'applicazione console? mi
> conviene fare qualche altro formato (WinForm senza finestra ?).
WinForm senza finestra
> Il metodo che utilizzo ￜ il seguente:
> 1) viene lanciata l'applicazione a 64 bit;
> 2) quest'ultima lancia l'applicazione console a 32 bit che fornisce il servio
> (accedere alla DLL);
> 3) viene richiesto l'accesso alla DLL tramite l'applicazione console;
> 4) i dati vengono restituiti tramite binding "wsHttpBinding";
> 5) l'applicazione console deve restare aperta per tutto il tempo che
> l'applicazione a 64 bit viene eseguita, in quanto ogni tanto ne viene
> effettuato un accesso.
il processo figlio ￜ tuo quindi si chiude quando lo stabilisci tu, io
esporrei anche un metodo Shutdown() dal servizio Wcf che altro non fa
che terminare il processo figlio a 32bit
> Grazie a tutti per l'aiuto che mi state dando.
>
> Alex P.
.m
Alessandro Pulvirenti
> You wrote on 23/07/2009 :
>> semplicemente per essere sicuro che giri a 32 o 64 bit.
>> Non vorrei che l'applicazione, dovendo accedere a una DLL a 32 bit,
>> venga eseguita sempre a 32 bit.
>
> ok, quindi la soluzione Wcf/quello che vuoi ti potrebbe anche sgravare dal
> mantenere le 2 build.
in teoria si, ma in pratica questi 64 bit mi stanno creando un sacco di
problemi!
>> Ora il problema � che:
>> 1) il binding avviene tramite "wsHttpBinding" mentre mi consigliavano
>> named pipes, come cambiarlo?
>
> parti da qui:
> http://msdn.microsoft.com/en-us/library/ms730879.aspx
Con HttpBinding mi funziona, con Named Papes invece No!
Sicuramente perch� sbaglio in qualcosa...
in teoria basterebbe sostituire il protocollo, ma a me non funziona e quindi
per adesso utilizzo HttpBinding.
Anche se avrei preferito l'altro.
>> 2) posso evitare che si apra la finestra dell'applicazione console? mi
>> conviene fare qualche altro formato (WinForm senza finestra ?).
>
> WinForm senza finestra
Anche qui, qualche piccolo problema l'ho avuto.
Posso creare anche una applicazione WinForm con una finestra,
tanto appena creo il "ServiceHost" la finestra neanche appare.
>> Il metodo che utilizzo � il seguente:
>> 1) viene lanciata l'applicazione a 64 bit;
>> 2) quest'ultima lancia l'applicazione console a 32 bit che fornisce il
>> servio (accedere alla DLL);
>> 3) viene richiesto l'accesso alla DLL tramite l'applicazione console;
>> 4) i dati vengono restituiti tramite binding "wsHttpBinding";
>> 5) l'applicazione console deve restare aperta per tutto il tempo che
>> l'applicazione a 64 bit viene eseguita, in quanto ogni tanto ne viene
>> effettuato un accesso.
>
> il processo figlio � tuo quindi si chiude quando lo stabilisci tu, io
> esporrei anche un metodo Shutdown() dal servizio Wcf che altro non fa che
> terminare il processo figlio a 32bit
L'ho fatto e funziona.
L'unico problema � che tutto quello che ho fatto,
funziona benissimo su un sistema operativo a 32 bit,
mentre mi va in errore in quello a 64 bit.
Ho provato a compilare l'applicazione host sia con "Any CPU" che con "x64",
ma mi va in errore, segnalando un errore del framework!
L'errore c'� ancor prima che si faccia accesso alle DLL.
Praticamente cheare il "Service Host" fa andare in errore l'applicazione
host,
se eseguita in un SO a 64 bit, mentre funziona benissimo con SO a 32 bit.
Devo trovare una soluzione al pi� presto!
Grazie
Alex P.
Raffaele Rialdi [MVP]
> in teoria basterebbe sostituire il protocollo, ma a me non funziona e quindi
> per adesso utilizzo HttpBinding.
> Anche se avrei preferito l'altro.
Un consiglio. Non usare WCF se non capisci cosa stai facendo nei file
di configurazione.
Tolti i file di configurazione, WCF lo puoi mettere in mano ad un
bambino, ma quei file fanno la differenza tra fare un buon lavoro e un
macello.
Se poi vuoi usarlo c'ￜ il tool di configurazione (nel solution
explorer, pulsante destro sulla config, edit wcf config o qualcosa del
genere).
Mauro Servienti [MVP]
You wrote on 23/07/2009 :
> L'ho fatto e funziona.
ok
> L'unico problema ￜ che tutto quello che ho fatto,
> funziona benissimo su un sistema operativo a 32 bit,
> mentre mi va in errore in quello a 64 bit.
> Ho provato a compilare l'applicazione host sia con "Any CPU" che con "x64",
> ma mi va in errore, segnalando un errore del framework!
ma se non ho capito male tu devi forzare la compilazione dell'host a
32bit perchￜ la dll unmanaged che poi chiami ￜ a 32bit.
> L'errore c'ￜ ancor prima che si faccia accesso alle DLL.
> Praticamente cheare il "Service Host" fa andare in errore l'applicazione
> host,
> se eseguita in un SO a 64 bit, mentre funziona benissimo con SO a 32 bit.
quale ￜ l'errore?
> Devo trovare una soluzione al piￜ presto!
Alessandro Pulvirenti
"Mauro Servienti [MVP]" <maurose...@online.nospam> ha scritto nel
>> L'unico problema � che tutto quello che ho fatto,
>> funziona benissimo su un sistema operativo a 32 bit,
>> mentre mi va in errore in quello a 64 bit.
>> Ho provato a compilare l'applicazione host sia con "Any CPU" che con
>> "x64",
>> ma mi va in errore, segnalando un errore del framework!
>
> ma se non ho capito male tu devi forzare la compilazione dell'host a 32bit
Vero!
Poi per fare una prova, tanto per, l'ho voluta compilare a 64 bit,
ma a me interessa farlo a 32 bit per comunicare con la DLL.
>> L'errore c'� ancor prima che si faccia accesso alle DLL.
>> Praticamente cheare il "Service Host" fa andare in errore l'applicazione
>> host,
>> se eseguita in un SO a 64 bit, mentre funziona benissimo con SO a 32 bit.
>
> quale � l'errore?
In questo momento non s� dirtelo, in quanto sono state altre persone a
testarlo.
Adesso installo Windows Vista a 64 bit sp 2 e faccio delle prove io.
Alex P.
Alessandro Pulvirenti
"Raffaele Rialdi [MVP]" <malta@n0spam_vevy.com> ha scritto nel messaggio
news:mn.c0187d973...@n0spamvevy.com...
>
> Un consiglio. Non usare WCF se non capisci cosa stai facendo nei file di
> configurazione.
Ho dovuto fare tutto di fretta, per questo non ho la piena conoscenza di
quello che fanno i file di configurazione.
Approfondir� il tutto questo fine settimana.
> Tolti i file di configurazione, WCF lo puoi mettere in mano ad un bambino,
> ma quei file fanno la differenza tra fare un buon lavoro e un macello.
> Se poi vuoi usarlo c'� il tool di configurazione (nel solution explorer,
> pulsante destro sulla config, edit wcf config o qualcosa del genere).
Il programma di configurazione l'ho visto e utilizzato,
mi dava, come risultato, lo stesso file di configurazione.
Penso per� che forse ho fatto un errore,
cio�, cambiavo il file di configurazione mentre il servizio era attivo e
quindi, pu� anche darsi che il file eseguibile non veniva sostituito
oppure restava attivo il precedente.
Adesso con calma cercher� di fare delle altre prove.
La cosa che mi ha creato un p� di confusione � il fatto che per l'Host,
si utilizza un indirizzo http,
mentre come endpoint address si utilizza "net.pipe:".
Devo approfondire l'argomento.
Comunque ho capito che fatto uno per bene,
poi diventa molto semplice cambiarli.
WCF dopo uno studio iniziale,
penso veramente che sia semplice.
Grazie
Alex P.
Mauro Servienti [MVP]
You wrote on 24/07/2009 :
> In questo momento non sￜ dirtelo, in quanto sono state altre persone a
> testarlo.
> Adesso installo Windows Vista a 64 bit sp 2 e faccio delle prove io.
>
ok, siamo qui se ti serve.
> Alex P.
Raffaele Rialdi [MVP]
> mi dava, come risultato, lo stesso file di configurazione.
>
> cioￜ, cambiavo il file di configurazione mentre il servizio era attivo e
> quindi, puￜ anche darsi che il file eseguibile non veniva sostituito
> oppure restava attivo il precedente.
Il tool cambia l'app.config che poi diventa il file di configurazione
*durante la compilazione* nella cartella debug/release.
Quindi ovviamente per leggere la nuova config devi riavviare il
servizio.
Altrettanto ovvio ￜ la necessitￜ di cambiare la configurazione sia del
client che del server in modo che siano compatibili tra loro visto che
devono parlare con lo stesso protocollo.
> La cosa che mi ha creato un pￜ di confusione ￜ il fatto che per l'Host,
> si utilizza un indirizzo http,
> mentre come endpoint address si utilizza "net.pipe:".
???