Jag är ingen utvecklare utan sitter och kodar lite sporadiskt vid sidan av allt annat.

Jag har en ärvd applikation som är kodad i vb 6 och börjar tycka att det känns lite gammalt... Har börjat fundera på att gå över till visual studio 2005.

Är det någon idé? Vinner man mycket på att gå över? Hur jobbigt är det att konvertera till vb.net?

Ska jag tänka i andra banor, vad finns det för alternativ?

Som ni märker är jag ganska grön på det jag frågar om men om någon kan stötta mig i en eller annan riktning så vore jag tacksam.

/Knut

Hej Knut,Är det något som du tjänar pengar på eller kan få betalt för eller för att lära dig är svaret självklart. Oftast är det enklare att ha något konkret att börja med när man skall gå över till objektorienterad programmering som .Net är.

Mycket löses av importen som är inbyggd i VS.Net, det är bara att öppna ett VB6-projekt så konverterar guiden så mycket den kan. Observera dock att det blir VB6-kod skriven i .Net, dvs oftast inte speciellt snyggt...den "objektifierar" ju inte koden, så bra är den inte :-)

Problemet är oftast tredjepartskomponenter i GUI:t som inte har någon motsvarighet i .Net, t ex griddar, trädstrukturer e t c. Har du många sådana icke-standard-komponenter så blir det jobbigt att uppgradera.

Att byta utvecklingsmiljö för att "det känns lite gammalt" är i mitt tycke ett dåligt skäl. Se till att kunna språk, miljö och bibliotek för vad du funderar på att byta till innan du gör ett byte.

Förmodligen är det enklare att göra en nyutveckling (och undvika "version två"-problemet).

Personligen skulle jag tipsa om ett annat språk än just VB.NET.

<b>Personligen skulle jag tipsa om ett annat språk än just VB.NET. </b>

Håller med till 100%, VB.Net är <b>OANVÄNDBART</b> i stora projekt p g a att bakgrundskompileringen inte går att stänga av. Tänk på det om du skall dra igång ett stort projekt (kanske inte aktuellt just nu om du är "grön")...Rekommenderar ändå C#/mC++ framför VB.Net...

Per, har du någon länk som beskriver problematiken ytterligare?

OK, tack för all respons.

Valet verkar stå mellan vb.NET och C#, där det sistnämnda verkar vara den mest rätta vägen att gå. Jag får ändå en känsla av att det är det mest krävande valet...

Jag ska kolla runt lite och testa lite för att få mer underlag.

Det är inte svårare att gå från Vb6 till C# än VB 6 till VB .Net.
Faktiskt rätt trött på alla som tror detta...

Allt är syntax så som for, if, int, deklaration av objekt... så mkt mer är inte språket.
Det tog mig knappt en eftermiddag att gå över från VB .Net till C# jag tänkte som er
jag kan VB då kan jag VB .Net men lovar att det var mycket krångligare att gå från
VB 6 till VB .Net än från VB 6 till C#... Av många skäl, men mest syntaxbaserade skäl,
VB .Net har en massa idéer och massa namn på syntax som man måste lära sig vilket
du inte behöver bry dig om i C# etc... C# blir även mycket mer lättläst än VB .Net pga att
det är bättre strukturerat, du kommer arbeta både snabbare, effektivare och ha lättare att
läsa och hitta i C# kod än i VB .Net kod.

Mvh Johan

Tack för det svaret Johan.

Ska kolla lite närmare på C#.

Lars-Erik:

Min kritik ang VB.Net i stora projekt bygger på erfarenhet, jag har inte sett några sidor där MS erkänner att bakgrundskompileringen är ett problem, däremot är det många som önskar möjligheten att kunna stänga av denna. Sök på "background compiling vb.net" så hittar du en del...

I det projekt jag sitter i nu så får jag vänta alltfrån en sekund upp till 15 sekunder efter att man skrivit en kodrad och tryckt enter, under tiden är CPU:n uppe i 100%. Det är ändå ingen dålig maskin jag har (Dual 2.8 GHz, och 3Gb RAM). Det är givetvis helt förödande för produktiviteten, otroligt frustrerande med oönskade mikropauser...dessutom kraschar VS.Net lite då och då, när CPU:n är maxad. OutOfMemory är inte ovanligt vid kompilering trots att jag har 3 Gb och endast < 2 Gb är utnyttjat enligt taskmanager...

