Guida Conversione C#->VB.Net e viceversa

[JustARegularGuy]

Quanti di voi hanno iniziato a studiare C# e vogliono portare il loro vecchio progetto VB.Net verso il nuovo linguaggio C#?
Sicuramente la prima cosa che vi siete chiesti sarà stato "Dovrò davvero scrivere tutto da capo? Non esistono tool a riguardo?", ed io vi rispondo SI i tool esistono ma funzionano al 70%.

Con il progresso del C# sono stati creati tanti package che per VB.Net non esistono e quindi non "traducibili", perciò se sono programmi fatti letteralmente da 0 e senza utilizzo di package esterni avrete una buona possibilità di tradurre solo con l'utilizzo del converter altrimenti nel miglior dei casi il tool vi farà la conversione e vi toccherà "pulire" il codice o nel peggiore dei casi, riscrivere tutto!
Ancora peggio se si tratta di convertire soluzioni abbastanza avanzate di VB.Net in C# in quanto sicuramente vi ritroverete a dover riscrivere grosse porzioni di codice da riscrivere da capo come ad esempio, se si usano degli array, il programma non è in grado di sostituire le parentesi tonde di VB con le quadre di C# e vi ricordo che il C# è case-sensitive e quindi la conversione di alcuni variabili/metodi risulteranno un grosso problema.

Vi lascio ora i vari tool utilizzabili online testati personalmente con buoni risultati:
Telerik Converter
DeveloperFusion

Inoltre se utilizzate Visual Studio avete a disposizione il plugin da utilizzare offline:
Plugin VS

 

[nfvblog]

Quanti di voi hanno iniziato a studiare C# e vogliono portare il loro vecchio progetto VB.Net verso il nuovo linguaggio C#?
Sicuramente la prima cosa che vi siete chiesti sarà stato "Dovrò davvero scrivere tutto da capo? Non esistono tool a riguardo?", ed io vi rispondo SI i tool esistono ma funzionano al 70%.

Con il progresso del C# sono stati creati tanti package che per VB.Net non esistono e quindi non "traducibili", perciò se sono programmi fatti letteralmente da 0 e senza utilizzo di package esterni avrete una buona possibilità di tradurre solo con l'utilizzo del converter altrimenti nel miglior dei casi il tool vi farà la conversione e vi toccherà "pulire" il codice o nel peggiore dei casi, riscrivere tutto!
Ancora peggio se si tratta di convertire soluzioni abbastanza avanzate di VB.Net in C# in quanto sicuramente vi ritroverete a dover riscrivere grosse porzioni di codice da riscrivere da capo come ad esempio, se si usano degli array, il programma non è in grado di sostituire le parentesi tonde di VB con le quadre di C# e vi ricordo che il C# è case-sensitive e quindi la conversione di alcuni variabili/metodi risulteranno un grosso problema.

Vi lascio ora i vari tool utilizzabili online testati personalmente con buoni risultati:
Telerik Converter
DeveloperFusion

Inoltre se utilizzate Visual Studio avete a disposizione il plugin da utilizzare offline:
Plugin VS

ha senso portare il VB.net in c# ma non vice versa, il VB.net è vecchio e sta diventano un linguaggio morto o quasi, perché ormai si porta male i suoi anni, anche se sono al corrente della sua importanza nell'ambiente microsoft, visto che è uno dei linguaggi nativi per Windows

 

[Predator]

ha senso portare il .net in c# ma non vice versa, il VB.net è vecchio e sta diventano un linguaggio morto, perché ormai si porta male i suoi anni

Hai scritto una cosa 100% sbagliata.
Innanzi tutto non porti il C# in .NET, in quanto C# è un linguaggio di programmazione della famiglia del .NET/DotNet.
Probabilmente confondi VBNet con VB6. Dal punto di vista del risultato finale C# e VBNET sono 100% identici salvo per la gestione dei puntatori ai quali li VBNET accede tramite la classe Marshal e un altra manciata di cose. Il VBNET si presta più user friendly soprattuto nella generazione automatica degli eventi, lo possiamo definire più vicino alla lingua parlata. Il C# presta molta più famigliarità a linguaggi C like e pertanto java like.
Dal punto di vita prestazionele sono identici, che sia C# o VBNET tutto passa per il JIT che si occupa di compilare a runtime il codice IL e trasformare tutto in codice nativo per poi eseguirlo.

 

[nfvblog]

Hai scritto una cosa 100% sbagliata.
Innanzi tutto non porti il C# in .NET, in quanto C# è un linguaggio di programmazione della famiglia del .NET/DotNet.
Probabilmente confondi VBNet con VB6. Dal punto di vista del risultato finale C# e VBNET sono 100% identici salvo per la gestione dei puntatori ai quali li VBNET accede tramite la classe Marshal e un altra manciata di cose. Il VBNET si presta più user friendly soprattuto nella generazione automatica degli eventi, lo possiamo definire più vicino alla lingua parlata. Il C# presta molta più famigliarità a linguaggi C like e pertanto java like.
Dal punto di vita prestazionele sono identici, che sia C# o VBNET tutto passa per il JIT che si occupa di compilare a runtime il codice IL e trasformare tutto in codice nativo per poi eseguirlo.

Il Visual basic non è il massimo della vita, onestamente, il .NET ha i suoi vantaggi e i suoi svantaggi, ha ovviamente i suoi perché, ma il modo in cui è stato pensato non mi fa proprio impazzire tutto qui, poi il fatto che resti relegato ad una singola piattaforma è limitante, tanto che la maggioranza delle aziende predilige linguaggi come il Java e il Python

 

[JunkCoder]

