Newsgroup: it.comp.lang.visual-basic
Titolo: [?][.NET]DLL ActiveX

Ho mio malgrado scoperto che in 
VB.NET
 Standard Edition non
si possono creare progetti DLL ActiveX.
Esiste un sistema per creare/compilare una DLL ActiveX
sfruttando l'IDE di 
VB.NET
 SE ed eventualmente compilazione
a riga di comando?
Grazie per eventuali link e/o info,
Lokar
-- 
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt
UGIdotNET - 
http://www.ugidotnet.org

 Lokar
Ciao
Alessandro
P.S. anche tu se mi hai plonkato come dici non vedrai la risposta.
--
Morfeus®
Free Joint
:PII

 a riga di comando?
A quanto mi risulta (ma non ho ancora provato con successo) 
VS.NET
 non 
permette di creare DLL ActiveX.
E' invecie possibile usare un tool compreso nel framework (un programma 
a linea di comando, tlbexp.exe se non sbaglio) che crea una tlb in modo 
da usare la tua dll-net come se fosse una dll-activex.
Credo perņ che il compilato .net debba avere qualche accorgimento 
(qualche direttiva di compilazione?)
Ciao

 permette di creare DLL ActiveX.
[SNIP]
Si puo' fare, il paragrafo di riferimento nella documentazione dell'SDK e'
"Exposing .NET Framework Components to COM" mentre gli esempi del caso sono
su <percorso del SDK>Samples\Technologies\Interop\
Ciao
-- 
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown


.A
UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org

 si possono creare progetti DLL ActiveX.
No, non é possibile creare una DLL ActiveX, ma...
é possibile creare una DLL .NET e registrarla come server ActiveX (ovvero in
sostanza non cambierebbe niente!)
Come fare?
Primo: Creare la DLL con uno strong name.
1) Come fare a creare uno strong name:
1a) creare una coppia di chiavi con l'utility sn.exe (fai sn /? dal prompt
dei comandi di 
VS.NET
 o dalla opportuna cartella del framework)
  Ti conviene creare un file con le chiavi che utilizzerai sempre per i tuoi
progetti e quella sarà la tua "firma digitale"
1b) Inserire in AssembyInfo.vb il seguente attributo: <Assembly:
AssemblyKeyFile("C:\..........................."> dove specifichi la
posizione del file con le chiavi
2)Come fare a registrare la DLL che generari:
  regasm percorsoEnomeDLL.dll /tlb: StessoPercorsoEStessoNome.tlb
A questo punto dal tuo progetto può referenziare la tlb creata come se fosse
una DLL ActiveX...
                        Ciao
                                                            Allanon
--
- SPAMKILLER
 L'indirizzo delle risposte é 
itlangv...@michele.sytes.net
 LASCIATE il NOSPAM fa parte dell'indirizzo :-)
  Per superare le impostazioni di protezione antispam scrivete
  nel testo del messaggio la scritta "SPAMKILLER"
Scusate il disturbo, ma non posso più di pubblicità

 [SNIP]
Grazie a tutti per le preziose informazioni.
Un chiarimento. La mia intenzione e' di scrivere un
programma modulare, con una DLL "core" con tipi e classi di
base, tanti plugin referenzianti la DLL "core" e derivati da
una delle classi base ed un eseguibile che carica
dinamicamente i plugin.
Morpheus indica un modo per compilare librerie (DLL) in
VB.NET
 a riga di comando.
Che differenza c'e' con le DLL ActiveX sviluppate in VB?


 Lokar
Ciao
Alessandro


 (inserire spazi e apostrofi a piacere).
E Buon DIO ,Perchè?



Semplicemente, le "DLL" sviluppate con VB .NET _non_ sono server COM; ciò
nonostante, ti becchi tutti gli svantaggi di COM: dovrai registrarle, dovrai
stare attento ai problemi di versioning. Paradossalmente, dovrai stare
ancora + attento di quanto non avresti dovuto esserlo sviluppando la
libreria direttamente in VB6. Oltretutto, ti beccherai un overhead medio del
15% per ogni chiamata a metodo (è una stima di MS e, come tutte le stime,
conviene pernsare che sia ottimistica) dovuto all'intervento di Interop
(creazione del Runtime Callable Wrapper, Marshal dei parametri, uso
estensivo da parte del CLR di tipi non isomorfi, ...)
Insomma, se facilità di manutenzione e performance per il tuo progetto non
sono significative, alllora vai tranquillo. Altrimenti, beh... pensaci
_davvero_ bene.


 E Buon DIO ,Perchè?
Appunto! :)

 Appunto! :)
Ma vaffalova e io che vi vengo dietro


 _davvero_ bene.
Beh, se non hai serio bisogno di prestazioni e hai la DLL o le funzioni per
la DLL già fatte... Non pensarci nemmeno un secondo... E una la COM
Interop...
Soltanto posso testimoniare di avere avuto un problema... Se hai caricamenti
da database particolarmente pesanti ci deve essere un qualche timeout che
alla fine ti crasha l'applicazione... :(
Aggiungerei una cosa per Lokar: Usa l'attributo <Guid("{TuaGUID}")> e non
avrai il problema di dover cambiare irferimenti ogni volta! :)


