How can we help you today? How can we help you today?
mike.hodgson

Activity overview

Latest activity by mike.hodgson

Ran into the same issue myself.  This is Claude's analysis of the issue from the exception log file I fed it: What's actually failing The DI container (Ninject) is trying to wire up ShowIndexAnalysisAiCommand — which is SQL Prompt's AI-powered index analysis feature — and the injection chain is:     ShowIndexAnalysisAiCommand → IndexAnalysisCommandController → QtpIndexesController → IndexAnalysisResultViewModelFactory → IndexAnalyzer → QtpApiFetcher → IHttpClientFactory ← MISSING BINDING IHttpClientFactory is a standard .NET Core type (from Microsoft.Extensions.Http ) used to create HttpClient instances. Ninject can't find a binding for it, meaning whoever was responsible for registering it in the DI kernel didn't do so — most likely because SSMS 22.4.1 changed something about how it exposes or provides that factory, and SQL Prompt's bootstrapping code is now looking in the wrong place or expecting it to already be registered by the host. Key observations from the log SQL Prompt version is 11.3.7 — so it's the current release, not an old one left behind SSMS version detected is 22.4.11612.150 — the fresh update Your locale is en-AU / en-US — irrelevant but good to know it logged it The error fires during InitializeAsync → InitializeCommands — i.e., at startup, before SQL Prompt is even usable Importantly, the licence check at the bottom succeeds — so SQL Prompt partially loads, it just can't build its command menu What this means practically The feature that's broken is the newer AI/index analysis functionality (QtpApiFetcher suggests it's calling out to a Redgate API endpoint). It's possible that: SSMS 22.4.1 changed how IHttpClientFactory is registered in its own DI container, and SQL Prompt was piggybacking on that registration Or Redgate introduced this AI feature in 11.3.7 and didn't properly register IHttpClientFactory in their Ninject kernel for the SSMS 22 entry point specifically Either way, this is squarely a Redgate bug to fix — there's nothing you can do on your end to resolve it short of waiting for 11.3.8. What to report to Redgate When you log the support ticket/forum post, the salient details are: SQL Prompt 11.3.7 + SSMS 22.4.11612.150 Ninject.ActivationException on IHttpClientFactory during InitializeCommands The failing feature is ShowIndexAnalysisAiCommand / QtpApiFetcher / comments
Ran into the same issue myself.  This is Claude's analysis of the issue from the exception log file I fed it:What's actually failingThe DI container (Ninject) is trying to wire up ShowIndexAnalysis...
8 votes
For those of you who didn't get Redgate's email about 5 hours ago… --- We’re writing to inform you about a compatibility issue affecting several products within our Productivity solution area when used with the latest version of SSMS. What happened Microsoft updated some of the underlying libraries as part of the SSMS 22.3.2 release, which changed how extensions are loaded during startup. This created compatibility issues for a range of extension vendors, including several of Redgate’s Productivity tools. We’ve been working closely to address this as quickly as possible. What’s happening next We are releasing fixes in two stages: Interim fix – already available for SQL Prompt We released an interim compatibility fix for SQL Prompt last Friday. Customers who update SQL Prompt and are using the latest version of SSMS can continue working without disruption. Please note:  Interim fixes for other affected Productivity tools are coming on Wednesday. These updates will ensure compatibility with the latest SSMS release, although they will not support some earlier SSMS versions. This allows customers who have already updated SSMS to remain productive while we complete broader fixes. 2. Full compatibility update – coming shortly after We are preparing a broader fix that restores compatibility across multiple supported SSMS versions. We will communicate as soon as this is available. Where to find the latest updates For the most current information, downloads, and release notes, please visit our documentation pages. We understand how disruptive tooling issues can be and appreciate your patience while we work through this carefully. Our priority is to restore stable, predictable compatibility across supported environments. If you have urgent concerns or need guidance on version alignment, our support team is ready to help. Best regards,  The Redgate Team / comments
For those of you who didn't get Redgate's email about 5 hours ago…---We’re writing to inform you about a compatibility issue affecting several products within our Productivity solution area when us...
1 vote
I have the same issue as everyone else.  While troubleshooting I came across this thread that reiterates that Microsoft updated the Microsoft.Data.SqlClient library that SSMS v22.3.0 now uses: https://www.sqlservercentral.com/forums/topic/ssms-22-latest-update-crashing I also sent some troubleshooting info to Claude (Anthropic) and it came back with:   -------------- The Real Problem: SSMS v22.3.0 upgraded its internal Microsoft.Data.SqlClient assemblies to a newer version. Your Redgate SQL Toolbelt extension was compiled against the old assembly versions, so when Object Explorer loads (which triggers extension initialization), the extension can't find the assemblies it expects → crash. The "ClientRights" error is likely a red herring - it's just the last thing in the call stack before the assembly binding failure causes everything to unwind. Solutions (in order of preference): 1. Wait for Redgate to release a compatible update Check Redgate's website/support for a v22.3-compatible SQL Toolbelt update You mentioned you already updated Thursday, but there may be a newer hotfix by now 2. Disable the Redgate extension temporarily: Tools → Extensions and Updates (or Manage Extensions) Disable SQL Toolbelt/SQL Search extensions Restart SSMS You'll lose the Redgate functionality but SSMS will work 3. Rollback to SSMS v21.x or v22.2: Uninstall SSMS 22.3.0 Install previous version from Microsoft's download archive This is the fastest way to get back to full functionality with Redgate --------- I'm going to just use SSMS v20.2 (which I still have on my SQL jump box) until Redgate recompile/release an update for SQL Toolbelt that is compatible with the newer version of Microsoft.Data.SqlClient.  I'm sure Redgate are already working on that. / comments
I have the same issue as everyone else.  While troubleshooting I came across this thread that reiterates that Microsoft updated the Microsoft.Data.SqlClient library that SSMS v22.3.0 now uses:https...
0 votes