Microsoft .NET 1.1 maakt einde aan 'DLL hell'

The Star brengt ons een bericht over de oplossing van de DLL-problemen, die volgens Microsoft met Windows Server 2003 moet komen. De Dynamic Link Libraries zijn softwaremodules die gedeeld worden door meerdere programma's, en juist in dit delen zit het probleem. Wanneer het ene programma een vernieuwde versie van de DLL installeert, gebeurde het vaak dat een ouder programma niet met deze vernieuwde DLL kon werken.

Microsoft .Net 1.1, wat standaard bij Windows Server 2003 zal zitten, heeft hiervoor (of eigenlijk hiertegen) het Global Assembly Cache. Wanneer een DLL geïnstalleerd wordt, geeft de Global Assembly Cache deze een naam en slaat hem op. Wanneer een programma een DLL nodig heeft, kijkt het in de opslagplaats en kan aan de naam onder andere zien met welke versie het te maken heeft. In theorie zou dit dus de verwarring tussen verschillende DLL-versies moeten voorkomen:

Microsoft .Net 1.1, which will be integral to the new Windows Server 2003 operating systems, will support what the company calls strong binding, said Salmre. "Strong binding means an application or component can bind to a specific version of another component, so you can reuse components or use them in isolation."

Reacties (65)

[Biff]

Dit is toch eigenlijk de wereld compleet op zijn kop. Het idee van DLLs is toch juist dat je bepaalde functionaliteit niet statisch in ieder programma wilt meecompileren, maar juist wilt isoleren om vanuit meerdere programma's aan te kunnen spreken en zo geheugen te besparen. Anders kan je die functionaliteit net zo goed bijvoorbeeld direct in een .exe file zetten.

Maar dit nieuwe proces bevordert juist het idee dat het best ok is als programma's weer allemaal hun eigen versies van zo'n dll gaan gebruiken. En dat terwijl Microsoft al zo vaak heeft geclaimd dat inzicht in sourcecode niet nodig is als de interfaces (API) maar duidelijk gedefiniëerd zijn. Als de interfaces echt consequent zijn, dan zou de revisie van de DLL niet uit moeten maken, en zou je dit vreemde systeem niet nodig hebben. Waarom werkt dit niet?

[Verwijderd]

Akkoord. Software engineering beginnersklas: maak libraries met common functionaliteit en zorg voor een consequent interface/data structuur zodat zaken blijven werken na upgrades.

Maar wat als je na een aantal jaren eens iets totaal anders wilt gaan doen? Bijvoorbeeld omdat de eerste implementatie een rotzooitje was. Andere oplossingen?

[Verwijderd]

Microsoft komt m.i. ERG laat met deze technologie! Linux heeft al eeuwen versie nummers toegekend etc met andere systemen (rah.so.7 bijvoorbeld); het nieuwe ms systeem zal vast werken enzo maar waarom niet ook versienummers aan DLL files toewijzen? rah.dll.1 ofzo, dan heb je ook geen gezeik..

[arjankoole]

niet alleen linux, de so's zijn van zo'n beetje iedere denkbare *NIX dacht ik.

met de *nix equivalent los je alleen nog minder op, omdat de ene app wel werkt met so.4 maar niet met so.5, of weer specifiek zoekt naar so.3 en dus niet om kan gaan met so.4. (een symlink lost dit met de BSD versie van McAffee gelukkig al op).

shared libraries zijn onder ieder systeem een leuk principe en een leuke theorie, de praktijk wijst echter meestal uit dat je eindigt met een systeem waar echt wel shared libs op staan die al lang niet meer gebruikt worden. Echter, het is een noodzakelijk kwaad, ongeacht het OS dat je gebruikt. Nu scheelt 't dat onder de meeste NIXen minder shared libs worden geinstalleerd dan onder windows, waar zo'n beetje alles met shared libs aan elkaar zit gekleeft, maar nog, het principe is leuk, de praktijk, tja......

[deadinspace]

met de *nix equivalent los je alleen nog minder op, omdat de ene app wel werkt met so.4 maar niet met so.5, of weer specifiek zoekt naar so.3 en dus niet om kan gaan met so.4.

