Wczytanie do aplikacji dostępnej wersji biblioteki, a nie przypisanej w Visual Studio

Witam.
Potrzebuje nakierowania jak ustawić Visual Studio żeby nie brało konkretnej wersji, która została podpięta do projektu, a zawsze brał dostępną z systemu. Mam taki problem, zwłaszcza przy DDLkach do Comarch Optima, że jak klient robi update ERPa to muszę też zrobić ten update w swojej aplikacji. Biblioteki są zawsze z tą samą nazwą, nie ma opcji żeby uzywać starszej wersji niż ta, która jest zainstalowana (erp nie puści z błędem, ze baza jest nowsza niż dll).

To samo, na przykład, dzieje się z Newtonsoft.Json, albo RestSharp. Optima też korzysta z tych bibliotek i po aktualizacji niektóre programy przestają działać, bo mają inną wersje niż Optima, przeważnie nowszą. Jak przekopiuje swoje DDLki to Optima nie wali błędem, że Newtosoft albo RestSharp jest w złej wersji, więc jakoś da się to zrobić

Comarch twierdzi, że żeby "działało" to to trzeba wpisać Directory.SetCurrentDirectory(), ale to nie działa. Trzeba robić cyrki z CurrentDomain_AssemblyResolve i tam wczytywać potrzebne DLLki podając ścieżkę do zainstalowanej Optimy.

Jak w Visual Studio mam starszą wersję, a nowsza jest zainstalowana to mam taki błąd

: 'Metoda 'get_LoginData' w typie 'Optima.Common.Logic.OptimaContext' z zestawu 'Common.Logic, Version=2024.2.2.0, Culture=neutral, PublicKeyToken=5179454a0b814fab' nie ma implementacji.'

Comarch funkcji logowania nie zmienił od 5 lat, ta metoda tam jest, ale pod Visual Studio mam tą bibliotekę Common.Logic.dll wrzuconą w wersji 2024.2.2.0, a zainstalowaną mam 2024.3.1.0.

Ja miałem podobny problem ale z insert nexo. Rozwiązałem go dodając userowi plik bat, który odpalał po aktualizacji nexo a który kopiował wszystkie potrzebne pliki z katalogu nexo do katalogu mojej aplikacji i zastępował stare przez nowe. Proste i skuteczne

OMG tyle lat i dalej .NET nie potrafi sobie tego sam ogarnąć?

Czemu po prostu nie usuniesz tych dllek i wtedy będą się brały z systemu? Po prostu ich nie deployuj z aplikacją lub ustaw w referencjach "Copy local" na false
AssemblyResolver to nie jest cyrk tylko ewentualne drugie proste rozwiązanie tego problemu

Bez podłączonych DLLek do projektu nie mam jak pisać kodu, który jest potrzebny do poprawnego działania. Czy czegoś nie rozumiem po tylu latach?

obscurity napisał(a):

Czemu po prostu nie usuniesz tych dllek i wtedy będą się brały z systemu?

na 99% one nie są w GACu więc to nie zadziała

No chyba nie rozumiesz. Dll-ki normalnie dodajesz do referencji ale zaznaczasz żeby się nie kopiowały, wtedy jak uruchamiasz program to bierze te z systemu. Jeśli nie masz na środowisku developerskim ich zainstalowanych to je zainstaluj lub po prostu usuń zanim dasz aplikację klientowi

Jeśli ich nie ma w GACu to możesz też dodać ścieżkę do optimy jako private path: https://stackoverflow.com/questions/1892492/set-custom-path-to-referenced-dlls