Jeg tænkte umiddelbart ikke på direkte embedded kode, idet at html bliver skrevet af en helt tredje person, men primært på codebehind filer (eller src for den sags skyld), der i visse aspx filer skal referere til en .cs source fil og andre til en .vb source fil, på en måde, således at vs.NET kan både håndtere det og kompilere det.
Men som sagt, det kan være at jeg beder om for meget...
-- det er præcis det punkt hvor .NET er genial, for alle former for kompileret kode vil kompileres til JIT-kode, som næsten vil være den samme uanset udviklingssprog ...
-- så et projekt kan, som arne_v gør opmærksom på, ganske udmærket udføres af en webdesigner, som laver selve .aspx-filen, f.eks. en c#-programmør, som laver den core .aspx.cs-fil, samt adskillige andre programmører, som laver diverse utilities i C#, VB.NET, J#, JScript.NET og kompilerer dem til JIT-kode !-)
En forms eget code behind kan være hvad som helst. Problemet at er conditional compile stadig ikke fungerer så godt, så man må som arne foreslår benytte et dll til at ineragere. Du kan jo godt lave vb form klasser, eller page nedarvere som du så laver dine udvidelser i og så inherit'e hele namespacet fra dll'et så du kan lave sådan en præcis knap eller form, eller div eller dataaccessobject som util.vb leverer
Men du kan ikke lave code behind i VB.Net i et projekt som kompilerer i C#.Net web application project endnu, men jeg tror at det er på trapperne.
ellers må man bare have to projekter... et vb.net og et c#, og i disse to projekter befinder der sig så de respektive codebehind-klasser skrevet i henholdsvis vb.net og c#.
roenving>> det du tænker på er vel MSIL og ikke JIT. JIT betyder Just In Time, og kan ikke bruges til at navngive/kategorisere et sprog, men bruges om en process. F.eks. JIT-compilering.
Jeg synes det lyder som en rodet affære. Jeg har selv skulle merge to web projekter skrevet i forskellige sprog... Jeg endte med at lave to projekter der lå samme sted, og med samme bin mappe. Det fungerer, men kan helt sikkert ikke anbefales.
Jeg synes helt klart at i skulle blive enige om et sprog og lave det hele i det. Hvis man kan ét .Net sprog er det jo ikke så svært at lære et andet. Og så går arkitekturen heller ikke i vasken bare fordi i skal være flere om det.
I modsætning til så mange andre synes jeg ikke at undestøttelse af flere sprog er en fordel ved .Net. Derfor! Vælg et sprog og hold jer til det.
At omskole en programmør fra vb eller asp til vb.net tager væsentligt kortere tid af lav produktion, så derfor bør man bruge namespaces til at adskille de forskelligt kompilerede dele og siden bruge imports, så kan det gøres med minimal gnidning. men det betyder naturligvis at vi ikke har nogen brug for c# programmørere i projekter hvor vb.net bruges til at binde asp sammen med server side session objekter og logik. Jeg mener at det taler for fler-tier arkitektur, så alle kan udfolde sig optimalt i deres egne namespaces. På den måde behøver logik og datapræsentation t.eks ikke at blive lave af samme person, eller i samme sprog, så ved at lade gamle asp (perl folk vil have nemmere ved c# tror jeg, kan evt. bruges til web controls) kode med webcontrols og databinding, så kan html/script folk lave asp.net html'en imens virksomhedens CLR.Net pionerer på få enkelte hænder laver virksomhedens logik i inkluderbare namespaces. som når forankret kan lære objekt brug og adfærd til de som binder frontends, imens designerne kan gå igang med den næste opgave... men det kræver at man er mindst 3, ellers er samarbejdskompatabiliteten i projekter måske også en sekundær overvejelse :D
Det tager kort tid for en vb programmør at lære at skrive sin første kode i VB.Net.. men det er ikke syntaksen der er det svære ved at programmere, det er selve tankegange, og at lave en løsning der også holder om 2 år. Hvis man lader en vb programmør skrive VB.Net applikationer, vil disse applikationer med garanti være lavet som gamle VB applikationer... dvs. modules, ingen nedarvning, ingen brug af interfaces, brug af late binding etc. Derfor mener jeg godt at det kan anbefales at vælge at bruge C# selvom man har nogle VB programmører i forvejen.
Simpelthen for at tvinge programmørerne til at lære .Net
runesoft >> Jep. Netop selve eventsbaseringen er dog helt lig med vb, så det er for så vidt det samme man skal lave, men der er visse ting, som nedarvning og i det hele taget OOP er måske ikke noget en VB programmør kender, men hvis man husker at fortælle dem at en web form grundliggende er som en windows form. Bagved er der naturligvis den forskel at selv VB6 var ikke implementeret som objekter, selvom de opførte sig sådan, og det er de nu. Det betyder dog ikke det helt store i praksis. Du har nedarvning i VB det eneste du ikke kan bruge i den forbindelse er multipel nedarvning, det behøver man også kun i et par procent af faktiske situationer. C# er ikke rentablelt, hvis du ikke har programmørere som kender C eller lign i forvejen. Naturligivs vil de ikke programmere som i VB. Du starter naturligvis med at købe en bog som er skrevet til at introducere VB programmørere og hvis de læser så skriver de allede i uge et applikationer i .net som tilsigtet. Jeg synes ikke at du kan antage at programmørerne nødvendigvis er dovne, som argument til at vælge C slap *gg*
.Net's events er vel ikke ligesom VB's. VS.Net autogenererer bare kode således at det kan se sådan ud. Jeg er som sådan ikke imod VB.Net... Jeg synes bare de skulle koncentreret sig om ét sprog... så havde IDE'en sikkert også fungeret bedre.
Jeg tror simpelthen ikke på at VB programmør kan blive gode .Net programmører på en uge!
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