Ehm... Duh?

Het hele idee van shared library versioning is dat er incompatible veranderingen tussen de major versies zijn. libblaat.so.4 is bevat dus incompatible veranderingen t.o.v. van libblaat.so.3. Daar is die versie-verandering voor!

(een symlink lost dit met de BSD versie van McAffee gelukkig al op).

De echte oplossing is de juiste versie van die shared library installeren. Een symlink is een lapmiddel dat misschien wel, misschien niet werkt. Dat hangt er maar net vanaf of de functies waar McAffee gebruik van maakt veranderd zijn in die versie of niet.

shared libraries zijn onder ieder systeem een leuk principe en een leuke theorie, de praktijk wijst echter meestal uit dat je eindigt met een systeem waar echt wel shared libs op staan die al lang niet meer gebruikt worden.

Dat is een beheer-probleem, geen probleem van shared library versioning. Een beheer-probleem dat prima kan worden opgelost door een goed package-systeem. Packages geven aan op welke andere packages (die bijvoorbeeld shared libraries bevatten) ze dependen, en op die manier zijn alleen de packages die je nodig hebt geinstalleerd.

Nu scheelt 't dat onder de meeste NIXen minder shared libs worden geinstalleerd dan onder windows, waar zo'n beetje alles met shared libs aan elkaar zit gekleeft

Riiiight!

Heb jij *ooit* gezien wat voor een berg libs Gnome of KDE nodig heeft? Of willekeurig welk ander progsel eigenlijk? Alleen al voor aterm, een tamelijk minimalistische terminal emulator, tel ik niet minder dan 7 shared libraries.

Unices hangen net zo goed van de shared libraries aan elkaar, alleen is het in de Unices wel behoorlijk goed geregeld, onder andere door versioning.

maar nog, het principe is leuk, de praktijk, tja......

In de praktijk werkt het hier uit-ste-kend.

[de Rochebrune]

Dit zit toch al in Windows XP onder de naam side-by-side assemblies? Hiermee zou de DLL-Hell ook al over zijn.

zie: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs /setup/side_by_side_assemblies.asp

en ook: http://windowsxp.devx.com/presentations/sidebysideassemblies_110k/defa ult.htm

[Verwijderd]

Microsoft zou meer naar Apple moeten kijken dan ze tot noch toe gedaan hebben. Bij Apple heeft ieder pragramma zijn eigen mapje met ALLE zooi erin die het programma nodig heeft + 1 set voorkeuren die wanneer je ze weggooit weer nieuw aangemaakt worden. Deze programma's zijn te verplaatsen naar waar je maar wil op je HD of naar desnoods een andere mac en alles blijft gewoon werken. Never last met vervelende "kan ik niet vinden" bestandjes. Maar ja, is maar goed dat niet alles zo goed geregeld is als bij apple, anders zou er een appeltje moeten verschijnen wanneer je opstart...

http://www.apple.com/switch/

[cybermans]

switch humor: http://home.attbi.com/~m.ellsworth/pornswitch.mov

[Forage]

Ik hoop dat ze het dan meteen ook goed aan pakken, of het behoud van dll's een goed iets is is een tweede.

Ik heb laatst mijn hardeschijf eens even opgeschoont van alle overbodige dll's dmv Ashampoo WinOptimizer, deze heeft een optie om je hele harde schijf te scannen op alle dll's, deze zet ie dan allemaal netjes gesorteerd op versie en locatie op het scherm. Aan de hand hiervan kun je bepalen welke je weg wilt gooien.

Hieruit bleek nog eens extra hoe onoverzichtelijk de hele dll kermis is. Elk willekeurig programma gooit de (algemene) dll's maar ergens neer, of het nou in hun eigen programma directory is of de system of system32 directory. Ik heb geen dll gevonden die er niet dubbel op stond...