[MEGA-SNIP]
Grazie ancora i suggerimenti ricevuti sono davvero
preziosi...
Chiedo scusa per essermi spiegato estremamente male :)
In realta' non mi interessa che le DLL siano ActiveX, davo
per scontato che le DLL .NET fossero ActiveX, mentre
arguisco dai vostri post che non lo sono affatto a meno di
registrarle come Server ActiveX con gli appositi tool, che
ne creano il relativo .tlb referenziabile.
Sempre dai vostri post capisco che per compilare un DLL .NET
posso (con i dovuti accorgimenti) utilizzare la compilazione
da riga di comando.
Andrea Saltarello dice pero' che le DLL .NET sono un inferno
peggiore delle DLL ActiveX, poiche' oltre a dover essere
registrate, tocca stare attenti col versioning, beccarmi un
overhead minimo di 15% ad ogni chiamata.
A questo punto mi chiedo se vale il caso di passare a .NET
per sviluppare questo progetto.
Cerchero' di essere sintetico :)
Devo sviluppare un'applicazione interamente .NET senza
compatibilita' alcuna con VB6/C++ o quant'altro.
L'applicazione *deve* essere modulare: intendo distribuire
un'applicazione base e tanti plug-in (tipo Photoshop per
capirci).
Per come la vedo, l'applicazione sara' un eseguibile .NET, i
plugin delle DLL .NET ed entrambi dovranno referenziare una
libreria di classi e tipi comuni sempre DLL .NET, che
contiene anche il prototipo per i plugin.
Entrando nel dettaglio l'applicazione base si occupa di
catturare dei dati con una frequenza variabile da 10 al
minuto (1 ogni 5-6 secondi) a 150 al minuto (2-3 al secondo)
e di "alimentare" i plugin. Ogni plugin analizza man mano la
serie passata ed al verificarsi delle condizioni codificate
nel plugin viene scatenato un evento di cambio stato, a sua
volta gestito dall'applicazione principale.
Cio' detto, la strada *migliore* da praticare e' quella
delle DLL .NET o esistono sistemi alternativi?
Grazie a tutti per la disponibilita' e l'aiuto che mi state
fornendo... A buon rendere ;)


 per sviluppare questo progetto.
Avendo parlato di "ActiveX" piu' o meno tutti pensavamo volessi sviluppare
dei componenti che fossero compatibili con il mondo COM (per es. invocabili
ad un client VB6)... i problemi che descriveva Andrea sono relativo
all'utilizzo, possibile, di componenti .NET in tale contesto, non alla
normale interazione tra componenti .NET e basta
Se non ti interessa nulla di tutto questo, allora quello che devi fare sono
semplicemente dei progetti di tipo Class Library, che concettualmente sono
paragonabili alla funzione che svolgevano le DLL ActiveX in VB6, ma senza
nessun problema di registrazioni, overhead aggiuntivo e quant'altro... tutto
.NET nativo.
Resta la questione che 
VB.NET
 standard non supporta i progetti di questo
tipo; sono piu' che convinto che tu possa compilarli direttamente con il
framework, ma ovviamente perdi tutte le funzionalita' di debug tramite
IDE... per quest'ultimo punto potresti compensare, ma non so fino a che
livello, con il tool 'DbgCLR.exe' incluso nel SDK


 delle DLL .NET o esistono sistemi alternativi?
Esistono sistemi alternativi, ma questa strada é la migliore... :)


 Lokar
Ciao
Alessandro


 livello, con il tool 'DbgCLR.exe' incluso nel SDK
Ah, mi era sfuggito che usa 
VB.NET
 e non 
VS.NET
! :-)
Si potrebbe usare #Develop per creare la DLL o ancora meglio testare tutte
le classi all'interno del progetto .EXE e poi compilare con il compilatore a
linea di comando...
Un'avvertenza: occhio alle imports a livello di progetto perché non valgono
usando il compialtore a linea di comando...


[SNIP]
Per l'ultima volta (per questo thread ;) ), grazie ancora a
tutti!
Per Allanon:
avevo notato dai tuoi thread precedenti che ti stai
occupando della stessa cosa e confidavo infatti in un tuo
intervento.
Considera che io ho gia' sviluppato la base di tutto il
lavoro in VB6 sfruttando classi, OOP (per quanto concessa da
VB6) ed ereditarieta' di interfaccia. Il "porting" sara'
molto rapido.
In ogni caso (a scanso di equivoci) non sono proprio
all'asciutto di .NET e 
VB.NET
: ho "leggiucchiato" Vecchio e
Nuovo Testamento (come li chiamo io ;) ) ovvero Balena +
Richter/Balena e mi sono gia' "divertito" con alcuni
progettini. Inoltre a suo tempo programmavo C++ e mi sono
trovato a sviluppare con VC++ e le MFC (un "framework" per
VC++ :) ) quindi l'approccio mi e' abbastanza familiare.
Grazie e a risentirci su questi lidi,
Happy Coding =)


 linea di comando...
Il problema e' proprio il "testare": #Develop e' solo un editor, non ha il
debugger integrato come VS...


 debugger integrato come VS...
Beh, ribadisco, testare all'interno del progetto EXE, fare la DLL a mano
(con un bel file batch in modo da non dover riscrivere tutto il mondo ogni
volta) e verificare che funzioni... Condire il tutto con fiducia nella
Provvidenza...


 Provvidenza...
Hai ragione, ho capito ora che intendevi un progetto EXE "client+libreria
mischiati" per usare l'IDE standard :-)



"Andrea Saltarello" si è (evidentemente) spiegato male... L'overhead
menzionato è presente solo nel caso di uso della Intoperabilità COM: se da
un "exe" .NET usi una "dll" .NET non avrai questa penalizzazione. Mi spiace
per l'equivoco...