Come dice Predator, una volta "compilati" C# e VB.NET sono pressoché identici (IL opcodes). Può non piacere la sintassi, infatti preferisco C# per quello, ma restano equivalenti, tant'è vero che puoi combinare trasparentemente eseguibili e librerie scritte nei due linguaggi, anche tramite reflection. Mi sembra di capire che quando dici .NET ti riferisci a VB.NET, ma .NET è la piattaforma su cui entrambi i linguaggi si basano e il motivo per cui scrivendo VB si aggiunge .NET è per distinguerlo dalle precedenti versioni VB non basate su di esso. La stessa cosa vale per ASP e ASP.NET, mentre C# è stato basato su .NET fin dalla prima versione.

 

[nfvblog]

Come dice Predator, una volta "compilati" C# e VB.NET sono pressoché identici (IL opcodes). Può non piacere la sintassi, infatti preferisco C# per quello, ma restano equivalenti, tant'è vero che puoi combinare trasparentemente eseguibili e librerie scritte nei due linguaggi, anche tramite reflection. Mi sembra di capire che quando dici .NET ti riferisci a VB.NET, ma .NET è la piattaforma su cui entrambi i linguaggi si basano e il motivo per cui scrivendo VB si aggiunge .NET è per distinguerlo dalle precedenti versioni VB non basate su di esso.

né sono al corrente, semplicemente la sintassi di VB non è comoda e per questo motivo comunque sta sparendo, è meno utilizzato rispetto al passato, C# effettivamente ha un ottima integrazione con Windows e ha anche una sintassi molto più comoda, non sarà perfetto manco quello ma VB è decisamente peggio

 

[Predator]

né sono al corrente, semplicemente la sintassi di VB non è comoda e per questo motivo comunque sta sparendo, è meno utilizzato rispetto al passato, C# effettivamente ha un ottima integrazione con Windows e ha anche una sintassi molto più comoda, non sarà perfetto manco quello ma VB è decisamente peggio

No la sintassi VB è notoriamente più vicina all'uomo e non sta sparendo. Il C# essendo un linguaggio C like è per forza è più diffuso. A parità di risultato la scelta del linguaggio è soggettiva. Parlare di integrazione con Windows non ha senso, è un linguaggio

Messaggio unito automaticamente: 22 Gennaio 2022

Il Visual basic non è il massimo della vita, onestamente, il .NET ha i suoi vantaggi e i suoi svantaggi, ha ovviamente i suoi perché, ma il modo in cui è stato pensato non mi fa proprio impazzire tutto qui, poi il fatto che resti relegato ad una singola piattaforma è limitante, tanto che la maggioranza delle aziende predilige linguaggi come il Java e il Python

Qui parli di VBNet che è un linguaggio confuso con .NET che è un framework. Una cosa è un linguaggio, una cosa completamente diversa è il prodotto compilato di tale linguaggio. Paragonare poi un linguaggio che può essere compilato in nativo con un liguaggio come il java che ha una altissima astrazione dall'OS, scusa non ha proprio senso. Cosa ancora diversa per Python. Non so mi sembra che hai un po' di confusione sull'argomento del Dotnet/Net

 

[nfvblog]

No la sintassi VB è notoriamente più vicina all'uomo e non sta sparendo. Il C# essendo un linguaggio C like è per forza è più diffuso. A parità di risultato la scelta del linguaggio è soggettiva. Parlare di integrazione con Windows non ha senso, è un linguaggio

Messaggio unito automaticamente: 22 Gennaio 2022

Qui parli di VBNet che è un linguaggio confuso con .NET che è un framework. Una cosa è un linguaggio, una cosa completamente diversa è il prodotto compilato di tale linguaggio. Paragonare poi un linguaggio che può essere compilato in nativo con un liguaggio come il java che ha una altissima astrazione dall'OS, scusa non ha proprio senso. Cosa ancora diversa per Python. Non so mi sembra che hai un po' di confusione sull'argomento del Dotnet/Net

Io ho studiato C per anni, alla fine sono abituato a quella sintassi, per quanto riguarda il java e il python più che altro sono i linguaggi che le aziende ti richiedono al momento, onestamente il .net l'ho visto diverso tempo fa e onestamente non è mai stato di mio personale interesse, so che comunque per programmare applicativi per windows è fondamentale essendo una piattaforma di sviluppo dedicata, che ultimamente è dentata disponibile per altre piattaforme come linux e mac, ho ridato proprio oggi uno sguardo alla documentazione e noto diversi errori in quello che ho scritto, sia perché non lo rivedo da 5 anni e anche per altre cose che ricordavo differenti per sintassi, ovviamente ci sono molti aspetti che per forza di cose dovrò rileggermi per la connettività client/server su windows server.

 

[Predator]

Io ho studiato C per anni, alla fine sono abituato a quella sintassi, per quanto riguarda il java e il python più che altro sono i linguaggi che le aziende ti richiedono al momento, onestamente il .net l'ho visto diverso tempo fa e onestamente non è mai stato di mio personale interesse, so che comunque per programmare applicativi per windows è fondamentale essendo una piattaforma di sviluppo dedicata, che ultimamente è dentata disponibile per altre piattaforme come linux e mac, ho ridato proprio oggi uno sguardo alla documentazione e noto diversi errori in quello che ho scritto, sia perché non lo rivedo da 5 anni e anche per altre cose che ricordavo differenti per sintassi, ovviamente ci sono molti aspetti che per forza di cose dovrò rileggermi per la connettività client/server su windows server.

Hai dato una risposta ottima, non ho nulla da aggiungere. E complimenti per aver ammesso qualche svista dovuta ad un ricordo passato

 

[nfvblog]

Hai dato una risposta ottima, non ho nulla da aggiungere. E complimenti per aver ammesso qualche svista dovuta ad un ricordo passato

Quando si sbaglia è giusto ammetterlo