Met deze "nieuwe" methode zal het er misschien eindelijk van (moeten) komen dat dit hele gebeuren centraal gebeurd. Op deze manier hoeven programma's ook niet meer voor de zekerheid (algemene) dll's in hun eigen directory te plaatsen. Iets wat naar mijn idee meteen van het begin af aan had moeten gebeuren. Niet meer dan logisch als je een systeem als werken met dll's gaat opzetten lijk mij...


P.s. Voor de mensen die nu spontaan ook hun harde schijf gaan opschonen van overbodige dll's: WEET WAT JE DOET! Het is bepaald niet zonder risico en je kunt je hele systeem r mee de soep in helpen...

[Verwijderd]

Daar zal het os ook niet kleiner van worden.
Maar da's al sinds tijden een normale gang van zaken.

[MichelVH]

Je kunt kiezen:

1) accepteren dat je oude programma's niet werken en hooguit 1 versie van een DLL installeren in je SYSTEM map
2) elk programma z'n eigen kopie van een DLL laten installeren in de programmamap, waardoor je dus van dezelfde DLL een bepaalde versie meerdere keren op je schijf hebt staan
3) alle DLL's in de GAC laten installeren waardoor je elke versie maar 1 keer op je systeem hebt

Doe mij optie 3 maar En zoals Durona al zegt, zo groot zijn die dingen over het algemeen niet.

[Verwijderd]

Blijkbaar nog niet gezien hoe windows groeit na een jaartje te draaien??? Ik merk het goed genoeg. Je installeert een programma ... vlam ... een hoop dll's ... die niet altijd verwijderd worden... Na een jaar is je windows directory 3 * zo groot of groter (vooral je system32 dir). En de mensen die hierop willen antwoorden: "ik herinstalleer men os altijd". Ik wil je dat eens zien doen met bedrijf pc's ...

Als men nu nog eens de dll's gaat bijhouden van iedere verschillende versie ... lol ... ik zal maar aanraden om 180GB hd's te laten installeren op men werk

[Battle Bunny]

Wat een onzin. Je hebt in de registry een lijst met DLL's, en het aantal keer dat die "gebruikt" is. Als je een prog installeerd (met WAT voor installer dan ook) verhoogt 'ie het getalletje. Als je iets deinstalleerd, verlaagt de installer em (als het goed is ). Wanneer het tellertje op nul staat gaat de entry uit de registry en mag je de DLL wegmikken. Als de installer dit doet (en dat doen de meeste) is er niets aan de hand.

Behalve dat je er nog steeds erg veel hebt dan.

Persoonlijk zou ik liever een "echte" oplossing zien, in plaats van hun eigen rotzooi te plakken met van dit soort vage oplossingen, maarja.

[reactie op MichelVH, maar dat mag niet van de layout :+]

[MichelVH]

Gek he, als de ene ontwikkelaar z'n DLL's installeert met InstallShield, de andere met Wise en weer een andere met Windows Installer En soms worden die programma's zelfs door elkaar heen gebruikt binnen hetzelfde softwarehuis. Geen wonder dat er dan geen overzicht is van welke DLL's nog nodig zijn en welke niet.

Ik denk dat dát een belangrijke functie van de GAC gaat worden: het bijhouden van welke programma's welke DLL's gebruiken. I.c.m. de Windows Installer zal het met de hoeveelheid trash in je GAC wel meevallen.

[YoMarK]

En de mensen die hierop willen antwoorden: "ik herinstalleer men os altijd". Ik wil je dat eens zien doen met bedrijf pc's ...

Fijne bedrijfspolicy als de gebruikers zomaar alles mogen installeren. Vrijwel alles kun je afvangen, dus de dll-hel is helemaal niet zo'n probleem binnen bedrijven die het goed voor elkaar hebben.

[Verwijderd]

Het kan inderdaad een warboel worden en dat wordt dan ook een koele nieuwe feature van dit OS, het .NET platform kent al sinds de introductie 2 soorten van DLL opslag. de local en global assembly cache. De global bevat alle shared DLLs en de local alle product/poject gerelateerde DLLs het mooie aan de nieuwe Windows versie is dan ook meteen het zwakke punt; immers Microsoft legt een basis met het Nieuwe Windows 2003 server en de .NET ontzikkelomgeving maar als de software producenten deze technologie (nog) niet gebruiken zal het nog steeds een DLL hell blijven....

