Inledningsvis: Detta är inget hatbrev om dotnet utan bara fundersam utvecklare. Om du kör en applikation som är kompilerad under 1.0 version av .Net på en dator som inte har 1.0 installerat men 1.1 finns, så kommer din 1.0 applikation köras under 1.1 CLR:en. <b>Om du kör en applikation som är kompilerad under 1.0 version av .Net på en dator som inte har 1.0 installerat men 1.1 finns, så kommer din 1.0 applikation köras under 1.1 CLR:en.</b> Roggan: "Här finns förändringarna mellan 1.0 och 1.1. Där kan ni se om ni behöver göra någon förändring i er kod för att få 1.0 att fungera under 1.1:" Jag tycker iofs inte att kunden ska hantera problemet utan det är leverantören. Jag tycker även att de som levererar en 1.0 produkt kan testa och se om den fungerar under 1.1, om det inte gör det så får kunden installera 1.0 eller så får tillverkana modifiera 1.0 versionen till 1.1 om möjligheten finns. 1.0 och 1.1 kan köras på samma server utan problem, ev så behövs vissa konfigurationer göras i configurations filen, står om det i länken i mitt tidigare inlägg. "...så får kunden installera 1.0 eller så får tillverkana modifiera 1.0 versionen till 1.1 om möjligheten finns...." När det inte handlar om ASP .Net så kommer applikationen köras under den version den var kompilerad för. Det är endast ASP .Net som kör under senaste runtime om man själv inte ändrar detta. Så jag förstår inte vad problemet ligger. Jag förstår precis vad du menar, men låt mig försöka förklara vad jag tänker på när man säger att dll-hell är "löst". Disclaimer: Det finns mer kompletta svar på detta som även täcker andra saker än just COM, men detta är det som jag ser som fördelarna. Tackar för hjälpen. Du borde ju kunna använda något installationsprogram som stöder msi... ;) Sedan om rätt version inte är installerad så får man installera den ifrån nätet/cd-skiva/nätverk etc. :) "Sedan om rätt version inte är installerad så får man installera den ifrån nätet/cd-skiva/nätverk etc. :)" vet du vad.. Skrev så om VB6 bara för att man alltid får det nedtryckt i halsen att man kan stanna kvar i stenåldern. om det nu är så att dina kunder kör win95 , så JA då är kanske delphi eller vb6 rätt lösning för DIG! Hej, Roggan: Jhoan du har fel när det gäller Delphi. Det finns inga beroenden till tolkar m.m(krävs iochförsig ett OS). För windows går det utmärkt att göra XCopy installationer. "Jhoan du har fel när det gäller Delphi" Hej Roland. Många bra svar vilka nu har rätat ut vissa frågetecken till utropstecken varför jag får nöja mig och klassa tråden som löst. du behöver INTE (!!!!!) någon special version för win98 Tackar Roggan Så länge win32 funnits så har jag alltid varit tvungen att supporta alla win32 OS och är så fortfarande. Inte för att det är något att längta efter. "Ser ljuset i tunneln." Knappast nu har jag inte powerpoint så jag har inte kollat den artikeln. Har testat. Jag måste erkänna att när jag kollar på C12.ppt så tycker jag att den på ett bra sätt beskriver de lösningar som .NET har på versionsproblem, inte att den visar på att .NET har problem att hantera versioner. Han skriver att assemblies löser DLL hell, men att det kan vara komplicerat att sköta versionshanteringen. De tekniker som han beskriver <assemblyBinding> och <supportedRuntime> är visserligen inte helt smidiga om man skulle använda dem i stor skala, men det finns som jag ser det få anledningar till att hålla på med detta. Men du kanske läser/tolkar det annorlunda än mig?! För det första, PPT-dokument är aldrig speciellt läsbara, då de oftast bara är nyckelpunkter för ett längre föredrag. Man bör alltså ha varit med på föreläsningen för att ha nytta av ett sådant här dokument. Så detta dokument är näst intill omöjligt att lära sig något av, men det är knappast .NET:s fel. dokumentet beskriver ju hur man använder versions hantering på separata assemblies i en app...dotnet-hell ?
Har nyligen genomlevt dll-hell med MDAC i olika versioner.
Bakgrund:
Om man använder dll-er i gamla miljön (ej .net) så kan man få problem med olika versioner av samma typ av dll.
t.ex MDAC finns med versioner t.ex 1.5 2.1 2.5 2.7 och nyaste 2.8.
Här måste användaren av ADO ha rätt version till det program man utvecklat annar får man eländes elände.
Nu till frågan och funderingen
Bakgrund:
Nya miljön med dotnet är dll-hell löst. För att kunna köra en applikation utvecklad i tex vb.net eller c# behövs ett .NET Framework installerat på användarens dator.
saxat från MS-hemsida
"I varje version av Visual Studio .NET ingår det nya och förbättrade .NET Framework 1.1"
Eftersom all utveckling är nödvändig kommer det snart finnas en hel del olika versioner av .NET Framework (gissar)
Vad händer när när man har versioner 1.0 1.1 2.0 2.5 2.8 osv ?
Blir inte detta liknande som dagens dll-hell att användaren då måste ha ett gäng med olika versioner i sina maskiner ?
Detta är förhoppningsvis löst men var hittar jag svaren som jag kan skicka till kunder som undrar om programs kompabilitet som utvecklas i nya dotnet miljön ?Sv: dotnet-hell ?
Om du skapar en applikation under 1.1 så kärver den att 1.1 är installerat på datorn. En 1.1 version kan inte köras under .Net version 1.0.
/Fredrik Normén NSQUARED2
http://www.nsquared2.netSv: dotnet-hell ?
fast det där är ju inte 100% sant , den kommer FÖRSÖKA köra programmet under 1.1 , där med inte sagt att det kommer funka...
det finns förändringar mellan 1.0 och 1.1 som gör att vissa saker inte fungerar helt ok..
så det är helt sant som Roland säger , det finns risk för att användare kommer behöva ha flera versioner av .net på sina burkar om de har program skrivna för olika versioner av frameworket...
//RogerSv: dotnet-hell ?
"köras under 1.1 CLR:en" är inte samma sak som att att det kommer att fungera till 100% eller hur!? ;)
Du har självklart rätt när det gäller att en 1.0 applikation kanske inte kommer att fungera upp till 100%.
.NET Framework klarar av både bakåt och framåt kompabilitet.
De flesta applikationerna som är skapade under 1.0 kommer att köras under version 1.1 utan problem. dock, så kan det hända att 1.0 applikationen behöver modiferas för att fungera under 1.1 utan problem, precis som Roggan säger.
Här finns förändringarna mellan 1.0 och 1.1. Där kan ni se om ni behöver göra någon förändring i er kod för att få 1.0 att fungera under 1.1:
http://www.gotdotnet.com/team/changeinfo/default.aspx
/Fredrik Normén NSQUARED2
http://www.nsquared2.netSv: dotnet-hell ?
En kund som köper en applikation utvecklad i 1.0 hur ska han hantera sådant på egen hand ?Sv: dotnet-hell ?
/Fredrik Normén NSQUARED2
http://www.nsquared2.netSv: dotnet-hell ?
Vem ansvarar och vem får betala ?
"... 1.0 och 1.1 kan köras på samma server utan problem"
Nu tänkte jag inte bara på asp.net utan även installationer i lokala maskiner, vilka även de idag kan köra båda versionerna men behövs då i framtiden 1.0 1.1 2.5 3.8 osv ?Sv: dotnet-hell ?
Dock kan det ju kännas bökigt att hålla reda på alla versioner, men tack vare att flera olika versioner kan köras samtididgt har sådana problem minskat.
JNSv: dotnet-hell ?
Jag tänker på hur det är när man har COM komponenter som accessas med CreateObject("Acme.Application"). Om en ny version av Acme.Application installerades så kommer alla applikationer som skapar Acme.Application att börja använda den nya versionen, utan att man egentligen kunde kontrollera detta på något vis. Det finns ju visserligen regler i COM hur man kan komma runt detta någorlunda, men jag har aldrig sett något använda dessa i praktiken...
I .NET kan du genom att använda private assemblies, alltså ej stoppa dem i GAC, vara säker på att de assemblies som du en gång installerade din applikation med även kommer vara de som applikationen körs med. Du kan installera en ny applikation som innehåller uppdaterade versioner av någon support assembly utan att existerande applikationer berörs.
Jämförelsen med versioner av .NET Framework med MDAC tycker inte jag stämmer helt. Detta eftersom .NET Framework versioner installeras side-by-side, dvs de kan verka oberoende på samma maskin utan att sabba för varandra. Med MDAC så är det ju lite annorlunda, installerar du en ny MDAC version så påverkar du ju existerande applikationer i hög grad.
/MattiasSv: dotnet-hell ?
Som jag uppfattar det så bör jag alltid skicka med en version av den FrameWork jag har använt mig av för att kunna garantera funktion hos användaren.
Om så är fallet kommer installationsfilerna bli ganska stora och besvärliga att distriubera vi internet.
Finns det enklare sätt att sköta detta på så att användaren som installerar program
upplever detta som enkelt ?
Tacksam för kommentarer.Sv: dotnet-hell ?
Sv: dotnet-hell ?
Ok för mig men knappast för slutanvändare som vill ha användarvänliga program och installationer. Det blir lite av vad Britney Spears sjöng om "Ooops I did't again"
"Microsoft .NET Framework Version 1.1 Redistributable Package"
23698 KB
Detta är vad som bör tillkomma för .net applikationer för att kunna köra dem säkert.
Antag att du utvecklar applikationer i .net som du säljer via webben till användare som ofta bara har modem. De får då förutom din applikation tanka ned nästan 24 Mb och hoppas att det går bra att installera samt vad jag vidare i vissa trådar läst att man bör ha XP för full kompabilitet. De kanske hade rätt version men vem vill be dem testa för att få ett äckligt felmeddelande i facet.
Morgontrött och lätt besviken som hade bestämt mig för att växla över till dotnet nu.
(och jag vill inte vara kvar i Visual Studio med VB6 mycket längre eller växla över till java)Sv: dotnet-hell ?
java har oxo en ganska stor och fet runtime...
(vb6 har oxo en runtime , kanske inte lika stor då men iaf)
och innan du säger att "så måsta man visst ha xp för att få full kompatabillitet" så tycker jag nog du ska ta och kolla VAD det är som går i xp som inte går i tex. win2k..
tänk om den där 1%en med features handlar om att .net kanske kan byta grafiskt tema i xp , skulle det då vara ett problem att den featuren inte finns i .net under win2k?????
(ok nu är det inte det det är , men alla features du behöver för att göra vanliga apps utan att hacka finns under 2k/nt)
//RogerSv: dotnet-hell ?
VB6 har en massa elände med bla massa dll-er som skapar problem, java har säkert massor med elände.
Alllt detta pekar på att SvenPon med sitt tjat om Delphi börjar få rätt.
(ok finns säkert massa elände med Delphi också)
Ok att det bara är 1% nu som är problem med win2000 men hur blir läget med Framework 1.5, 2.1 osv (vet ingen nu inte ens MS) men ger mej sjutton på att läget kan bli ohållbart och man får ha flera progamversioner för olika användarkategorier.
dotnet skall vara plattformsoberoende men blir då operativversionsberoende !?
Nyhet ?
Var finns enkelheten?Sv: dotnet-hell ?
men alla har ju inte samma kunder som du... och därmed inte samma behov...
//Roger
ang:
<b>dotnet skall vara plattformsoberoende men blir då operativversionsberoende !?
Nyhet ?</b>
.net fungerar till viss del redan idag på tex linux/*nix maskiner..
och att om man bakar in stöd för vissa features i windows i frameworket så är det väll rätt uppenbart att dessa features INTE kommer fungera på operativ som inte har sånna features...
ett exempel:
säg att du köper en fjärrkontroll som fungerar till din svartvita gamla tv (rent teoretiskt alltså)
och säg att fjärrkontrollen även har knappar för att justera färgen på andra tvmodeller oxo..
är det då fjärrkontrollen eller din tv som är dålig för att färgknapparna inte fungerar tillsammans med din tv?
//RogerSv: dotnet-hell ?
När du bygger ett .Net program så måste ju självklart kunden ha den tuntime som krävs för att .Net skall fungera. I Win Update finns .Net runtime nerladdningsbar och rekommenderas att ta hem. Jag tror att io m. senaste XP Versionnen så ingår .Net ramverk. I win 2003 ingår den. Så idag har rellativt många stödet för .Net på sina datorer. Och du ger ju inte bort ett program eller säljer ett program utan att kräva .Net.
Så vad du gör är enkelt antingen slänger du med DEN stora filen eller så sätter du ett systemkrav. Java går som sagt inte köra utan en VM som är är Javas Runtime. VB6 behöver oxå en del saker för att fungera (dock medföljande i alla OS).
Gällande Delphi så är jag nästan övertygad att du måste installera någon slags tolk där oxå? Så du kommer ha samma problem vare sig språk.
Exempelvis är det ju lite svårt att läsa en Wordfil utan att ha en läsare installerad på din dator eller hur?
Dock är jag med på dina tanker om det ex skulle komma en 1.5 version och man då blir tvungen att ha 1.0, 1.1, 1.2, 1.3, 1.4 och 1.5 på sin dator. Det kan ju bli lite knepigt. Men skillnaderna API mässigt är väldigt få i dessa releaser. Det brukar mer vara så att det kommer flera klasser som man kan dra nytta av.
Var finns enkelheten? I vad .Net allmänt? Eller installation? Sv: dotnet-hell ?
Jag kan inte bestämma vad kunden ska ha för ett operativsystem. Kunde jag det hade jag givetvis sagt windows xp eftersom det gjort det så mycket enklare för mig.
Kunde jag sedan krävt att de alltid skulle ladda in rätt version av allting som just mitt program behöver och struntat i vad det ställt till för övrigt hade allt varit kanon.
Om de sedan kunde svälja att jag krävt att de skulle haft kraftfulla datorer osv vore lyckan fullkomlig.
Nu ser inte världen ut sådan.
Johan:
Enkelhet, där det är bättre att jag lägger några timmar extra än att ett antal användare som får problem och skapar mängder med arbete.
Jag tror inte delphi behöver något extra men skapar något större exe-filer. Nu är dock inte det intressant eftersom stor flertalet går mot dotnet.
Förhoppningsvis är dotnet lösningen.Sv: dotnet-hell ?
Vet inte om det kommer att skapas ett dotNet Hell men det skrivs endel om "Assembly Hell".Sv: dotnet-hell ?
Bra då har vi löst den frågan :-) Som sagt var jag inte säker. Sv: dotnet-hell ?
Idag har allt systemkrav. Så när det gäller .Net är kravet 98 och uppåt. Jag tror inte det är så många som sitter med lägre versioner som skulle vara kund till dig. Och jag tror heller inte dina kunder är denna målgrupp. Men om det är så så visst då kanske du skall vänta med .Net lösningar för dina system som då inte kräver .Net och köra .Net lösningar i de fall du anser att det skall vara ett systemkrav. Allt handlar ju om vad kunden vill betala för. En god analys sitter ju på sin plats, kolla runt med ev. kunder hur många av dem skulle kunna slänga in .net för ett kraftigare program som du dessutom kanske kan sälja billigare då utvecklingstiden kan minska.
Allt gott för något ont med sig vare sig man vill eller ej.
Jag bygger web applikationer så jag är inte lika beroende av vad folk har på sina datorer. Då de endast kommer köra tunna klineter (ex. IE).
Dock är det knöligare att göra klient applikationer i .Net i dagsläget av de problem jag uppfattar att du hela tiden pekar på. Alla kanske inte har eller vill köra .Net på sin dator, det är då jag väljer att bygga saker i ex Vb6 annars har inte jag några kunder.
JNSv: dotnet-hell ?
Lite kommentarer.
Andelen som är kvar i win95 är inte många nu och kan förhoppningsvis acceptera svaret att de måste uppgradera, men andelen win98 maskiner är förhållandeivs stor speciellt där ekonomiska begränsningar gjort att man fått dra ned på IT-investeringar samt många privata datorer. Därför kommer man få ha flera versioner av sina applikationer om man vill nå hela gruppen.
Detta gör mig tveksam att i dagsläget satsa helt på dotnet utan får nog nöja mig med det som testutveckling så länge tills marknaden är mogen. Liknande slutsatser kan nog finnas hos många andra.Sv: dotnet-hell ?
har du en fungerande version för win98 så funkar den på de andra operativen oxo..
så du behöver bara EN... dock måste du ta hänsyn till win98s begränsningar när du skriver den...
ang versioner av frameworket så är det ju inte säkert att du får några problem...
det kan hända att din app fungerar utmärkt i flera versioner av frameworket..
och om det inte är så så kan det hjälpa med att helt enkelt kompilera samma projekt under den nya versionen av frameworket.
och i värsta fall så får du ha precompile direktiv runt den kod som är specifik för ett visst framework...
//RogerSv: dotnet-hell ?
Det var några mycket bra tipps, alltså kan man använda tekniken framåtkompatibel inom windows, intressant.
Den typ av applikationer jag skriver (hittills) klarar troligen sig bra med begränsningen som win98 har och kan då ha garanti att den går i win2000 och XP.
Ser ljuset i tunneln.Sv: dotnet-hell ?
Skriver man vanliga win32 program(utan dotNet) så måste man ocshå ta hänsyn till de olika operativen.
En powerpoint om Assembly Hell från Sam Gentile.
http://samgentile.com/C12.ppt
Finns ju tillräckligt med MSFT predikanter här så ;-).
Raw Delphi:
http://www.codexterity.com/raw-delphi/index.htmSv: dotnet-hell ?
Rejält tveksam till dotnet efter ovanstående artikel.
Jag rekommenderar er, läs den. (http://samgentile.com/C12.ppt)
Antingen är artikeln falsk eller så mörkar MS rejält om dotnets fantastiska värld.
Hittills pekar mycket på att SvenPon som skrikit sig hes om Delphi börjar få rätt.Sv: dotnet-hell ?
men helt seriöst Roland...
varför tar du inte och tittar på .net och bildar dig en egen uppfattning??
du sitter ju bara och gnäller på saker du inte vet något om..
är du så med allt?? "JAG TÄNKER INTE ÄTA DEN DÄR KÖTTBULLEN!! DET VAR EN SOM SA ATT MAN FICK BÖLDER I ÖGONEN OM MAN GÖR DET .. JAG SKITER I OM MILJONER ANDRA KÄKAR KÖTTBULLAR UTAN ATT FÅ BÖLDER I ÖGONEN , HAN SA JU ATT MAN FICK DET SÅ JAG TÄNKER INTE TESTAAA!!!!!"
köp dig några böcker , gör lite testprogg så märker du ju snart hur det funkar...
//RogerSv: dotnet-hell ?
Trögt och komplext men finns en del intressant.
Läst några böcker och då med c# eftersom jag tidigare hållt på med bla c och lite c++
NEJ jag är inte gnällig bara kritisk till onödigt komplex miljö med återigen massa versionsproblem. Den soppa MS skapat med dll versionsproblem kan du knappast förneka. Den bild man får om man läser powerpoint dokumentet enligt ovanstående inlägg pekar dock på massa problem som måste tas om hand.
Om man bar kör i en version av FrameWork och har full koll på att alla program uppgraderas vid ny versioner så slipper man troligen problem men detta är kostsamt och problematiskt.
Har hållit på med systemutveckling sedan mitten av 80-talet och vet vilka problem arvet av programkod skapar vid versionsbyten.
Troligen (min uppfattning) är dotnet bäst till typ asp.net speciellt då gamla asp har stora brister. Samt att man då mer har koll på vad som finns i server vilken är den som kör programmet. Den delen som användaren får då är vanlig HTML och bör slippa problemen. Hur det är med komponenter som behövs hos användaren då har jag ej studerat.Sv: dotnet-hell ?
När det gäller CLR versioner så ser jag inte att .NET skulle vara värre än någon annan runtime-miljö (JVM, VB, C++, Smalltalk, etc.). Snarare tvärtom, hur många andra miljöer kan man installera side-by-side och ha applikationer kompilerade mot olika versioner och som körs i sin ursprungliga (och testade) miljö. Visst kan man i .NET gå in och detaljstyra exakt vilken runtime version som ska användas, men varför skulle jag vilja det om applikationen fungerar? Vore det bättre om man inte tillät en fungerande applikation att köra i en känd miljö och istället tvingade den att uppgraderas till en ny runtime-version?
Vad gäller Win98 så är väl de största skillnaderna att ASP.NET och COM+ inte stöds på denna platform.
"Om man bar kör i en version av FrameWork och har full koll på att alla program uppgraderas vid ny versioner så slipper man troligen problem men detta är kostsamt och problematiskt."
Men hela iden är ju att inte tvingas uppgradera dina program och kan har flera versioner side-by-side. Det finns inget som tvingar dig att hacka config-filer och styra om till nya versioner. T.ex. skriver Sam i sin PPT att "Use publisher policies only when patching an existing component", men ingen av oss gör ju fel så det berör ju inte oss :-)
"Trögt och komplext", i jämförelse med vaddå? Trögt antyder långsamt, vilket jag verkligen inte håller med om. Komplext är möjligt, men det är väl tur att .NET tillåter dig att göra det mesta som Win32 tillhandhahåller (jaja, visst finns det delar som inte är inkluderat).
/MattiasSv: dotnet-hell ?
Sedan kan jag konstatera att jag inte förstår hälften av dokumentet och jag har bara använt en bråkdel av det. Trots detta har jag utan några som helst problem redan levererat ett 4-5 produkter i ett flertal versioner och det har gått utmärkt. Man behöver inte sätta sig in i allt som står i dokumentet för att slippa DLL-hell. Det är i alla fall min erfarenhet.
Sedan ser jag det som positivt med .NET att det finns minst ett lager till av komplexitet att ta till när jag råkar ut för ett specifikt versionsproblem som måste lösas...men det tänker jag inte sätta mig in i förrän jag behöver. Det är en inställning jag kan rekommendera hellre än att tro att man måste förstå alla detaljer innan man börjar koda :-)Sv: dotnet-hell ?
säg att du levererar en app som använder assembly "flerp.dll" ,
säg sedan att leverantören av assemblyn "flerp.dll" skapar en ny version
då har man nytta av det som står i powerpoint presentationen..
men det är ju inget man MÅSTE använda... du kan ju lika gärna kompilera om din app med den nya dll'en och skicka ut ett nytt installationspaket till dina kunder...
ELLER , så skiter du i det oxo , om du tycker att "flerp.dll" fungerade bra från början och dina kunder har inget behov av den nya funktionalliteten i den...
//Roger