Newsgroup: it.comp.lang.visual-basic
Titolo: di nuovo .NET

Scusate se insisto sull'argomento differenze VS6 - VS2005...
Personalmente il fatto che il codice sia diverso mi interessa "il giusto".
Semmai mi farebbe piacere spere se a differenza del vecchio VB6 il nuovo può
creare codice oggetto linkabile con il C oppure no.
Questo, dal mio punto di vista cambierebbe DRASTICAMENTE (in meglio) le
cose.
Fino ad oggi ho dovuto scrivere delle DLL in C, Fortran.... da richiamare
poi in VB per la parte grafica (che è sempre stata molto facile da
sviluppare in VB).
Rovesciare le sitiazione sarebbe veramente "innovativo" (fare le DLL in VB)
e chiamarle dal C, fortran, Delphi....
Ne sapete niente?
Ciao e grazie
Ioson

 creare codice oggetto linkabile con il C oppure no.
Per quanto ne so una libreria di classi .NET può esporre una interfaccia 
COM, quindi può essere visibile anche da linguaggi unmanaged (ma il 
Framework ovviamente resta obbligatorio).
Però non so quanto possa essere efficiente o sensato. Non è meglio fare 
tutto in .NET?
-- 
news:it-alt.comp.software.openoffice : Il newsgroup dedicato a
OpenOffice.org, la suite open source di applicazioni per ufficio.
Saluti, VITRIOL


Aspetta.. forse non mi sono spiegato bene.
situazione vecchio VS:
scrivo una applicazione in VB che presenta un po' di form  con dentro una
serie di controlli.
Tutti i calcoli, gestione dati, ecc vengono fatti con delle DLL che ho
scritto e compilato in C.
Purtroppo (per fortuna) , la parte "complicata" è scritta in C e non posso
scriverla in VB.
Quindi ho un eseguibile in VB che usa delle DLL esterne in C. Nessun uso di
COM ecc.
Il mio sogno sarebbe quello di poter rovesciare la situazione o meglio:
Poter "compilare separatamente" e "linkare assieme" il codice VB con quello
C per creare un'unico EXE.
Ovviamante "compilare" e "linkare" si intende in modo che una
funzione/routine del VB possa essere chiamata direttamente dal C.
Sono stato chiaro?
Grazie
Ioson

 C per creare un'unico EXE.
IMHO non è possibile. La situazione ideale sarebbe quella di avere tutto 
codice .NET, indipendentemente dal linguaggio di programmazione.
Ad esempio una libreria scritta in C# o in C++/CLI può venire 
referenziata direttamente in 
VB.NET
 e utilizzata in modo assolutamente 
trasparente. Non si deve fare nulla. Puoi anche linkarla con in un unico 
EXE usando ILMerge.
E' poi possibile usare una libreria "classica" win32 (scritta in C, C++, 
Delphi...) in .NET tramite P/Invoke.
Doverebbe essere anche possibile utilizzare una libreria .NET in un 
linguaggio Win32 (Iverse P/Invoke), ma mi pare che occorra comunque 
passare tramite COM.


 passare tramite COM.
Cosa decisamente scomoda ed inaffidabile (almeno nel vecchio VS).
Ciao
Ioson

 Delphi facendo delle chiamate da main in C a routines scritte in VB?
No, non è possibile. Puoi creare una soluzione che contiene progetti in 
diversi linguaggi, ma non puoi mischiare diversi linguaggi nello stesso 
progetto.
Per quanto riguarda .NET comunque il problema non sussiste, perché gli 
assembly creati con diversi linguaggi possono interagire in modo 
totalmente trasparente. Non te ne accorgi neppure, perché tutti i 
compilatori compilano in IL (il linguaggio "a basso livello" di .NET) e 
per .NET non fa alcuna differenza il linguaggio di origine.
Ad ogni modo non devi confondere un compilato .NET (detto managed), da 
un compilato Win32 (detto unmanaged). VS compila solo per .NET 
sfruttando tutte le sue potenzialità, quindi il problema dei differenti 
linguaggi in VS non si pone.


 chiamata direttamente da C (sempre in VS2005)?
