Begynder niveau.. Med Visual Studio.net installeret kan det ikke blive nemmere at lave applikationer til windows og webforms til browsere. Framework er den bagved liggende teknologi. (Hvor bliver det sjovt når/hvis Bill releaser en runtime del til alle øvrige OS)
Det er så nu samtlige anti-M$ zealots med samlet røst begynder at råbe og skrige i vilden sky... Men men men, da man jo ikke er en af dem, holder jeg kaje. ;)
Det skulle ligne Microsoft meget dårligt at begynde at lave programmer til Open Source platforme, som jeg synes de indtil videre ikke rigtig har taget særlig alvorligt. Desuden ville jeg for eksempel personligt være meget mere tryg ved en Open Source version af .NET Frameworket (som Mono jo er) end en Microsoft-made en...
simon.ulsnes>> de hjælper nu ellers flittigt med til at gøre Mono til en realitet... de har jo også interresse i at få portet deres framework til andre platforme. Eller.. har de ;)
Der er jo også lavet en open-source version af Visual Studio... sårn, da. CSharpDevelop.
Yesyes - bortset fra med System.Web, System.Drawing og System.Windows.Forms, hjælper de flittigt... Det vil sige tre af de allervigtigste namespaces. Mono-folkene har tilmed følt sig tvunget til at basere SWF på Wine, af hensyn til nogle API-kald og deslige. Så for at køre SWF-applikationer på andet end Windows, skal man altså også have Wine (www.winehq.com).
Og selv om CSharpDevelop er Open Source (og i øvrigt et godt stykke af vejen til at være på højde med VS.NET), kan det stadig ikke køres på non-Windows platforme før System.Windows.Forms og System.Drawing (mindst) er færdiggjorte. Så det er problematikken for øjeblikket.
simon.ulsnes>> Tjaa... jeg synes det går meget godt for dem, og det skrider hurgigt frem. Både for winforms og webforms. Og det er da klart at de har svært ved netop disse to dele, da det på windows er baseret på GDI og IIS, mens Mono ikke har disse to ting at gøre godt med. Det gør det jo også svært for Microsoft at hjælpe.
Du har fuldstændig ret cyberfessor. For mig er det underordne om Bill eller andre udvikler Runtime delen til andre OS, bare den bliver udviklet og release't snart. Desværre går der nok et par år før end alle har den i sin browser og indtil da må jeg leve med en manglede grafisk brugerflade på client-siden. Jeg bruger ordet manglende fordi verdens rigeste mand ikke understøtter de eksisterende.
wired >> Hvad mener du med "før alle har den i sin browser"? begge to >> Når nu det er at Mono-folkene har besluttet at bygge SWF på Wine, mon så ikke de ville kunne drage nytte af Microsofts version? Men, nevertheless, så er SWF, System.Web, System.Drawing (tror jeg) og nogle flere (vigtige!) namespaces slet ikke med i CLR-ECMA-standarden, så i virkeligheden behøver man ikke de namespaces for at have et (i princippet) fuldstændigt .NET Framework. Nu er det bare sådan at det er svært at finde på noget at bruge .NET Frameworket til hvis man hverken har SWF eller System.Web at lege med.
cyberfessor >> System.Web har i sig selv ikke mange forbindelser til IIS, det er (så vidt jeg ved) sådan set kun en ordenlig bunke klasser (WebControls og deslige) uden alt for mange API-kald. I princippet burde det ikke være supersvært at udvikle selve WebControls'ne, der er bare rimelig mange og det kommer til at tage tid, ud over at det vil tage tid at skrive en ordenlig ASP.NET-parser (på nuværende tidspunkt kan man, med mod_mono i Apache, kun have én sølle applikation, og derudover mangler det meste af System.Web).
wired>> hvad har det med ens browser at gøre ?!. Og bare fordi at der findes en JITcompiler til f.eks. Linux, betyder det ikke at man bare kan afvikle programmet lavet i f.eks. c# derpå. Hele BCL'et skal jo også med over.
cyberfessor >> BCL'et? (hvad er det?) Tillad mig at modsige din påstand om at man ikke bare kan afvikle programmer skrevet i C# på Linux-maskiner bare fordi der er en JIT-compiler... Det er da netop det der er en af hovedpointerne med .NET Framework'et/Mono. Hvis noget er compilet med .NET på Windows kan det såmænd sagtens afvikles på en Linux-maskine med Mono (medmindre selvfølgelig det gør brug af System.Windows.Forms eller System.Web til en vis grad). Men alt det er jeg sikker på at du godt ved... Enten bunder det i en typo, eller også er det fordi jeg ikke ved hvad BCL betyder... :)
MS kompiler - ved brug af CLR - sin sproguafhængig kode om til MSIL som derved skulle kunne afvikles platformsuafhængigt ved en RunTime enhed med JIT.
Som jeg ser det, eksistere der desværre kun en JIT til MS (og det lyder til at mono er svaret for øvrige OS). Denne JIT (ligger i .NET Framework) fylder desværre pt. 9 MB og er ikke implimenteret i nogen browser endnu (hvilket betyder at der mindst vil gå 2 år før end det bliver standard), og der har heller ikke være direkte tale herom, men... - når/hvis det bliver aktuelt (hvilket ville være perfekt for MS), så ser det ud til at man kan afvikle programmer - på samme måde som Java appletter - hos clienten uafhængigt af sprog og platform. Kan du se et eldorado.
Det er desværre kun det jeg læser mellem linierne, men lur mig om ikke det er det MS har planer om i fremtiden. Jeg er derfor glad for at høre Simon støtte mig i denne idé/tanke.
wired>> jeg ved udmærket hvad JIT (Just In Time) compileren er... Jeg kan dog stadigvæk ikke se hvad det har noget som helst med browser, java og appletter at gøre ?!
Java har ikke noget JIT. Deres bytecode kører i en JVM, som fortolker koden så den kan afvikles. Det bliver aldrig compilet til native code, ligesom MSIL gør. Ang. browsersupport, så er det ikke JIT'en der skal implementes. Den er installeret på systemet, en gang for alle, ligesom JVM'en også er det. Det er tilgengæld muligheden for at embedde en .Net assembly der mangler, på samme måde som du kan embedde et javaapplet eller et COM-object.
Hmmm, tjaaa, jeg ved nu ikke om det var tanken at bruge .NET-applikationer på samme måde som Java appletter.
Min personlige holdning, er at Java-appletter langsomt vil dø ud (vent! Jeg sagde ikke noget om server-side Java), for at blive overtaget af en kombination af client-side Flash og server-side .NET. Men hvad ved jeg...
Kan jeg ikke få et lille svar på hvor jeg kan finde information om hvad Visual Basic .NET er, som jeg kan bruge i min rapport? Jeg skal ikke bruge eksempler, eller noget til at lave et program, bare info om selve programmet... Helst på dansk!
simon.ulsnes>> eller jsp ;)... forresten, så er MM ved at komme med noget actionscript til serverside afvikling... har jeg i hvert fald lade mig fortælle af to flash-nørder der går i min klasse ;) Men du har nok ret. Java apletter er i hvert fald ikke vejen frem... dog har de en klar fordel frem for f.eks. flash, og det er at forbindelsen mellem server og klient bliver opretholdt.
zapzie>> jeg er lidt forvirret ang. dit spm. Er det programmet VS.Net du skal skrive om, eller et det .Net teknologien i det hele taget? Hvis det er programmet som sårn, så har du fået et udmerket link til microsofts hjemmeside.
Jeg har lavet et program i Visual Basic .NET, og så skal der stå nogle facts om visual basic .NET går jeg ud fra... Aner egentlig ikke hvad jeg skal skrive, jeg skal bare have det lavet.. :/
jamen... så er det jo en hel anden snak. Visual Basic.Net er et SPROG. Visual Studio.Net er et PROGRAM der kan hjælpe dig med at skrive programmet i VB.Net.
cyberfessor>> Det har ikke været min hensigt at genere dig. Jeg er ked af det hvis du har fået den fornemmelse. Jeg er da ganske sikker på at du ved hvad en JIT er. MSIL gør ikke så meget, det er et sprog. Det er JIT'en som gør noget. En .NET assembly er en samling af filer - hvorfor jeg ikke tror at det kan være noget som skal implementeres for at opnå nogen form for applet-lignende funktion.
Men jeg vil igen støtte mig til Simon. Jeg ved heller ikke om tanken med .NET-applikationer skulle ende som Java-appletter, men det kunne det meget nemt og med MS udtalelser om at satse på client-delen frem for server-delen (da der er ca. 100 gange flere af denne slags), ville det være ganske smart.
Java dør langsomt ud på client-siden og jeg tror ikke at Flash vil overtage, jeg tror MS gerne vil ind her og hvordan tja...
wired>> der skal en del til for at opnå den appletlignende-effelt i en browser. Browseren skal jo forstå og fotolkte, f.eks. den her linje
<applet type=".net" source="asd.dll" />
til at den skal tage asd.dll, og oprette den som object, og hvise outputtet på skærmen. Samtidig skal den kunne behandle input/output. Lidt ala det VS.Net gør i formdesigneren når man hiver en kontrol ind på sin form.
cf> Du har ret cf, det er en stor opgave, men det ville være fedt om MS's mål var at opnår denne effekt. Som nævnt har jeg intet belæg for denne idé/tanke, men alt hvad jeg læser rundt omkring peger i den retning, uden direkte at skrive det. Og nogen/noget skal jo erstatte java-appletter. Det ville være perfekt om .NET kunne varetage denne funktion.
Desværre er eksemplet fjernet, men havde man den 9 MB framework version installeret kunne denne ".NET applet" erstatte en java applet:
wired>> interresant eksempem ham manden kommer med... :) men som du nok kan se, så hjælper det ikke noget om man kun har sin JIT-compiler installeret, da hans applet gør brug af System.Windows.Forms.Form-klassen, som ligger i Base Class Libary'et... en installation på godt 20 mb.
Hmmm... Det er der vist delte meninger om. Hvis det stod til mig, blev alle Java-appletter henrettet ved daggry. De er langsomme, usikre og i øvrigt en dårlig beslutning sådan rent brugervenlighedsmæssigt (efter parolen inkonsistente brugerflader => total forvirring).
Jeg kan ærlig talt ikke se hvorfor de er så hulens nødvendige.
simon.ulsnes>> rent sikkerhedsmæssigt kommer de til sin ret, da du kan oprette en socket-forbindelse mellem klient og server, og derigennem have en permanent forbindelse og bruge egne protokoller til trafik. Noget du ikke kan med ren http-trafik.
cyberfessor >> Nu er det ikke fordi jeg kender vildt meget til Java (buuh! han trækker i land! ;), men spørgsmålet er ikke om det er muligt at lave en sikker Java-applet (jeg ved det er blevet gjort før), det er mere om det er det folk gør. Der findes masser af teenage-junk-programmør-wannabes derude (aah! don't hit! jeg ville lyve hvis jeg påstod at jeg ikke er en af dem).
Problemet er faktisk mest at man med Java-applets _kan_ gøre en masse usikre ting (tror jeg).
wired >> "styret fra serveren"? Det kan du da sagtens klare med Flash! (som efter min egen personlige mening er en del mere elegant end Java) Men i hvilken sammenhæng har du dog brug for sådan noget?
simon.ulsnes>> nordeas webbank kører over en javaapplet... :) faktisk er der mange webbanker der gør det, så mon ikke det er på grund af noget sikkerhedsnoget, og på grund af ulemperne ved https stateless opbygning :) Det eneste du kan styre med flash er da gennem almindelige POST- eller GETrequests.
cyberfessor >> Jarjarjar, jeg sagde jo heller ikke at det ikke kan lade sig gøre at lave noget sikkert i Java. Der er bare en (rimelig lille, agreed) risiko for brugeren. I øvrigt er jeg sikker (mnaaarh, nærmere et spinkelt håb) på at Nordea skifter til en Windows.Forms-baseret løsning når det engang bliver muligt. (sådan noget med at gå ind på en side, hvorefter der kommer et rigtigt Windows-program (så rigtigt som det bliver i .NET) på skærmen hvorfra man kan styre sine konti) Online Winforms, se det er smart!
- Simon, der er ellers bare gang i den her til aften...
Ovenstående kan i øvrigt allerede sagtens lade sig gøre, hvis klienten har .NET Runtime installeret... (hvilket vedkommende for the most part ikke har)
Nu ved jeg ikke så meget om VB.NET, men jeg ved lidt om Java.
Sikkerheden i Java applets afhænger naturligvis ikke af dem der skriver appletten, men af dem der skriver den JVM der udfører appletten. Det er normalt ret professionelle folk.
Og det er lidt unfair overfor applet's det ry for sikkerheds-problemer de har.
Der blev ganske rigtigt fundet en del huller i de første JVM'ers applet sandbox.
Men: 1) De er fleste (alle kendte formentligt) er blevet fixet for mange år siden. 2) Der er ikke noget tilsvarende til Java applet security. Det må da være et større sikkerheds-problem med ingen sandbox overhovedet end en sandbox som ikke var perfekt i første forsøg.
Hvis I læser lidt i Java kategorien vil I også se at problemet ikke er at sikkerheden er for lav, men at den er for høj (folk får ikke lov til at gøre det de gerne vil gøre).
Iøvrigt mener jeg at 95% af alle de applets der er lavet er ganske overflødige og nemt kunne være lavet med en anden nemmere teknologi, men det er en helt anden sag.
Og forskellene på MS JVM og SUN JVM gør det til et helvede at vedligeholde applets for forskellige browsere, men det er en helt tredie sag.
cf> Jeg glemte forresten af fortælle at Lloyd Dupont C# Applet ikke virkede skyldes at han brugte enten framework 1.0 el beta. Det virker hos mig med kun framework 1.1 installeret.
mht. java/.net og sikkerhed ved jeg kun at .net er yderst sikkert, og at ikke alle har JVM "indbygget"/installeret hvorfor der typisk vil opstå kompabilitets problemer. Det vil .net løse. Til gengæld skal man nok glemme alt om animeret menuer og siden vil blive opdateret efter hvert tryk i browseren.
Tak for en hyggelig samtale.
Synes godt om
Ny brugerNybegynder
Din løsning...
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
