SQL Server Management Studio 18 nie otwiera się (pojawia się tylko ekran powitalny)

Właśnie zainstalowałem SSMS 18 GA na komputerze z zainstalowanym tylko VS2019, a kiedy próbuję otworzyć SSMS, pojawi się ekran powitalny, ale wtedy proces się kończy.

Uruchomienie ssms z -logparametrem ujawnia komunikat o błędzie:

Tworzenie pakietu nie powiodło się dla pakietu [Pakiet harmonogramu zadań] Źródło: „mscorlib” Opis: Nie można załadować pliku lub zestawu „Microsoft.VisualStudio.Shell.Interop.8.0, Wersja = 15.0.0.0, Kultura = neutralny, PublicKeyToken = b03f5f7f11d50a3a” lub jednego z jego zależności. Definicja manifestu zlokalizowanego zespołu nie pasuje do odwołania do zespołu. (Wyjątek od HRESULT: 0x80131040) System.IO.FileLoadException: Nie można załadować pliku lub zestawu „Microsoft.VisualStudio.Shell.Interop.8.0, Wersja = 15.0.0.0, Kultura = neutralna, PublicKeyToken = b03f5f7f11d50a3a” lub jednej z jej zależności. Definicja manifestu zlokalizowanego zespołu nie pasuje do odwołania do zespołu. (Wyjątek od HRESULT: 0x80131040) Nazwa pliku: „Microsoft.VisualStudio.Shell.Interop.8.0, wersja = 15.0.0.0, kultura = neutralna, PublicKeyToken = b03f5f7f11d50a3a „---> System.IO.FileLoadException: Nie można załadować pliku lub zestawu„ Microsoft.VisualStudio.Shell.Interop.8.0, Wersja = 8.0.0.0, Kultura = neutralny, PublicKeyToken = b03f5f7f11d50a3a ”lub jednej z jego zależności . Definicja manifestu zlokalizowanego zespołu nie pasuje do odwołania do zespołu. (Wyjątek od HRESULT: 0x80131040) Nazwa pliku: „Microsoft.VisualStudio.Shell.Interop.8.0, wersja = 8.0.0.0, kultura = neutralna, PublicKeyToken = b03f5f7f11d50a3a”

WRN: Rejestrowanie powiązania zestawu jest wyłączone. Aby włączyć rejestrowanie niepowodzenia powiązania zestawu, ustaw wartość rejestru [HKLM \ Software \ Microsoft \ Fusion! EnableLog] (DWORD) na 1. Uwaga: Z rejestrowaniem niepowodzenia powiązania zestawu wiąże się pewna utrata wydajności. Aby wyłączyć tę funkcję, usuń wartość rejestru [HKLM \ Software \ Microsoft \ Fusion! EnableLog].

w System.Reflection.RuntimeAssembly.GetType (zestaw RuntimeAssembly, nazwa ciągu, typ logiczny throwOnError, typ logiczny ignoreCase, ObjectHandleOnStack) w System.Reflection.RuntimeAssembly.GetType (nazwa łańcuchowa, Boolean throwOnError, Boolean System ignoruje. assemblyString, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object [] args, CultureInfo culture, Object [] aktywacjaAtrybuty, Dowody securityInfo, StackCrawlMark & ​​stackMark) w System.Activator.CreateInstance (nazwa zestawu String, nazwa typu ciągu) .CreateInstance (String stringName, String typeName)

System.IO.FileLoadException: Nie można załadować pliku lub zestawu „Microsoft.VisualStudio.Shell.Interop.8.0, Wersja = 8.0.0.0, Kultura = neutralna, PublicKeyToken = b03f5f7f11d50a3a” lub jednej z jej zależności. Definicja manifestu zlokalizowanego zespołu nie pasuje do odwołania do zespołu. (Wyjątek od HRESULT: 0x80131040) Nazwa pliku: „Microsoft.VisualStudio.Shell.Interop.8.0, wersja = 8.0.0.0, kultura = neutralna, PublicKeyToken = b03f5f7f11d50a3a”

WRN: Rejestrowanie powiązania zestawu jest wyłączone. Aby włączyć rejestrowanie niepowodzenia powiązania zestawu, ustaw wartość rejestru [HKLM \ Software \ Microsoft \ Fusion! EnableLog] (DWORD) na 1. Uwaga: Z rejestrowaniem niepowodzenia powiązania zestawu wiąże się pewna utrata wydajności. Aby wyłączyć tę funkcję, usuń wartość rejestru [HKLM \ Software \ Microsoft \ Fusion! EnableLog].

Próbowałem uruchomić „Napraw” w SSMS i próbowałem naprawić C:\ProgramData\Package Cache\{AAA9F15B-AF45-4562-9991-93A848D3A902}v15.0.28307.421\redist\vs2017_isoshell_for_ssms.msi, ale problem nadal występuje.

Właśnie nałożyłem Microsoft.VisualStudio.Shell.Interop.8.0.dll C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\PublicAssembliesna kopię z ..\PrivateAssemblies\Interopi IDE otwiera się. (Podziękowania dla Mitcha za wykrycie obrażającej nazwy DLL).