Non avrebbe senso e se il problema è importare l'interfaccia in una dll c++ 
questo va contro tutte le norme di buona programmazione, che vuole 
l'interfaccia *sopra* alle librerie e non sotto.
L'unico problema (da testare) sono le performances del c++/cli che 
compilando in IL dovrebbe essere un bel pezzo più lento del corrispondente 
win32.
Ma già il vantaggio di scrivere e debuggare un progetto 
vb.net
 e c++ nella 
stessa istanza di VS è secondo me impagabile.
Ciao

 (che supportano IL) ?
Facciamola semplice, un esempio classico: tu fai un progetto in c#, poi uno 
in 
vb.net
 dove referenzi quello in c#.
Ora in 
vb.net
 scrivi codice 
vb.net
 usando le classi di quello scritto in c# 
*esattamente* come se fossero state scritte in 
vb.net
 o in qualsiasi altro 
linguaggio .net.
In pratica tu non ti accorgi e non sai in che linguaggio č stata scritta la 
libreria.
Ciao 

 (che supportano IL) ?
Sì, a patto che tu referenzi "moduli" compilati per la stessa versione 
del Framework, o per una versione inferiore.
Attualmente, ad esempio, VS 2005 compila per .NET 2.0, mentre Delphi è 
rimasto indietro, e compila per .NET 1.1.
Se tu compili una DLL con Delphi e la referenzi in VS funzionerà, ma se 
tenti di fare il contrario (referenziare una libreria VS 2005 in Delphi) 
allora non funzionerà.
Questo perché .NET è compatibile all'indietro e non in avanti.
Comunque, nel caso specifico, Delphi verrà presto aggiornato a .NET 2.0, 
e il problema non sussisterà più. Era solo mettere in evidenza questa 
differenza tra versioni.
Allo stesso modo un programma compilato per .NET 1.1 funzionerà su .NET 
2.0 o superiori, ma non il contrario.


Grazie.
Non mi manca che provare.
Auguratemi buona fortuna....
Ciao
Ioson

Meraviglioso.. (se funza)...:))))))
Grazie mille
apesso proverň.
Ioson
Un'ultima cosa ... basta la versione gratuita di VS2005 o bisogna andare
sulla prof.?
Arigrazie
Ariciao

 sulla prof.?
Ti bastano le Express gratuite che hanno l'unico grosso limite di poter 
creare soluzioni con progetti dello stesso linguaggio, che detto così sembra 
il contrario di quanto detto finora, ma non è vero: puoi aprire un 
vb.net
 
express e un c# express e farli interagire, ma non è come VS che ti permette 
di mescolare nello stesso IDE più linguaggi contemporaneamente.
Ciao 

 sulla prof.?
Sicuramente per iniziare basta la versione gratuita (denominata 
Express), ma tieni conto che questa versione ha un IDE separato per ogni 
linguaggio, e se vuoi pasticciare con diversi linguaggio non è proprio 
comodissimo.
In alternativa c'è SharpDevelop, che è open source, piccolissimo (9 MB 
il file di installazione) e per nulla invasivo. Però gestisce solo C#, 
VB.NET
 e Boo (un linguaggio .NET non Microsoft). Il Framework 
(consigliato anche l'SDK con tutta la documentazione) va installato a parte.


TKS one more time

Grazie mille anche a te.
Ciao

 (consigliato anche l'SDK con tutta la documentazione) va installato a parte.
Sharp Develop gestisce anche il Compact Framework per PocketPC :)
(giusto per la memoria di google, se non erro mi hai aiutato per i file INI
sul NG Ms) :D
-- 
DBMS Firebird
VB6 + Ado

 Sharp Develop gestisce anche il Compact Framework per PocketPC :)
Sì, intendevo come linguaggi. Se è per questo gestisce anche Mono, come 
Framework.
A me piace parecchio. Non è un mostro di stabilità, ma il filo diretto 
con gli sviluppatori sul forum aiuta.
