2009-12-28 7 views
5

Napisałem przystawkę w języku C#.Instalacja niestandardowych przystawek MMC

Próbowałem zainstalować go przy użyciu installutil i na początku nie działał. Zauważyłem, że na stronie msdn powiedzieli, że uruchamiają mmcperf, aby zainstalować plik management.dll w GAC.

W ten sposób udało mi się zainstalować mój przystawkę i uruchomić go. Mam maszynę XP.

Moje pytanie brzmi: w jaki sposób mogę wdrożyć moją wtyczkę niestandardową na komputerze klienta ... Jakie rzeczy muszę wziąć pod uwagę? (OS ?, framework .net, jest zainstalowany mmc 3.0, itp?)

Czy mogę uruchomić mmcperf podczas instalacji mojego przystawki? Czy to dobre podejście?

Odpowiedz

8

Problem może być inny, ale raz napotkałem podobny problem na maszynie 64-bitowej i dowiedziałem się, co następuje. Jeśli Twój problem nie jest związany z wersją 32/64-bitową, nie mogę powiedzieć, na czym polega problem, i przepraszam za poświęcenie czasu.

Powinieneś być w stanie zainstalować przystawkę za pomocą InstallUtil. Należy jednak zauważyć, że istnieją dwie oddzielne wersje na InstallUtil: Jeden (domyślny) dla binariów x86 i jeden dla binariów x64.

Nawet jeśli skompilujesz swój kod C# dla Dowolny procesor, przy użyciu standardowej InstallUtil zarejestruje się tylko przystawkę MMC jako 32-bitową przystawkę. Jeśli używasz 64-bitowego systemu operacyjnego, spróbuj uruchomić MMC jako proces 32-bitowy (MMC /32 IIRC) i sprawdź, czy przystawka nie jest tam dostępna.

Aby zarejestrować przystawkę jako przystawkę 64-bitową, należy użyć 64-bitowej wersji InstallUtil (zwykle znajdującej się w C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727)

Aby zarejestrować obie wersje przystawki, należy zarejestrować ją dwukrotnie.

+0

Dziękuję, mimo że nie rozwiązuje to bezpośrednio mojego problemu, dobrze jest wiedzieć. Tworzę MSI z niestandardowymi akcjami, które instalują dane wyjściowe projektu. Jeśli jest to maszyna 64-bitowa, czy mam rację, zakładając, że uruchomi instalację 64-bitową wersję podczas instalacji? – pdiddy

+0

Naprawdę nie jestem pewien, ale pliki AFAIR msi są albo 32-bitowe, albo 64-bitowe, więc jeśli nie jest to jawnie 64-bitowy MSI, myślę, że będzie to wersja 32-bitowa. Możesz jednak łatwo to sprawdzić, otwierając MMC w trybie 32-bitowym, aby sprawdzić, czy jest tam dostępna przystawka. Naprawdę wszystko sprowadza się do tego, w którym węźle rejestru rejestrowana jest przystawka. –

3

Dodawanie do Mark Seemanna odpowiedzi:

Można również sprawdzić wpisy rejestru MMC bezpośrednio, w celu sprawdzenia, czy przystawka została zarejestrowana we wpisach rejestru 64 bitowych lub 32-bitowy przekierowany rejestru (ten, który pokazuje się pod Wow6432Node):

  • 64 bit przystawka: HKLM \ Software \ Microsoft \ MMC \ SNAPINS \ FX: {SNAP-IN-GUID} ...
  • 32-bitowy przystawka: HKLM \ Software \ Wow6432Node \ Microsoft \ MMC \ SnapIns \ FX: {SNAP-IN-GUID} ...

Jeśli twoje wpisy są tylko w HKLM \ Software \ Wow6432Node, to zarejestrowałeś 32-bitowe snapiny, a wskazówki Marka dotyczące uruchamiania "MMC/32" powinny uczynić je widocznymi. To nie koniec świata: jeśli zapiszesz sesję MMC jako skrót, myślę, że po uruchomieniu otwiera ona 32-bitową wersję MMC.

Jeśli naprawdę chcesz mieć 64-bitową rejestrację snapin (i dlaczego nie?), MSDN ma stronę na MMC 64-Bit Versus 32-Bit Considerations z dodatkowymi szczegółami, w tym ścieżkami InstallUtil do wywoływania, aby uzyskać wpisy rejestru w wersji 64- lub 32-bitowej.

Należy jednak zauważyć, że niektóre aplikacje do pakowania MSI faktycznie zawierają kopię InstallUtil.exe w samym MSI jako plik binarny zamiast wywoływania tego na komputerze docelowym.(Możesz sprawdzić, czy tak się dzieje, patrząc na tabelę binarną MSI i akcje niestandardowe, używając Orca.) Jeśli dołączona jest tylko 32-bitowa instalacja InstallUtil, spowoduje to, że twoja rejestracja będzie w złym miejscu (Wow6432Node), dla ciebie ciężko.

Jak rozumiem, Instalator Windows "Właściwa droga" (TM) nie powinien w ogóle używać InstallUtil (myślę, że głównie z powodu problemów związanych z uruchamianiem zarządzanych niestandardowych działań MSI?). W każdym razie, jeśli unikniesz użycia InstallUtil, całkowicie zarejestrujesz swoje przyciąganie, tworząc wpisy rejestru jawnie w MSI, umieszczając Instalatora Windows w kontroli nad ich tworzeniem i usuwaniem.

Alternatywnie, można zrobić niestandardową akcję do powoływania się InstallUtil.exe w folderze Framework64 urządzenia docelowego. Uzyskałoby to właściwą lokalizację rejestracji snapin, ale wtedy musiałbyś sobie poradzić z tym, że niestandardowa akcja wyświetliłaby okno powłoki CMD podczas działania, jeśli ci to przeszkadza. Nie jestem pewien, czy twoje narzędzie do tworzenia MSI ma odpowiednik, ale w WiX jest Quiet Execution Custom Action. (Przypuszczam, że jeśli nie korzystasz z WiX, nadal możesz włączyć WixUtilExtension.dll i wywołać "CAQuietExec64" po prawidłowym skonfigurowaniu właściwości QtExec64CmdLine ... ale jeśli pracujesz na tym poziomie tworzenia MSI, prawdopodobnie będziesz lepszy wystarczy, aby zmienić i używać WiX :)