To dziś wygląda na popularne pytanie i odpowiedź, więc cieszę się, że to nie tylko ja.

Jak zaleca Ronan Ariely , opublikowano oficjalne rozwiązanie, które zaleca usunięcie linii z ssms.exe.config.

W C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <!-- ...snip... -->
    <runtime>
        <!-- ...snip... -->
        <!-- Remove this line (~line 38) -->
        <NgenBind_OptimizeNonGac enabled="1" />
        <!-- ...snip... -->
    </runtime>
    <!-- ...snip... -->
</configuration>

Jeśli uruchomiłeś moje poprzednie rozwiązanie dodawania zestawu do GAC, prawdopodobnie powinieneś go odinstalować, uruchamiając:

gacutil /u Microsoft.VisualStudio.Shell.Interop.8.0,Version=15.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a

Jest to znany problem i pojawiło się nowe oficjalne obejście opublikowane przez zespół programistów SSMS.

Możesz zobaczyć otwarty bilet w systemie Microsoft Feedback w następującym linku: https://feedback.azure.com/forums/908035-sql-server/suggestions/37502512-ssms2018-installed-but-will-not-run

Krótka historia:

Pierwszym obejściem tego problemu było skopiowanie pliku:Microsoft.VisualStudio.Shell.Interop.8.0.dll

z katalogu: C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\PrivateAssemblies\Interop

do katalogu: C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\PublicAssemblies

Później opublikowano bardziej ukierunkowane rozwiązanie (tego właśnie użyłem): po prostu usuń plikC:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\CommonExtensions\Platform\Microsoft.VisualStudio.MinShell.Interop.pkgdef

W każdym razie kilka dni temu zespół opublikował aktualizację, jak widać w powyższym linku. Oto cytat z oficjalnej zaktualizowanej odpowiedzi:

Tymczasowo zalecane obejście:

1) Zamknij wszystkie wystąpienia SSMS

2) Edytuj ssms.exe.config

3) Usuń wiersz z następującym tekstem (powinien to być wiersz 38): NgenBind_OptimizeNonGac włączony = „1”

To ta sama zmiana, która będzie w następnym wydaniu SSMS 18.x

Uwaga! lokalizacja pliku ssms.exe.config znajduje się w folderze:C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE

Właśnie rozwiązałem ten sam problem na świeżo zbudowanym serwerze 2016 z SQL Server 2017 i SSMS 18.0, jednak zniknął po 2 ponownych uruchomieniach, podczas których serwer został w pełni załatany łatami O / S z marca 2019 r. Spróbuję wykonać więcej testów, aby dowiedzieć się, czy to naprawdę łatki O / S pomagają w tym, ale nie jestem świadomy niczego innego instalowanego w międzyczasie na tym serwerze.

Wydaje się bardziej losowy po ponownym uruchomieniu, ale zauważyłem, że SSMS działa zaraz po instalacji, ale potem SCCM w mojej organizacji zaczyna instalować różne rzeczy i SSMS przestaje działać. Teraz podejrzanym jest „.NET Framework 3.5 Server Feature 2016”

Istnieje inne rozwiązanie tego problemu. Na Azure Feedback pozycja SQL Server Management Studio 18 GA (15.0.18118.0) niezgodna z .NET Framework 4.8 Erich Signer sugeruje:

Krok 1:

C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\CommonExtensions\Platform\Microsoft.VisualStudio.MinShell.Interop.pkgdef

Zmień nazwę i upewnij się, że ten plik nie ma .pkgdefjuż rozszerzenia. Lub usuń plik.

Krok 2:

Usuń następujący klucz rejestru (który jest tworzony podczas uruchamiania SSMS 18 przy użyciu wyżej wspomnianego pliku „.pkgdef”):

HKEY_CURRENT_USER\SOFTWARE\Microsoft\SQL Server Management Studio\18.0_IsoShell_Config\RuntimeConfiguration\dependentAssembly\bindingRedirection\{8BC7AF31-B6DA-4B97-8B36-F0500DECB147}

_{Na podstawie komentarza pierwotnie pozostawionego przez omzig}

Napotkałem ten sam problem i po chwili poszukiwania tego problemu znalazłem następujący artykuł krok po kroku dotyczący tego problemu:

• SSMS: Jak naprawić problem z otwieraniem programu SQL Server Management Studio

Dostarczone rozwiązanie to:

Skopiuj plik PrivateAssemblies \ Interop \ Microsoft.VisualStudio.Shell.Interop.8.0.dll (ten z wersją zestawu 15.0.0.0) do folderu PublicAssemblies.

Kroki były następujące:

• Po pierwsze, jako środek ostrożności autor zmienił nazwę istniejącego PublicAssemblies\Microsoft.VisualStudio.Shell.Interop.8.0.dllna coś innego, na wypadek, gdyby później potrzebowałem tego pliku.
• Następnie skopiował Microsoft.VisualStudio.Shell.Interop.8.0.dllplik PrivateAssemblies\Interopdo PublicAssembliesfolderu.

Po tej zmianie SSMS został załadowany bez żadnych problemów.