[Verwijderd]

Een doorsnee dll-file palmt zo'n 50 à 300 Kb in van je schijfruimte, dus dat zal wel nog meevallen, zeker als je dit in rekening brengt met de ontwikkelingen op vlak van opslagcapaciteit.
Trouwens, als dat een probleem is, laat je gewoon je windows de bestanden comprimeren: scheelt mss 1ms in snelheid, maar een heel stuk in grootte (op voorwaarde dat je van NTFS gebruik maakt natuurlijk)

[Verwijderd]

Ik heb net even een search gedaan in C:\winnt naar alle *.dll bestanden en kwam op ruim een half gigabyte aan dll's... en zo lang geleden is het nog niet dat ik dit systeem geinstalleerd heb (Win2k prof)

[Verwijderd]

Ik vind eigenlijk dat elke programma een aparte directory moet krijgen waarin hij al zijn bestanden (ook DLL's enzo), instellingen (registry) moet opslaan.
Er mag dus niks gedeelt worden tussen programma's, tenzij er al 1 identieke bestand/module in het geheugen is geladen

Zo voorkom je denk ik aardig wat problemen

[Verwijderd]

en is tevens een wel erg inefficiente manier van omgaan met je schijfruimte wat jij nu voorstelt... want als bijvoorbeeld Word, Excel, Outlook, en Powerpoint dezelfde .dll gebruiken, moet ie toch 4x op je harde schijf staan? Om over de registery dan nog maar te zwijgen
Met andere woorden, lijkt me een slordige en inefficiente oplossing hiervoor

[Verwijderd]

Word/Excel/PowerPoint wordt vaak als 1 geheel verkocht (Office pakket dus )

Maar je hebt hier wel gelijk in, echter vandaag de dag kost opslag ruimte niet zoveel meer.

Een ander voordeel van deze methode -lijkt mij - is, dat je zonder veel problemen een programma kan verplaatsen, zonder dat windows gaat zeuren over missende bestanden etc.

[dmnq]

En hoe wilde je dat gaan doen met je register, snelkoppelingen, etc...?

Je kan wel leuk een programmatje verplaatsen omdat je alle bestanden bij elkaar hebt, maar er zijn nog 100-en-1 verwijzigen naar de oorspronkelijke locatie.

edit: typo

[Verwijderd]

Dat is het idee ook !

Als je de instellingen opslaat in de programma directory zelf, met daarin ook een bestand met daarin de configuratiegegeven en (relatieve)bestandspaden dan heb je hier geen last van.

Het programma moet dan wel optimaal voor deze methode geprogrameerd zijn.

Het probleem van een niet kloppende snelkoppeling is imo een 'klein probleempje'.
Is gewoon een kwestie van deze snelkoppeling aanpassen

[Zer0]

Efficient omgaan met schijfruimte en geheugen is de reden waarom we in de "dll-hel" terecht gekomen zijn. Omdat "vroeger" schijfruimte beperkt was is men gezamelijke componenten in DLL's gaan stoppen. .NET gaat minder efficient met de schijfruimte om, maar is dus wel in staat meerdere versies van assemblies naast elkaar op te slaan zodat er geen conflicten meer onstaan. Aangezien schijfruimte tegenwoordig geen schaars goed is, is die inefficientie geen probleem.

[Steven]

Dan zouden er een aantal DLL's zijn die je heel vaak op je hardeschijf hebt staan, is iets waar je ook niet vrolijk van zou worden.
Het makkelijkst is gewoon als elke DLL backwards compatible is, maar ja dat is een beetje naief natuurlijk. Makkelijker is dat er meerdere versies van een DLL op je systemen mogen staan, iets wat mogelijk is op de nieuwe manier die MS hierboven presenteerd.

[CyberSnooP]

Ik dacht dat de .NET filosofie sowieso al afzag van gedeelde DLLs. Ik neem aan dat deze techniek niet alleen voor .NET-software werkt, maar voor alle draaiende software anders duurt het wel erg lang voordat je hier echt profijt van hebt. Maar wat heeft het dan specifiek met .NET te maken, is het niet gewoon algemene feature van Windows Server 2003?

Verder is deze techniek wel vaker aangekondigd door Microsoft, maar blijkbaar is het toch nog lastig te implementeren (geweest)

[Marcelloz]

Met .Net kan je prima nog DLL's delen, iets waar DLL ze ook voor bedoeld zijn ( library files ). Wat .Net met 'einde dll hell' bedoeld is dat het versiebeheer enorm verbeterd is. Omdat je DLL's nu netjes via de Global Assembly Cache kan registreren, kan je meerdere, dezelfde, DLL's naast elkaar geinstalleerd hebben zonder dat applicaties daar 'last' van hebben. Simpel gezegd, .Net DLL's overschrijven elkaar niet, maar kunnen naast elkaar bestaan.

Windows 2003 heeft inderdaad een betere integratie met .Net, veel applicaties zullen gebruik maken van de .Net libraries. Echter, de dll's waar het meestal fout gaat ( o.a. drivers en msvc* ) zijn gewoon nog old-style dll's dus de 'dll hell' blijft nog wel even bestaan. Daarnaast is DLL Hell voornamelijk een probleem van workstations, en niet van servers. Dus de bovengenoemde uitspraken vind ik hype en een beetje voorbarig.

[Bosmonster]

Dit is toch geen oplossing? Hier wordt de hele DLL-structuur nog onoverzichtelijker van met verschillende versies van dezelfde DLL naast elkaar.

[Remenic]

Inderdaad, Linux heeft voor zolang ik er mee werk (4,5 jaar, maar daarvoor zal het ook al zo gewerkt hebben) gebruik gemaakt van versie nummers voor DLL's en dit vind ik zwaar irritant. Het werkt (meestal) wel, maar me schijf wordt er vreselijk vol van...

Dit is geen oplossing maar een workaround en dat is jammer, khad van zo'n groot commercieel bedrijf wel een beter verwacht...

Ik wou dat programmeurs gewoon eens beter hun best deden om subversies met elkaar compatible to houden...

edit:
Typo's enzo

[Brahiewahiewa]

Ik wou dat programmeurs gewoon eens beter hun best deden om subversies met elkaar compatible to houden...

Het probleem zit'm niet zozeer in de compabiliteit, maar in het feit dat programmeurs zich niet netjes aan de entry points in zo'n DLL houden. Vaak verwijst men rechtstreeks naar een bepaalde off-set in een DLL (om zo parameter checking te voorkomen zodat de code sneller wordt en je meteen fantastiese mogelijkheden voor buffer overflows creëert).

[Remenic]

Ow okee, onder Linux wordt dat naar mijn weten nooit toegepast op die manier.

[Verwijderd]

Hier is toch helemaal niks nieuws aan? .NET 1.0 heeft dit ook al gewoon...

Dus een beetje een flauwekul bericht...

Bovendien werkt dit alleen voor .NET assemblies (dll's) en niet voor de native dingen waar windows standaard gebruik van maakt.

[tigurr]

Ja dat klopt dit heeft .Net al sinds versie 1.0 maar, volgens dit verhaal :

Microsoft .Net 1.1, which will be integral to the new Windows Server 2003 operating systems.

maakt het nu dus deel uit van het OS. De native zaken van Windows zullen dus ook in een Assembly zitten.

edit :
Net dus het artikel gelezen en het gaat idd over applications en niet over de native zaken van het OS.

[Verwijderd]

ook nauwelijks nieuws dus, het heette eerst zelfs .net server

[RobzQ]

Helemaal mee eens. T.Net begint meer een meer een MS promotie outlet te worden..

[Ruuddie]

Logisch, anders wordt de site downgehaald

[Codin the Coder]

Meen je het?

Ik ben niks anders dan negatieve berichten over Microsoft en positieve berichten over Linux gewend op T.net.

Met de woorden "DLL hell" in de posttitel vormt dit nieuwtje geen uitzondering als je het mij vraagt.