Questo sito utilizza cookie di terze parti per inviarti pubblicità in linea con le tue preferenze. Se vuoi saperne di più clicca QUI 
Chiudendo questo banner, scorrendo questa pagina, cliccando su un link o proseguendo la navigazione in altra maniera, acconsenti all'uso dei cookie. OK

Progettazione e realizzazione applicazioni web e back office con la piattaforma Microsoft .NET

L'anteprima di questa tesi è scaricabile in PDF gratuitamente.
Per scaricare il file PDF è necessario essere iscritto a Tesionline.
L'iscrizione non comporta alcun costo. Mostra/Nascondi contenuto.

Quando un compilatore produce un assembly, a meno di indicazioni specifiche, crea un assembly con nome non sicuro, il che significa che per riferirsi ad esso CLR utilizza il nome indicato nel manifesto, e non una firma crittografata. Tuttavia questo non è il solo tipo di assembly esistente, infatti si possono avere anche quelli con nome sicuro, il che significa che, nell’assembly è contenuta una chiave pubblica dell’editore ed una firma digitale. E’ la firma digitale, generata con la chiave privata dell’editore, e verificabile con quella pubblica, a rendere l’assembly a prova di intrusione. A questo punto è normale chiedersi quale tipo di assembly conviene utilizzare, se quelli a “nome non sicuro”, o quelli a “nome sicuro”; è chiaro che la scelta è influenzata del tipo di uso cui sono destinato gli assembly. Se l’assembly deve essere distribuito in modo tale da essere condiviso da più applicazioni, allora è opportuno che sia con “nome sicuro”; dovrà essere con nome sicuro anche nel caso in cui si voglia sfruttare la possibilità di effettuare un controllo sulle versioni (quando viene caricato un assembly, CLR confronta il numero di versione dell’assembly, con quello utilizzato per compilare l’applicazione che effettua il caricamento dell’assembly stesso). La scelta di effettuare o meno la verifica della versione, è una scelta dello sviluppatore, può costituire un vantaggio o uno svantaggio, infatti, sebbene limita la possibilità di errori (pensiamo al caso in cui venga, erroneamente, sostituito un assembly corretto con uno pieno di errori, il controllo della versione ci avvertirebbe), possono esserci delle circostanze in cui sarebbe meglio che la verifica non ci fosse, come ad esempio nel caso in cui si voglia sostituire un assembly difettoso con uno nuovo, riveduto e corretto; in quest’ultimo caso per permettere di utilizzare la nuova versione di assembly è necessario rigenerare l’applicazione.

Anteprima della Tesi di Andrea Curti

Anteprima della tesi: Progettazione e realizzazione applicazioni web e back office con la piattaforma Microsoft .NET, Pagina 12

Tesi di Laurea

Facoltà: Ingegneria

Autore: Andrea Curti Contatta »

Composta da 145 pagine.

 

Questa tesi ha raggiunto 2704 click dal 20/03/2004.

 

Consultata integralmente 6 volte.

Disponibile in PDF, la consultazione è esclusivamente in formato digitale.