PDA

Visualizza versione completa : [VB.NET] Inclusione dll nei progetti


cipi
25-10-2004, 16.43.25
Io ho creato una mia dll e, una volta aggiunto il riferimento ad essa e scritto Dim funzione as New MyDll.Class() riesco a vederla e utilizzarla ma il problema diventa... una volta che io distribuisco la mia dll, qualsiasi utente può utilizzarla! Vero? Come faccio a renderla utilizzabile dal mio prog e inutilizzabile a terze persone?
Grazie,
cipi

ceccus
25-10-2004, 17.09.19
Salve,
Un modo semplice semplice è quello di prevedere nelle chiamate alla TUA dll (alias Funzioni Pubbliche), un parametro che rappresenta un GUID conosciuto soltanto dalla DLL (ovviamente) e dal Server che la richiama...in questo modo le chiamate che non contemplano questo GUID, sono destinate a fallire....
Ripeto, questo è solo uno degli n metodi possibili....
Altro modo è controllare l' "identity" del chiamante e se questa corrisponde bene, altrimenti..SKULO !!

Ciao !!

cipi
25-10-2004, 17.36.59
Ciao ceccus,
grazie per la dritta... devo essere sincero che le GUID non le conoscevo fino a 10 minuti fa... :( :(
Farò come suggerisci... Giusto per curiosita'... mi dici un altro degli n metodo possibili? ;)
Grazie 1k ancora....
cipi

P8257 WebMaster
25-10-2004, 17.43.01
Ma scusate...
il bello delle applicazioni multi-tier è quello di avere componenti riusabili e atte alla realizzazione di plugin o altro software che ne estende le funzionalità...

I suggerimenti dati sono corretti, ma a prescindere da questo ti basta non fornire la documentazione delle API che la dll espone e ti sfido a trovare un Programmatore (la P maiuscola non è a caso) che chiama delle API non documentate...

Bye :cool:

ceccus
25-10-2004, 17.50.52
Salve,
Osservazione corretta...
La risposta è arrivata ad una domanda esplicita....
Per il discorso API....
Beh..leggendo la TLB (TLB = Type Library) di un componente COM (anche VB la genera e la tiene interna se non si flegga "Remote Server Files" nella scheda Component delle proprietà di progetto) si risale facilmente alle funzioni Pubbliche e ai parametri esposti...(anche alla loro tipologia....).
Mi ricordo che, tempo addietro, la sviluppai anche una Classettina VB6 che leggeva la Tlb (o la Dll) e estraeva le Funzioni Pubbliche e i parametri associati....
Esiste uno strumento anche nel Visual Studio che corrisponde al nome di OLE Viewer e anche con quello si possono fare delle cosettine interessanti.....a patto che i componenti che si vanno a "visualizzare" siano COM...(e per il VB6 non può che essere così....)
Altro discorso se si sviluppa un componente NON-COM.....quì, chiaramente le difficoltà aumentano e non si parla di sviluppo VB6....)

Ciao !!

P.S. : un' altro metodo te l'ho descritto prima : Controllare l'identity di chi chiama e regolarsi di conseguenza....

cipi
26-10-2004, 12.06.38
ok, sarà come dite voi ma... AIUTOOOO!!!! Non riesco a trovare una cacchio di guida online che mi spieghi come si fa.... Dopo svariati tentativi ho scritto nella classe che genera la dll (che è scritta in C#):

namespace mynamespace
{
[ClassInterface(ClassInterfaceType.AutoDispatch)]
[Guid("B0...c0-A...A-63...BA2")]
public class Class1
{
public class Class2
{

ma mi sa che non basta... COsa devo aggiungere? E come faccio poi a richiamare la classe da VB.NET???
Grazie 1k, anzi 1G :D
cipi

ceccus
26-10-2004, 12.14.02
Salve,
Non ci siamo capiti.....
Quando dico di passare un Guid come parametro, intendo dire che ad ogni Funzione Pubblica della tua classe deve essere passato come parametro il GUID di riferimento....e che deve essere poi controllato...
Poi, la tua interazione è fra assembly.net o fra .NET e COM ??
Come intendi sviluppare la tua applicazione ??

Ciao !!

cipi
26-10-2004, 12.21.08
Ciao ceccus e intanto grazie per la pazienza.... ;)
Allora, la dll è semplicemente generata compilando una classe in C# come "Libreria di classi". Ora questa dll viene letta e utilizzata da un prog scritto in vb.net... (aggiungi riferimento... bla bla bla)
Il problema è che non riesco a capire come utilizzare il System.Guid :(

ceccus
26-10-2004, 12.52.44
Salve,
Prego ... ci mancherebbe...
Prova a leggere un po' quà :

http://www.dotnet247.com/247reference/System/Guid.aspx

Ciao !!

cipi
26-10-2004, 14.26.39
ok... il penultimo post mi ha illuminato...
Definisco una Guid nella dll e nella applicazione chiamante; ogni funzione nella dll confronta le due guid e, nel caso non siano uguali...

throw(new ApplicationException("Guid dell'applicazione errata!"));

Semplicissimo... Chissà perché ci ho meso tanto a capirlo :confused: ???
Grazie ancora,
cipi
PS
E se volessi anche celare (supponiamo in Visualizzatore risorse) il contenuto della dll... Si può fare?

ceccus
26-10-2004, 19.11.51
Salve,
Guarda..."celare" il contenuto di una Dll ottenuta su piattaforma .NET è "un eresia"...nel senso che , con un qualsiasi disassemblatore (una famoso è Anakrino), potrai comunque ricavare il codice sorgente !!! (esistono delle tecniche per "nasconderlo"...ma nemmeno poi tanto.....). per cui....rassegnati !!... a meno che , la tua Dll nasca come Library codificata in C++ "unmanaged" ....

Ciao!!

P.S. : toglimi una curiosità.....ma perchè "cotanta segretezza" ??

cipi
27-10-2004, 16.22.57
Semplice... in quella dll c'è un codice di crittaggio e decrittaggio... Se una potesse utilizzarlo liberamente... non avrebbe senso averlo creato! :D
Ciao e alla prossima ;)

ceccus
27-10-2004, 16.58.01
Salve,
E allora , se le cose stanno così, ha MOLTO SENSO creare la Dll in C++ .......

Ciao !!

P.S. : grazie per aver risposto alla mia curiosità.....

cipi
27-10-2004, 17.45.58
purtroppo nn ne sono capace... :(
Ma penso che ora che c'è la Guid nn ci siano più problemi...

ceccus
27-10-2004, 19.07.12
Salve,
Mah....una volta sviluppato il tuo componente, prova a disassemblarlo con Anakrino....

http://www.dotnetcoders.com/web/Articles/ShowArticle.aspx?article=40

Ciao !!

cipi
28-10-2004, 10.58.03
Sono IM PRES SIO NA TO!!! Cacchio.... mi becca la MyGuid interna.... :mad: :mad:
Devo assolutamente risolvere questo problema!!!!
Grazie 1k, come sempre... ;)

ceccus
28-10-2004, 11.39.08
Salve,
Se vuoi essere un po' più sicuro, credo che la strada sia obbligata...(C++ unmanaged.....o anche VB6...meno sicuro, ma sempre molto meglio del C#....devi solo "spostare" le routine di codifica/trascodifica su questo nuovo componente...)
Altrimenti, la tua Guid la metti in un file(punto di debolezza) che carichi quando sale la Dll e la lettura del Guid la metti in una variabile.....fa pena....ma è sempre meglio che vederla scritta "in chiaro".....

Ciao !!

P.S. : per questo genere di cose, i lunguaggi di programmazione "semi-interpretati" come tutti quelli che interagiscono con il Framework.NET , sono i MENO indicati, per ovvie ragioni di "sicurezza"...

cipi
28-10-2004, 11.47.19
E se io invece includessi la classe nel progetto anzichè come dll esterna?
Sarebbe lo stesso facilmente leggibile?
Ma porcocan, .net non dovrebbe criptare gli exe che produce?

ceccus
28-10-2004, 11.51.04
Salve,
Sarebbe la stessa cosa.....ricorda che con "codice managed", ovvero codice gestito dal Framework , la "zuppa" è la solita.....sia che siano Dll, Asmx, Exe ....

Ciao !!

ceccus
28-10-2004, 11.54.23
Salve,
Con .NET puoi "firmare" i tuoi componmenti, in modo da creare una situazione di "trust" fra i tuoi oggetti.....
A tal proposito :

http://www.microsoft.com/italy/msdn/library/default.asp?url=/italy/msdn/library/pag/apparch/AppArchCh3.asp?frame=true

Buona lettura....

Ciao !!

cipi
28-10-2004, 12.03.03
Salve,
ora mi metto a leggere... Vediamo di capirci qualcosa in più... Certo che .NET ti aiuta nell sviluppo ma questo comporta un sacco di ulteriori problemi... :rolleyes:
A dopo... ;)

Larthal
29-10-2004, 14.33.41
Originariamente inviato da ceccus
Salve,
E allora , se le cose stanno così, ha MOLTO SENSO creare la Dll in C++ .......

Domanda da newbie: ma utilizzando le librerie System.Security.Cryptography si resta sempre e comunque fregati dal punto di vista della sicurezza o facendo parte del framework ci si deve solo preoccupare di non utilizzare password memorizzate nel codice? :confused:

ceccus
29-10-2004, 14.52.03
Salve,
Utilizzando le funzioni inserite nel namespace indicato (System.Security.Cryptography), praticamente, si va ad utilizzare il set di funzionalità delle Cripto API...le quali sono scritte in linguaggio "UnManaged" (C++) ....
Il discorso dell' amico CIPI, sembra essere diverso...però...
A quanto pare ha implementato un proprio algoritmo di criptatura e si preoccupa di non renderlo disponibile a terzi...
Se ho capito male, CIPI può intervenire e darmi tranquillamente "del bischero" (da Toscanaccio...)

Ciao !!

Larthal
29-10-2004, 15.10.14
Originariamente inviato da ceccus
...le quali sono scritte in linguaggio "UnManaged" (C++) ....

Ok, il mio dubbio era che anche il framework (esclusa mscorlib.dll) fosse "managed".

Grazie mille per la precisazione!

ceccus
29-10-2004, 15.17.50
Salve,
Alcune parti del Framework sono anch'esse "Managed" , ma nella fattispecie , quelle relative alla sicurezza NO (almeno per il momento....)
Prego...ci mancherebbe....

Ciao !!

cipi
29-10-2004, 17.30.40
Originariamente inviato da ceccus
Salve,
Il discorso dell' amico CIPI, sembra essere diverso...pero'...
A quanto pare ha implementato un proprio algoritmo di criptatura e si preoccupa di non renderlo disponibile a terzi...
Se ho capito male, CIPI puo' intervenire e darmi tranquillamente "del bischero" (da Toscanaccio...)

Ciao !!

Ciao ceccus,
ti do del BISCHERO perche' mi fa ridere... :D :D :D
...e anche perche' non e' cosi'... Ho utilizzato anch'io le funzionalita' di .NET
using System.Security.Cryptography;
ma le ho incluse in una dll anziche in una classe compilata con tutto il resto del codice e questo perche' dovevo renderla comune a piu' programmi e quindi era la via piu' semplice....
Il problema era (e ora non piu'... ;) ) che, essendoci dentro sia la funzione di crypting che di decrypting, erano utilizzabili da chiunque (essendoci dentro sia l'IV che la Key!!!)
Se non ci fosse stato il ceccus.... starei ancora imprecando!!!! :p

ceccus
29-10-2004, 17.35.02
Salve,
Ah,ah,ah,ah.......:D :D :D
:wall:

Come dice il saggio : "Tutto bene quel che finisce bene.....e l' ultimo chiuda la polta....GULP"...anzi "SuperGulp".....


Ciao !!

Larthal
29-10-2004, 17.41.23
Originariamente inviato da cipi


Ho utilizzato anch'io le funzionalita' di .NET ma le ho incluse in una dll anziche in una classe compilata con tutto il resto del codice e questo perche' dovevo renderla comune a piu' programmi e quindi era la via piu' semplice....

Ecco... allora siamo pari perché anche io ho optato per una soluzione del genere (creando un wrapper per RijndaelManaged).

Ma invece di includere IV e Key non era preferibile una classe che implementasse i metodi desiderati?

Ti faccio l'esempio mio: per creare un'istanza del wrapper (che pare un hamburger) al costruttore passo come parametro la password.

...ok che alla fine la Key da qualche parte la devi pure memorizzare... :confused:

cipi
29-10-2004, 18.10.18
Appunto... da qualche parte la devi memorizzare e se più programmi utilizzano la stessa chiave è meglio se fai come me e la metti in una dll...
A proposito... guarda questo sito qui (http://www.dotnetthis.com/Articles/Crypto.htm)... ha messo un po' di funzionalita' che possono tornare utili! ;)

Larthal
29-10-2004, 18.59.51
Interessante davvero!
Appena ho tempo lo leggo con cura!
Grazie! :-)

cipi
29-10-2004, 19.03.45
Figurati... ;)
Buon lavoro e alla prossima...

Larthal
06-11-2004, 11.42.15
Tre articoli interessanti sulla sicurezza degli assemblies .NET:

http://www.codeproject.com/dotnet/NeCoder01.asp
http://www.codeproject.com/dotnet/NeCoder02.asp
http://www.codeproject.com/dotnet/NeCoder03.asp