2012-01-12 8 views
5

Sytuacja
uruchomić system gromadzenia, który wykonuje wiele buduje dla wielu projektów. Aby uniknąć jednej kompilacji wpływającej na inną, blokujemy użytkownika kompilacji tylko do jego obszaru roboczego. Kompilacje działają jako nieuprzywilejowani użytkownicy, którzy mają tylko możliwość zapisu w obszarze roboczym.Jak można używać C# DLL starszego prostu bez rejestracji (regsvr32)

Wyzwanie
Podczas naszej nowej kompilacji musimy użyć starszego 3rdParty DLL, który udostępnia swój interfejs poprzez COM. Zespół programistów chce zarejestrować kompilację (regsrv32.exe), ale nasz system zabezpieczeń kompilacji blokuje to działanie. Jeśli rozluźnimy reżim, wówczas trzecia strona DLL będzie miała wpływ na inne kompilacje i jeśli mam dwie kompilacje, które potrzebują dwóch różnych wersji, mogę mieć niewłaściwą kompilację kompilacji przeciwko niewłaściwej wersji (bardzo realna możliwość).

Pytanie
Czy są jakieś inne opcje oprócz rejestracji do obsługi starszych DLL, które narażają ich pośrednictwem interfejsu COM?

Dzięki za pomoc

Peter

+0

w .NET COM jest zwykle wykonywane przez Interop w celu rejestracji .DLL w .NET nazywa się Złożenia i można to zrobić na kilka sposobów .. poprzez dodanie referencji za pośrednictwem VS IDE na poziomie projektu, lub pisania kodu, który ładuje i rozładowuje złożenie .. przez plik .config, który zawiera odniesienie do zespołu, a także użycie tego odniesienia w projekcie ... GAC .. – MethodMan

+0

Rejestracja jest * nigdy * konieczna podczas kompilacji. COM używa biblioteki typów do ujawnienia interfejsów. Jeśli zobaczysz, że Regasm.exe jest używany, to robisz to źle. Użyj pliku Tlbexp.exe –

Odpowiedz

2

Jest solucja na rejestracyjnego wolne COM tutaj:

http://msdn.microsoft.com/en-us/library/ms973913.aspx

I rozdzierający szczegółów tutaj: http://msdn.microsoft.com/en-us/library/aa376414 (korzeń tego dokumentu jest faktycznie tutaj: http://msdn.microsoft.com/en-us/library/dd408052)

Również dla budowanie w ogóle, powinieneś być w stanie użyć Tlbimp lub tlbexp do stworzenia pliku TLB, którego możesz użyć do budowania, przy założeniu, że rejestracja jest możliwa tylko po to, aby pomyślnie skompilować i nie uruchamiać określonego testu s.

1
  • Jeśli masz dostęp do 3rd party DLL może je GAC i odwoływać się do nich w projekcie
  • można dodać używając do listy .cs plik nagłówka, a także dodać odniesienie do projektu, klikając prawym przyciskiem myszy na odwołanie -> dodaj odniesienie ...
  • można również wykonać powyższy krok, a także ustawić kopię local = true we właściwościach dla tego .dll .. Mam nadzieję, że to daje ci kilka pomysłów .. należy pamiętać, że zespoły są NET kod zarządzany tak, istnieje kilka sposobów, aby konsumować te 3rd party przy użyciu innych metod .dll jest w C# jak LoadFromAssembly ect ..
1

Narzędzia instalacyjne takie jak Installshield można wyodrębnić interfejsów COM od DLL i dodaj je do rejestru. Może również użyć procesu autorejestracji biblioteki DLL (co uważam za regsvr), ale nie jest to Microsoft installer best practice.

0

Dzięki za pomoc. Zmieniliśmy z wczesnego wiązania na późniejsze, ponieważ nigdy nie potrzebowaliśmy biblioteki DLL w czasie kompilacji. Spowodowało to konieczność rejestracji z serwera kompilacji na serwer testowy integracji (gdzie uruchamiamy instalator, który obsługuje rejestrację). Staramy się, aby system budowy był nieskazitelny i miał łatwe do zresetowania systemy integracyjne.

Dzięki ponownie Peter

6

Na mój oryginalny odpowiedź na podobne pytanie patrz: TFS Build server and COM references - does this work?

Dobrym sposobem do kompilacji kodu .NET odwołujący komponentów COM bez komponentów COM są zarejestrowane na serwerze kompilacji jest używać elementu odniesienia COMFileReference w pliku projektu/kompilacji zamiast COMReference. COMFileReference pozycja wygląda następująco:

<ItemGroup> 
    <COMFileReference Include="MyComLibrary.dll"> 
    <EmbedInteropTypes>True</EmbedInteropTypes> 
    </COMFileReference> 
</ItemGroup> 

Od Visual Studio nie zapewnia wsparcia dla COMFileReference projektant, należy zmodyfikować projekt/zbudować plik ręcznie.

Podczas kompilacji MSBuild wyodrębnia informacje o bibliotekach typów z biblioteki DLL COM i tworzy zespół współdziałania, który może być samodzielny lub osadzony w wywołującym zestawie .NET.

Każdy element COMFileReference może mieć również atrybut WrapperTool, ale ustawienie domyślne sprawdziło się w moim przypadku. Atrybut EmbedInteropTypes nie został udokumentowany jako mający zastosowanie do COMFileReference, ale wydaje się działać zgodnie z przeznaczeniem.

Aby uzyskać nieco więcej szczegółów, zobacz artykuł http://msdn.microsoft.com/en-us/library/bb629388.aspx. Ten element MSBuild jest dostępny od .NET 3.5.

Szkoda, że ​​nikt nie wie nic o tej technice, co wydaje mi się prostsze niż alternatywy. To naprawdę nie jest zaskakujące, ponieważ mogłem znaleźć tylko powyższe odniesienie do niego w Internecie. Sam odkryłem tę technikę, kopiując do pliku Microsoft.Common.targets MSBuilda.

Powiązane problemy