Sitter just nu med produktsjefen (japp, han är norrman så det stavas så), i telefonen.

De håller på att bygga om hela vårt system i C#, och han vill nu att jag ska bygga om webbsiten.

För framtida planer undrar jag om man kan bygga siten i VB.Net och kunna integrera det med C# programmet senare.

Frågan är tyvärr om det kommer att behövas. men det viktigaste att veta är att jag i vilket fall som helst inte har en aning om hur programkoden kommer att se ut när det är klart under våren 2006.

Så, egna ideér och funderingar tas tacksamt emot.

Ska jag bygga sidan i VB.Net eller C# för ev. framtida behov, och om jag bygger den i VB.Net kommer jag att behöva göra om den i det fall den ska in i programmet...

Och vilket språk rekommenderas främst till detta projekt?

Daniel,

Inga problem att bygga olika delar av ett system i olika .NET kompatibla språk! Kör på bara om du/ni/han inte har några problem att ha flera språk i systemet. Samtliga .NET språk kompileras till MSIL (Microsoft Intermediate Language), en form av plattformsoberoende assembly, spåk. Ska man vara petig så vid exekvering så kompileras (Just-In-Time) även MSIL koden till native kod som sedan exekveras.

Eftersom du bygger på ramverket så är det inga problem. Har du fler frågor så säg till så ska vi nog kunna nysta ut eventuella frågetecken =)

Ett tips som jag har fått är att om du kan VB men inte VB.NET så är det bättre att lära sig C# än VB.NET.
Tyvärr kommer jag inte ihåg varför. Men C# är i alla fall trevligt.

Hej,

Tekniskt sätt så är det inga problem att blanda olika .net språk, däremot så kan det vara jobbigt att underhålla. Jag menar att om det t.ex. enbart är du som jobbar i vb.net och du sedan slutar så är det ingen som kan underhålla din kod. Vist, då är det inte längre ditt problem, men man kan ju vara schysst osså...

// Johan

Dock kan man inte blanda språk i en och samma dll/exe, mig veterligen.

Underbart svar.

Saken är så här.
Jag programmerar redan VB.Net men inte så mycket C#, är förvisso mycket intresserad av att komma igång med det med, därför är det frågan kommer upp.

Är det bättre om jag kör C# i allla fall kanske?

Sedan med att om jag är den enda som programmerar VB.Net så är det ingen fara, Utveckling sköts idag av ett mjukvaruföretag och jag är den enda utvecklaren av ramverket, så det är nog inga problem.

Man kan inte blanda DLL och EXE skriver ni, går det att hämta DLL som är skriven i C# med VB.Net?
Som jag förstår vår köra .NET moderator så borde det gå?

Men som sagt, jag har gått från VB till VB.NET och ni har rätt, jag har tyvärr gjort en massa ineffektiv kod på det sättet.

Så.. Kanske ska jag lära mig C# lit emer och utveckla ifrån det,
Men hur kommer en gammal asp / vb programmerare igång med det?
Antar att det inte finns några genvägar ;-)

Daniel,

Frågan om VB.NET vs C# är lika gammal som .NET Framework är - det finns en del små skillnader, men ofta handlar det om smaksak. Det är min fulla övertygelse att kan du VB.NET bra och inte har en ovana av att förlita dig på sakerna i <b>Microsoft.VisualBasic</b> namnrymden (de döljer vid logik som finns i själva ramverket) så kommer du lära dig att programmera C# på 1-2 veckor beroende på hur mycket tid du lägger ner. Det är helt enkelt inte mer (till 99.9%) mer än en syntax skillnad.

Du kan konsumer VB.NET dll (class librabry) filer från ett C# projekt och vise versa, men du kan inte inom <b>samma</b> projekt använda båda språken samtidigt, dvs du kan inte ha en fil minvbklass.vb och mincsklass.cs inom samma projekt. Förutom det finns det inga tekniska integrationshinder. Du har t.ex inte samma problem som om man tidigare arbetat med VB eller ngt annat språk är datatype har haft olika storlekar, med eller utan null terminering etc.. allt bygger på ett gemensamt typsystem (Common Type System, eller CTS) tillsammans med ett gemensamt regelverk (Common Language Specifikation) som språken skall (med vissa avvikelser) följa.

Daniel,
Om de du kommer att jobba för skall satsa på C# tycker jag det verkar klokast att du också skriver i C#. Det går att blanda och anropa DLL'er kors o tvärs. Inga som helst problem. Men långsiktigt är det källkoden som spelar roll. Om du försvinner och deras C#-kådare ska ta över din "hemmasnickrade" VB kod kommer det inte att vara populärt. Jag är VB.NET kådare men skulle i det här fallet rekommendera C# (samt att du tar del av deras metodik, namnstandarder osv..).
Dessutom breddar du din egen kompetens med flera mil.. :)

Jag använder mycket "throw away prototyping". Och skriver då först i VB.NET. Och för att säkerställa att det verkligen blir "throw away prototyping" och inte som i många fall att man levererar en prototyp så skriver jag om det i C#!

Funkar bra för mig. Är ingen större skilnad på VB.NET och C# mer än att man kan sätta upp ett "keyword" till i sitt cv.

Det är bra svar allihop, har nu överlagt lite med mina chefer med dessa åsikter och det blir så att jag får åka till företaget som utvecklar "huvudprogrammet" och jag saka titta på den utvecklingen samt att ansvara även för den, jag men kommer enbart att koda ramverket själv.

Allt detta kommer att bli i C#.
Tackar för all hjälp jag har fått.
/Daniel Wiberg

Översättning mellan VB.Net och C#
http://www.codeproject.com/dotnet/vbnet_c__difference.asp

En suverän konverteringssida!
Här går det att konvertera kod från C# till VB.NET och tvärtom:
http://www.developerfusion.co.uk/utilities/convertvbtocsharp.aspx

Jo den typen av konverterare är trevliga, men bör av uppenbara anledningar inte användas när man skriver produktionskod. Ska man byta från en syntax till en annan så är det viktigt att man lär sig vad den nya syntaxen har att erbjuda för unika saker. En skillnad t.ex är att C# idag (VB.NET kommer från och med nästa version ha motsvarande funktionalitet) har ett nyckelord som heter <b>using</b> som är väldigt användbart.

Varför skulle inte en VB.NET -> C# konverterare känna till det? Visst skulle den det, det svåra är att känna igen när det bör/skall användas. För using översätts av kompilatorn till ett explicit antop till <b>Dispose</b> metoden på objektet man deklarerar för using-blocket. Att kunna tolka kod och förstå om det är säkert att ta ett eget anrop till Disposing och översätta det till using-block är inte helt trivialt.