Jak dodać .Net3.5 dll do projektu .Net2.0?

Question

Mam dll, który jest oparty na .net 3.5 - używa wewnętrznie na przykład Linq, ale odsłonięty interfejs API jest prosty, bez żadnych wymyślnych rzeczy. Ponieważ generics C# są rozwiązywane podczas kompilacji, zakładam, że dla strony wywołującej liczy się tylko API (wszystkie części publiczne).

Jednak kiedy próbuję użyć tego dll z projektu net2.0 otrzymuję informację, że dll nie może się odwoływać, ponieważ biblioteka dll lub jedna z jej zależności wymaga późniejszej wersji środowiska .net.

Mogę zainstalować dowolną wersję .net na komputerze docelowym (po zainstalowaniu całej aplikacji), ale nie mogę zmienić wersji .net dla samego projektu.

A więc: jak rozwiązać ten problem? Podczas dodawania pliku dll C do tego projektu nie miałem takich problemów, więc czy biblioteki C# są samodzielne, czy nie?

Answer 1

C# dll muszą uruchamiać środowisko .Net, ponieważ nie są one kompilowane do kodu maszynowego. W tym przypadku biblioteka DLL mówi, że wymaga sieci 3.5, więc cały projekt będzie musiał używać wersji 3.5 lub wyższej.

Aby zachować projekt jako Net 2.0, należy utworzyć inny plik wykonywalny, który będzie zawierał bibliotekę DLL w wersji 3.5 i komunikował się w ramach oddzielnych procesów.

Biblioteka DLL C działała, ponieważ jest skompilowana do kodu natywnego i nie wymaga środowiska .Net. (A przynajmniej nie w wersji wyższej niż 2.0)

Answer 2

Jeśli używasz LINQ do obiektów, a następnie można użyć LINQ Bridge: http://www.albahari.com/nutshell/linqbridge.aspx

to jest LINQ do obiektów realizacja dla .NET 2.0.

Nadal będziesz musiał skompilować używając vs2008, ale możesz skompilować z .net 2.0 jako platformą docelową w tym przypadku. (Dzieje się tak, ponieważ kompilator języka C# 3 rozumie klauzule LINQ, nawet jeśli kierujesz go na .net 2.0, to po prostu rozwiąże on wywołania do linqbridge zamiast bibliotek .NET 3.5 w tym przypadku)

Answer 3

Biblioteki DLL C# nie są autonomiczne . Jeśli 3.5 biblioteka DLL wymaga LINQ, zależy to od złożeń systemu od struktury 3.5 (dokładnie 3.0), dlatego cała aplikacja zależy od tej wersji.

Można dynamicznie załadować zestaw 3.5 i użyć odbicia, aby uzyskać dostęp do potrzebnych funkcji. Oczywiście wymaga to trochę więcej kosztów.

Answer 4

Używam System.Core a nowe System.Web.Extensions (na przykład) z 3,5 na 2,0 w ​​aplikacji ASP.NET (przy użyciu VS2005) na chwilę się bez żadnych problemów. Podobne do tego, o czym Scott Hanselman napisał na blogu na temat here. Więc tak, to możliwe.

.NET 3.5 nadal działa na tym samym CLR co .NET 2.0. Tak więc w czasie wykonywania jest tak samo. (Zakładając, że wyśledziłeś wszystkie zależności i skopiowałeś te pliki DLL 3.5 do folderu bin również).

Jedynym prawdziwym ograniczeniem jest to, jakie funkcje języka C# można użyć w czasie programowania. Takich jak "var", metody rozszerzenia lub składnia zapytania LINQ.

Answer 5

Jeśli korzystasz z bibliotek .NET 3.5, to wymagania aplikacji powinny być takie, aby każdy użytkownik jej interfejsu API również korzystał z .NET 3.5.

Jedynym sposobem można ominąć to jeśli pakiet wszystkie zależności swojej aplikacji wraz z nim. Oznacza to biblioteki używane przez aplikacje, które są oparte na frameworkach .NET 3.0.

Jednak nie jestem pewien co do legalności wyrzucania fragmentów frameworków .NET i pakowania ich za pomocą aplikacji. Przeczytałem EULA zanim zrobiłem coś takiego. IMO, to nie jest warte kłopotów; po prostu zainstaluj 3.5, poproś użytkowników, aby zainstalowali 3.5 i skończcie z nim albo korzystajcie tylko z 2.0 funkcji i bibliotek. Co najmniej, hackowanie w ten sposób spowoduje jeszcze większy ból po wdrożeniu, jeśli w przyszłości będą dostępne aktualizacje szkieletowe.

W obu przypadkach Twoja aplikacja będzie działać na .NET 2.0 jako 3.0 i 3.5, to tylko dodatkowe biblioteki w górnej części środowiska wykonawczego 2.0 i bibliotek (jak wspomniał Craig), o ile są w nim wszystkie zależności.

Answer 6

Nic nie całkiem, ale istnieją sposoby, aby uzyskać kod szczęśliwie pracuje razem (w kolejności preferencji):

1) Upgrade obu projektów do 3,5

Jeśli rozumiem zostanie poprawnie wówczas. Program netto FW 2.0 będzie miał zależność od biblioteki 3.5, co oznacza, że ​​dla każdej funkcjonalności Programu działa teraz FW 3.5. Ponieważ twierdzisz, że posiadasz kod i uprawnienie do rekompilacji Programu i zainstalowania dowolnego FW podczas wdrażania, możesz go zaktualizować do wersji 3.5. Brzmi prosto, ale ponieważ tego nie zrobiłeś, to myślę, że masz dobre powody (jak inne programy, które są wyżej w łańcuchu połączeń, których nie możesz zaktualizować do wersji 3.5/rekompilacji).

2) Przejdź wokół FW2. 0 kompilator

Twórz program, odwołując się do wersji 2.0 Biblioteki (lub manekina, udostępniając tylko publiczny interfejs API). Wykonaj osobną wersję Biblioteki 3.5 bez programu (usuwając tym samym konieczność odwoływania się do niewłaściwego zespołu FW) i wdrażaj wersję 3.5 zamiast wersji 2.0. Od wersji 2.0 i 3.5 korzysta się z tego samego środowiska uruchomieniowego środowiska CLR, wystarczy więc oszukać kompilator. Tak długo, jak maszyna do wdrażania ma zainstalowaną wersję FW 3.5, wszystko powinno być w porządku. Uwaga: wszystko jest w porządku, nawet jeśli na komputerze wdrożonym znajduje się właśnie .net 2.0, a użytkownik nie wywołuje klas .net 3.5. Jeśli to zrobi, nie będzie katastrofy;)

3) Biblioteka downgrade do 2,0

jeśli używasz tylko niektóre zajęcia z FW .net następnie można pozostać przy użyciu kompilatora 2.0 poprzez dodanie brakujących przyszłość złożeń do projektu. (to jest rozwiązanie z linku Hanselman udostępnionego przez Craiga). Jak już wspomniano, utracisz syntaktyczny cukier składający się z 3.5 kompilatora.

Wybierz tę, która najlepiej pasuje do Twojej sytuacji.