[.NET] Versie onafhankelijke DLL

[Exterazzo]

Ik probeer in C# een classlibrary te schrijven die gebruik maakt van externe DLL's. Deze DLL's heb ik dan ook als reference in mijn project. Nu kan het echter zijn dat deze externe DLL's een nieuwe versie krijgen (omdat er bijvoorbeeld een bug in gehotfixed wordt). De API-calls in deze DLL's wijzigen gelukkig niet.

Als ik nu gebruik maak van mijn DLL en die externe DLL's krijgen een hoger versienummer, krijg ik (uiteraard) de volgende foutmelding:

Assembly 'xxx' uses 'yyy' which has a higher version than referenced assembly 'yyy'

Omdat mijn library een soort uitbreiding is op de externe DLL's, wil ik niet steeds mijn DLL hoeven te compileren met de nieuwe references. Tevens kan het ook zo zijn dat die externe DLL's in verschillende projecten, verschillende versies hebben.

Ik heb de volgende dingen al geprobeerd:

- Bij de references van de externe DLL's specific version op "false" gezet. Dit geldt volgens mij alleen voor compile-time en niet voor run-time.
- Geprobeerd om in mijn classlibrary AppDomain.CurrentDomain.AssemblyResolve te gebruiken. Omdat een classlibrary geen module initializer heeft (http://stackoverflow.com/...-class-library-in-c-sharp), gebruik ik een static class welke ik steeds aanroep, maar dat werkt helaas ook niet.
- In de web.config kan ik versie nummers overrulen, maar dat betekent dat ik dat moet doen in het project dat weer gebruikt maakt van mijn DLL, dat wil ik eigenlijk niet. Ik wil dat mijn DLL het probleem zelf oplost.

Hoe kan ik mijn probleem oplossen? En zie ik misschien iets triviaals over het hoofd?

[HMS]

Heb je de documentatie al geraadpleegd? (link: MSDN: Redirecting Assembly Versions)

[Exterazzo]

HMS schreef op donderdag 19 september 2013 @ 15:14:
Heb je de documentatie al geraadpleegd? (link: MSDN: Redirecting Assembly Versions)

Ja, dat bedoel ik met mijn laatste puntje. Als ik dat goed begrijp moet ik dan bijvoorbeeld de web.config in mijn web-project aanpassen. Terwijl ik dat liever niet wil, omdat ik die abstractie in mijn classlibrary wil houden.

Edit: Ik bedenk me net wel dat ik dit inderdaad nog niet heb geprobeerd in de app.config van mijn classlibrary. Dat ga ik nog even proberen.

Edit 2: Dat gaat ook niet werken, daarnaast moet ik dan alsnog een versienummer opgeven wat uiteindelijk gebruikt moet worden. Omdat dat in verschillende projecten anders kan zijn, weet ik dat niet. Ik heb dus liever dus hij eigenlijk gewoon heel die versie check negeert en gewoon probeert die externe DLL te laden

[ Voor 32% gewijzigd door Exterazzo op 19-09-2013 15:35 ]

[HMS]

Hmm, dan weet ik ook zo geen oplossing. Maar als de versies inderdaad zo verschillend zijn in verschillende projecten, ben je dan niet beter af door de library gewoon als project op te nemen in de solution (eventueel als git submodule o.i.d.)? Of misschien een NuGet package er van te maken?

Eventueel zou je moeten gaan standaardiseren op bepaalde versies, maar die overweging is aan jou.

[AtleX]

Kan je de assembly niet laden door middel van Reflection en dan de juiste class instantiëren? Ik snap trouwens niet waarom je niet gewoon tegen een bepaalde versie aan wilt bouwen en nieuwe versies van je lib uit wilt brengen als de andere lib geupdate wordt? Dat beschermt je tegen breaking changes in de API daarvan en je kan je support end-to-end testen.

[eek]

Je zou er ook voor kunnen kiezen om de versie van de dll aan te passen. Dan moet je nog wel goed opletten dat er geen breaking API changes zijn. Hier wat uitleg over hoe je dat zou kunnen doen: http://www.codeproject.co...d-C-VB-NET-Code-Injection

[Grijze Vos]

Als 3.1.X en 3.1.Y binary compatible zijn dan zou ik ze allebei assembly version 3.1.0.0 geven, en als assembly file version 3.1.X en 3.1.Y. Op die manier hoef je niet binding redirects toe te voegen voor elke scheet.

Als je zelf de builds niet doet, of niet kan aanpassen, dan zul je assembly redirects moeten gebruiken, of de API client applicatie rebuilden.

[Exterazzo]

AtleX schreef op donderdag 19 september 2013 @ 16:23:
Kan je de assembly niet laden door middel van Reflection en dan de juiste class instantiëren? Ik snap trouwens niet waarom je niet gewoon tegen een bepaalde versie aan wilt bouwen en nieuwe versies van je lib uit wilt brengen als de andere lib geupdate wordt? Dat beschermt je tegen breaking changes in de API daarvan en je kan je support end-to-end testen.

Ik zou die oplossing graag willen, helaas zijn we in het proces nog niet zover dat we overal dezelfde API gebruiken.

Ik ga het nu overigens oplossen door het inderdaad via NuGet gewoon in het project te plaatsen, dan heb ik geen last meer van de DLL problemen

Bedankt voor jullie input.