Vi är fyra utvecklare och alla har samma problem med prestandan. Antalet krascher av VS.Net per dag varierar men ibland fler än 10 på en dag (tror 14 är rekordet för EN utvecklare)...Att öppna ett kod-fönster kan ta upp till 20-30 sekunder, lite beroende på om det är en VB-fil (lite snabbare) eller ASPX-fil (med en massa javascript, hemskt slött). Att öppna hjälpen (F1) har jag helt slutat med f ö, går mycket snabbare att starta IE och googla än att starta hjälpen.

Skall för säkerhets skull tillägga att inga av dessa problem upplever jag i C#-projekt, varken minnesproblemen, prestandaproblemen eller krascherna även om jag inte f n är med i något lika stort C#-projekt som VB.Net-projektet. Men man ser inte ens tendenser till samma problem i C#-projekt...Jag vet inte heller om det beror på att VB.Net-projektet är ett webprojekt och C#-projekten jag håller på med är WinForm-applikationer. Eventuellt spelar det också in...

Så länge MS inte ger oss möjligheten att stänga av bakgrundskompileringen så anser JAG att VB.Net är OANVÄNDBART i stora projekt, och jag varnar alla för att påbörja projekt, som de vet kommer att växa, i VB.Net.

Det är intressant information du kommer med, Per. När räknas ett projekt som "stort"?


/Thomas

Är det skillnad på bakgrundskompileringsproblemet med vb.net och C# i VS ?

Gäller problemet bara asp.net eller även winforms?


mvh Roland

Äntligen har jag fått medhåll på det jag kräktes över för några år sedan.

Vb.net är ett djäv.. "shitt" som aldrig skulle fått se dagens ljus.
Håller med till tusen. Skall du konvertera till annan plattform så är det C++ eller C# som gäller.
Själv blev jag kär i Delphi som är lika bra som de ovan nämnda.

Thomas:

Vet ej, det aktuella projektet har ca 15 komponenter, och har ungefär 5000 filer MEN då har jag bara högerklickat på mappen i utforskaren och valt egenskaper så antalet filer inkluderar alla DLL:er, debugfiler etc...

Roland:

Ja, C# har ingen riktig bakgrundkompilering, den kollar endast lite syntax-saker. Du måste själv kompilera för att få fram ev kompileringsfel som inte är rena syntaxfel.

Det aktuella problemprojektet är asp.net, så det kan vara relevant. Jag håller också på med ett relativt stort C#-winforms-projekt och där är det inga som helst bekymmer med prestandan i utvecklingmiljön.

Ok, men då har jag nog ett tag kvar innan jag går i taket. Mina projekt ligger på ca 500-700 filer styck så även om det inte går att jämföra rakt av så är nog ditt projekt något större =)

Sen så programmerar jag mest på hobbynivå och då brukar väl projekten inte bli så stora...


/Thomas

Men, vad vinner man egentligen då på att gå över till C# ?
Dvs. om ett C#-program egentligen är att betrakta som ett VB-program med annan syntax ?

Då blir ju frågan om språkval egentligen en fråga om vilket språk det finns kunskap om (ex. i communities/forum) och hur mycket exempelkod man kan hitta på "nätet" ?

Personligen så tyckte jag att det verkar som att VB.NET blir mer och mer likt VB6 för varje version
och att det i sig gör att det är enklare att konvertera och skriva VB.NET-kod när man redan är van VB6.

Att det blivit så antar att det beror på att VB6-programmerarna inte tagit till sig .NET i den takt som MS önskat och att de känt sig tvingade att lägga till gamla VB6-nyckelord istället för att som i de tidigare VS.NET hänvisat till ramverket.



/Johan

Man fastnar väldigt lätt i fulkod om man hoppar från vb 6 till vb.net..

För att slippa problemet med att man kodar "VB6-kod" i VB.NET så räcker det väl med att ta bort referensen till Microsoft.VisualBasic?

