Originariamente inviato da web@web
con vb.net ho sentito dire che, essendo compilato in metacode, i decompilatori hanno vita più facile.
Il linguaggio intermedio è un linguaggio assembler di livello più alto e reversibile con più facilità.

Originariamente inviato da web@web
Ma quanto?
Partendo da un exe che realizzo io, a che risultato può arrivare un decompilatore? Quello che intendo è se chi lo usa un decompilatore può arrivare a vedere per intero il listato del codice vb.
A seconda del compilatore utilizzato, vengono operate delle ottimizzazioni sul codice sorgente, pertanto non è possibile risalire alla forma originale del codice che ha prodotto un determinato eseguibile, sebbene sia possibile ottenere la traduzione del codice IL in uno qualsiasi dei linguaggi che supportano il .NET Framework.

Alla base di questa scelta ci sono vari motivi architetturali che si incentrano sulla necessità di apertura del framework ad un concetto di integrazione generale.

Il problema del copyright e della protezione di algoritmi è una questione giuridica, che va protetta con mezzi adeguati indipendentemente dalla semplicità con cui il codice prodotto può essere disassemblato.

Nel caso del .NET Framework, quando le esigenze professionali lo impongono, è consigliabile - come in altri ambienti e linguaggi, peraltro - ricorrere ad un offuscatore (obfuscator) in grado di "confondere le acque" e rendere più difficile risalire dal codice (nativo o intermedio che sia) alla forma (quasi) sorgente.

Comunque, il .NET Framework è stato ideato con la prerogativa di risolvere logiche di business decisamente complesse, integrando classi e soluzioni anche eterogenee...in presenza di un progetto di rilevanti dimensioni, non è comunque detto che sia semplice decifrare il "crudo sorgente" ottenuto sfruttando uno dei tanti disassemblatori, poichè si dovrebbe analizzare l'intera struttura di classi e strutture dati del progetto per avere una visione completa della soluzione invece di un semplice "brandello" di codice dell'applicazione.

Ciao!