Microsoft.SqlServer.Types.dll w pamięci podręcznej Global Assembly Cache?

Question

Obecnie mam problemy z wdrożeniem spowodowane przez Microsoft.SqlServer.Types i związaną z nim niezarządzaną bibliotekę, SqlServerSpatial110.dll - zarówno dla Microsoft SQL Server 2012. Problemy są trywialnie łatwe do rozwiązania, tylko typowe problemy z brakujące DLL problemy, ale staram się zdecydować na idealny sposób radzenia sobie z tymi zależnościami.

Po pierwsze, muszę zadeklarować, że nie zgadzam się z popularną opinią, że ręczne rozmieszczenie którejkolwiek z bibliotek (zazwyczaj poprzez skopiowanie ich do katalogu wyjściowego twojego projektu lub, przerażająco, do samej System32) jest poprawne. Firma Microsoft zapewnia redystrybucyjne instalatory MSI dla tych plików, a te instalatory umieszczają pliki w lokalizacjach systemowych. Wydaje się oczywiste, że chcą, abyśmy polegali na tych redystrybucjach instalowanych osobno lub w ramach wypróbowanych i przetestowanych mechanizmów zależności wbudowanych w sam MSI.

W czasie delegowania, najnowsza wersja tych redystrybucyjnych można pobrać z: http://www.microsoft.com/en-gb/download/details.aspx?id=43339

Dla SqlServerSpatial110.dll, nie wydaje się być żadnego problemu. Instalatory MSI (specyficzne dla platformy) upuszczają plik do wersji Windows\System32 lub Windows\SysWOW64 zgodnie z wymaganiami i wszystko jest w porządku.

Zarządzana biblioteka otoki, Microsoft.SqlServer.Types.dll, jest bardziej zagmatwana.

Wydaje mi się, że plik został upuszczony do pamięci podręcznej zespołu globalnego - po uruchomieniu MSI na moim komputerze widzę go pod adresem C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.Types\11.0.0.0__89845dcd8080cc91\Microsoft.SqlServer.Types.dll i plik ten ma poprawną wersję i datę modyfikacji.

Dziwne, nie widzę tego w przeglądarce odniesienia Visual Studio lub bezpośrednio w Eksploratorze Windows - tylko w moim bardzo starym systemie wyszukiwania plików przez Mythicsoft. Dlaczego nie widzę tego?

Ponieważ plik jest prawie w GAC, to myślę, że projekty odwoływania się go powinno nie zrobić lokalną kopię niego - powinny one polegać na to będąc tam w systemie docelowym. Przetestowałem to założenie i to działało:

1. ręcznie skopiować Microsoft.SqlServer.Types.dll od jego lokalizacji w C:\Windows\assembly\GAC_MSIL
2. Dodaj odwołanie do kopii.
3. Upewnić się, że wniosek ma Copy Local zestaw do False
4. budowania projektu i upewnić się, że Microsoft.SqlServer.Types.dll na pewno nie jest obecny na wyjściu.
5. Projekt testowy ... żadnych problemów!

Tak więc, jeśli zespół może zostać rozwiązany z GAC w czasie wykonywania w celu spełnienia tej zależności, dlaczego nie jest wyświetlany w przeglądarce referencyjnej podczas dodawania odniesienia? Dlaczego muszę go skopiować z GAC i odwołać się do kopii?

W moim uwadze, idealny przepływu pracy byłoby to:

1. zainstalować redystrybucyjny MSis na maszynach rozwoju.
2. Upewnij się, że redystrybucja jest zainstalowana na komputerach docelowych, wymieniając ją jako zależność MSI, jeśli produkt został wdrożony za pomocą MSI lub ręcznie instalowany, jeśli używasz wdrożenia "xcopy".
3. Odwołanie Microsoft.SqlServer.Types z GAC przy użyciu przeglądarki referencyjnej, tak jak każdej biblioteki framework. (Copy Local zostanie domyślnie ustawiony na False).
4. W czasie wykonywania, z poziomu GAC zostanie usunięta Microsoft.SqlServer.Types (agnostyka platformowa), a odpowiednia kopia biblioteki niezarządzanej zostanie załadowana z lokalizacji systemu w zależności od architektury procesu.
5. Bez obaw!

Oczywiście, krok 3 się nie dzieje. Czy czegoś brakuje? Być może nie rozumiem samego GAC - nie byłby to pierwszy raz. Dlaczego Microsoft zrobił to w ten sposób? Czy mogę zbliżyć się do mojego idealnego przepływu pracy?

Być może jest zupełnie inny sposób zarządzania tą zależnością - coś, o czym wyraźnie nie pomyślałem. Jeśli tak, co to jest? Jak sobie z tym radzisz?

Answer 1

Jeśli jest to wdrożenie jednym kliknięciem, przejdź do karty Projekt | Właściwości | Opublikuj i kliknij przycisk "Pliki aplikacji ...". Następnie wybierz plik zależny i upewnij się, że opcja "Uwzględnij (Auto)" jest wybrana dla wartości "Stan publikacji". Powodem jest to, że wygląda na to, że VS jest wystarczająco inteligentny, aby określić, czy plik jest częścią znanej redystrybucji, a to daje możliwość uzależnienia się od zewnętrznego pakietu podczas instalacji jako zależności lub samodzielnego zarządzania plikiem. Jeśli jesteś zależny od pakietu, to użytkownik końcowy może odinstalować go przez dodanie programów usuwania, a twoja aplikacja zostanie usunięta:/