Det gjorde jag från första stunden jag gick över till VB.NET och jag har tyckt att övergången har gått problemfritt. Visst försökte jag tex med Msgbox istället för Messagebox.Show i början, men eftersom jag hade plockat bort Microsoft.VisualBasic så fungerade det inte och då var jag tvungen att leta på internet hur man skulle göra istället.


/Thomas

>Men, vad vinner man egentligen då på att gå över till C# ?
>Dvs. om ett C#-program egentligen är att betrakta som ett VB-program med annan syntax ?

Tjaaa du... Vad skall man svara på det?
1... Det är lättare att läsa Java kod då, Java idag ligger före med massa trevliga mönster, ramverk
idéer och saftiga böcker så underlättar förståelsen för det.
2... Syntaxen är genrellt mkt kortare skriven vilket gör att du spar tid i skrivandet, tid är pengar.
ex. Inheritz = : sparar 7 tecken, slipper skriva Hadles bla bla för event, slipper skriva dim och as
slipper skriva en massa end if, o next o sånt jobbigt. bara här är det ca 25 tecken mindre o tänk dig
då i ett stort projekt ;-)
3... Mer lättläst (smaksak kanske) men suttit med vb och C# och tycker lätt att C# minskar tiden man
lägger ner på läsa koden för ev hitta fel eller review...
4... De flesta exempel som finns där ute på nätet är skrivna i C# före VB.

Det är väl några skäl och eftersom det är som du säger bara syntax så varför inte ta det språk med mest fördelar då ;-)

mvh Johan

>1... Det är lättare att läsa Java kod då, Java idag ligger före med massa trevliga mönster, ramverk
> idéer och saftiga böcker så underlättar förståelsen för det.

Ok,

>2... Syntaxen är genrellt mkt kortare skriven vilket gör att du spar tid i skrivandet, tid är pengar.
> ex. Inheritz = : sparar 7 tecken, slipper skriva Hadles bla bla för event, slipper skriva dim och as
> slipper skriva en massa end if, o next o sånt jobbigt. bara här är det ca 25 tecken mindre o tänk dig
> då i ett stort projekt ;-)

Ok, men det känns inte som något stort problem i och med att VS autokompletterar på olika sätt.
Det är klart, vore man fast i EDLIN så.. ;-)


>3... Mer lättläst (smaksak kanske) men suttit med vb och C# och tycker lätt att C# minskar tiden man
> lägger ner på läsa koden för ev hitta fel eller review...

Det har du nog rätt i, C# är mindre "pratigt" och det borde i teorin ge en bättre överblick över själva programlogiken.
Men, det kräver ju å andra sidan att man har C#-syntaxen "i ryggmärgen".

>4... De flesta exempel som finns där ute på nätet är skrivna i C# före VB.

Det är en viktig punkt, fast jag tycker nog att antalet VB.NET-artiklar har exploderat sen VS2005.
Fast om det beror på att man i princip numera kan skriva VB6-kod i VB.NET eller om det beror på expressversionerna, det vete tusan.

/Johan

>Ok, men det känns inte som något stort problem i och med att VS autokompletterar på olika sätt.
Jo men faktum är att koden blir större i alla fall

>Men, det kräver ju å andra sidan att man har C#-syntaxen "i ryggmärgen". >
Jag gick faktiskt från V6 till VB .Net för jag trodde det var enklast, men det var det inte, så efter 2
dagar kastade jag mig in i C# och efter 3h satt syntaxen i ryggmärgen :-) det är inte så knöligt egentligen.

public function Foo() as string
end function

vs
public string Foo()
{ }

Dim name as String = "Nisse"
vs
String name = "Nisse";

Dim myFooObject as FooObject = new FooObject()
vs
FooObject fooObjecrt = new FooObject();

Typ...
Man säger typen först bara och sen har { } iställer för end saker... O har man skrivit Javascript ja
då borde C# nästan sitta i ryggraden nu!

Ja nä. man skall välja det språk man tycker är snyggas o som ger än själv mest fördelar i långa loppet.
Men tänkt inte tanken, jag satt med VB6 då är VB .Net lättare för det är det inte, det är nästen mer
att lära sig där mellan än VB6 --> C#, ha det i tanken i alla fall...

Lycka till oavsett språk... .net är kul :-)

Mvh Johan