DLL hell i .NET?

Vi utvecklar ett modulbaserat system. De flesta moduler vi utvecklat än så länge kan sägas tillhöra grundsystemet och har därför byggts utvecklats i själva huvudprojektet.

Men, modulerna borde egentligen ligga i egna projekt och därmed som separata dll-filer som kan användas i olika paketeringar av grundsystemet och moduler. På så sätt kan vi sätta versionsnummer på modulerna och utan problem kopiera modulens dll-fil till en utrullad webbplats.

Det är inga konstigheter att kopiera grundsystemets dll-fil till ett nytt projekt och referera till den. Men, och här inträder problemet, eftersom modulen utvecklas mot just en version av grundsystemets dll-fil, kommer den väl inte fungera mot en annan version av grundsystemets dll-fil, vilket blir aktuellt då vi släpper en ny version av grundsystemet.

Jag skulle gärna vilja höra era kommentarer kring detta.

Lösningen blir väl att behålla de olika versionerna av "grundsystemet" och kompilera moduler anpassade till de olika versionerna. Alternativt kanske det går att sätta samma version för alla grundsystem och på så sätt slippa problematiken, dock vet jag inte om den går efter version eller annan nyckel så som fingerprint eller liknande.

Innehåller sedan grundsystemet funktioner som inte finns i tidigare versioner är det inte mycket att göra som du förstår och då kommer verkligen versionskollen till nytta i .NET.

renholm skrev:

då kommer verkligen versionskollen till nytta i .NET.

Versionskollen? Hur menar du?

Menar att t.ex strong name gör det möjligt att behålla integriteten för sina applikation i och med att det förhindrar att assemblys byts ut mot felaktiga. Samt det du beskriver att kompileras ett projekt med en referens till ett annat måste det även stämma vid runtime.

En lite "klargörning": Du menar alltså att de "fristående" modulerna kommer att finnas i olika versioner för alla klienter?

Dvs. både den logiska och binära kompabiliteten kommer att ändras?