Hoofdcategorieën
Device Settings

Microsoft .NET 1.1 maakt einde aan 'DLL hell'

Door Tamara van Hal, zaterdag 8 maart 2003 12:54
Bron: The Star, submitter: ac41964, views: 1.140

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 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."
Volgende 13:04 Silicon Image 3112 Serial ATA-chip getest
Vorige 12:21 Hackers gebruiken Google om in databases te komen
Advertentie

Reacties

«  1  2  3  »

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

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)

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)

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.

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 ;)

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.

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 :+]

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.

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....

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.

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.

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

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

Logisch, anders wordt de site downgehaald :P

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.


Ze kunnen die dlls niet zomaar afschaffen: al de oude apps zouden niet meer draaien op hun nieuwe Windowsedities. Ze willen natuurlijk compatibel blijven met die oude apps, omdat veel bedrijven anders zeker de overstap op een nieuw besturingssysteem niet meer zouden wagen.
Het zou ook zeer ambetant worden voor programmeurs, als die plotseling zouden moeten overschakelen op een andere manier van programmeren.
Mss dat nieuwe apps er geen gebruik meer van zullen maken???

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)

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.

Alleen komt dat de snelheid van de DLLs niet te goed :(

Uh, dus nu krijg dus eigenlijk alleen maar meer troep op mijn HD? :? Als ik het zo begrijp bewaart ie oude en nieuwe versie, dat is maar 1 stap efficienter dan programmas hun eigen dll laten bewaren...

Mss bewaart hij bij het installeren van een nieuwere versie enkel de verschillen tss de 2 dlls.

Dat lijkt me helemaal funest voor de snelheid. Dan kun je eerst DLL A erbij pakken, vervolgens mutatie B en mutatie C en mutatie D erop toepassen voordat het programma een DLL E krijgt welke hij kan gebruiken... Dan maar 400kb kwijt.

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

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.

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

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.

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

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 :)

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.

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/

Dus nog meer DLL's met ook nog eens database dat de versienummers bijhoudt? En dan ook nog een programmatje dat regelt welke applicatie welke dll gaat gebruiken? Of moet elk programma zelf aangeven welk dll versie hij het liefste heeft? Moeten all leverenciers dus ook weer aan denken bij de ontwikkeling?

Wat nou als je 2 applicaties tegelijk draait, die beide gebruik maken van dezelfde functionaliteit dus DLL, maar een verschillende versie? Dan draaien dus TEGELIJK 2 versies van 1 DLL op je pc???

Nog meer handelingen, en de ervaring leert, dus ook meer potentiele problemen.

.NET applicaties moeten inderdaad zelf aangeven met welke versie van een assembly ze willen werken (dit moet in het manifest staan). Maar wat denk je dat een programmeur liever heeft, zelf aangeven welke versie het programmma nodig heeft om goed te werken, of proberen er voor te zorgen dat het geen problemen heeft met verschillende (zelfs toekomstige) versies van een bepaalde dll?
En het kan idd voor komen dat je twee verschillende versies van een assembly (dll) tegelijk draait op je pc, so what? geheugenruimte is tegenwoordig geen isseu meer, en de verschillende applicaties draaien in hun eigen (afgeschermde) stukje van het geheugen en hebben dus geen invloed op elkaar.
.NET dwing een programmeur idd tot bepaalde handelingen, zoals het goed beschrijven van zijn programma en de afhaneklijkheden in het manifest, maar IMHO zijn dat dingen die een goede programmeur hoort te doen.
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 13:04 Silicon Image 3112 Serial ATA-chip getest
Vorige 12:21 Hackers gebruiken Google om in databases te komen
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011