VSSDK in-proc accessing extensibility service through this.GetServiceAsync(typeof(VisualStudioExtensibility)) fails.

[mitchcapper]

Here is a modified version of the composite example to illustrate the issue. https://github.com/mitchcapper/VSExtensibility/tree/hybrid_project_fails. Most of it is just adding full VSSDK entrpoints here you can see the issue (commented out the crash one): https://github.com/mitchcapper/VSExtensibility/blob/hybrid_project_fails/New_Extensibility_Model/Samples/CompositeExtension/CompositeExtension/CompositExtensionPackage.cs#L29-L38

It is documented that one should be able to access the new apis from composite/hybrid extensions by getting the service. Unfortunately this fails do to assembly mismatch.

Calling await this.GetServiceAsync(typeof(VisualStudioExtensibility)); or this.GetServiceAsync<VisualStudioExtensibility,VisualStudioExtensibility>(); does not work as different assembly versions and cannot be converted. The first version does return it ie:
Global service fetch returned: Microsoft.VisualStudio.Extensibility.VisualStudioExtensibility, Microsoft.VisualStudio.Extensibility.Framework, Version=18.0.96.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a but we requested: Microsoft.VisualStudio.Extensibility.VisualStudioExtensibility, Microsoft.VisualStudio.Extensibility.Framework, Version=17.14.2088.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

The second typed one just throws an exception as it cant cast it to that type. This wouldn't be an issue but due to the Extensibility design I can't seem to easily trigger a normal entrypoint that would have it injected without waiting for a user to manually click a button (which doesn't work for my case). I maintain an extension: https://github.com/mitchcapper/JustMyCodeToggle/ for allowing you to control various options like JustMyCode or Symbol Loading from the command bar or shortcuts. VS2026 broke several methods that worked in VS2022 and the only way I have found to set debugging.symbols.load.moduleFilterMode now is through the new unified store. Except I can't figure out how to get access to the unified store due to this and one other issue:)

I could maybe use a compiled set of expressions to be able to work with the wrong typed version but that isn't probably the best solution.

[matteo-prosperi]

The ability to retrieve an instance of VisualStudioExtensibility through GetServiceAsync is not supported. In the near future, we plan to remove VisualStudioExtensibility completely from the list of services that you can retrieve with GetServiceAsync.
The VisualStudioExtensibility object should only be used by retrieving it through dependency injection (for example from a Command).
If you have an extension that has an AsyncPackage or a MEF component and want to interact with the VisualStudioExtensibility object to leverage the new VisualStudio.Extensibility features, you should add an Extension class and a brokered service (the CompositeExtension sample shows how to add a brokered service to an extension). You can then use dependency injection to retrieve the VisualStudioExtensibility object from the brokered service. And you can communicate with the borkered service from your AsyncPackage or MEF component. I plan on adding a sample soon showing how to do this.

[matteo-prosperi]

This is the sample for how to interact between the VSSDK and VisualStudio.Extensibility portions of an extension: https://github.com/microsoft/VSExtensibility/blob/68cb1c4bc8e4f6c51599e362c3f4d38a13c2853e/New_Extensibility_Model/Samples/AsyncPackageAndMEF/README.md

[mitchcapper]

@matteo-prosperi thanks for this example.

I was able to get this working with one caveat, I can't get ahold of the service until after a solution is loaded.

I did add an always true activation constraint to be safe:

public override ExtensionConfiguration ExtensionConfiguration => new()
{
    RequiresInProcessHosting = true,
    LoadedWhen = ActivationConstraint.Or( ActivationConstraint.SolutionState(SolutionState.Exists), ActivationConstraint.SolutionState(SolutionState.NoSolution))
};

However still in my VSDDK portion in my InitalizeAsync I kickoff this loop that waits for the Extensibility service to be available:

public async Task AttemptGetExtensibility()
{
    while (true)
    {
        await JoinableTaskFactory.SwitchToMainThreadAsync();
        var serviceBrokerContainer = await this.GetServiceAsync<SVsBrokeredServiceContainer, IBrokeredServiceContainer>();
        var serviceBroker = serviceBrokerContainer.GetFullAccessServiceBroker();

        var myBrokeredServiceProxy = await serviceBroker.GetProxyAsync<IExtensibilitySettingManager>(IExtensibilitySettingManager.Configuration.ServiceDescriptor, default);

        (myBrokeredServiceProxy as IDisposable)?.Dispose();
        if (myBrokeredServiceProxy != null)
        {
            Debug.WriteLine($"{DateTime.Now}: Got an instance");
            return;
        }else
        {
            Debug.WriteLine($"{DateTime.Now}: Still waiting...");
            await Task.Delay(2000);
        }
    }

}

It never does it will wait until the cows come home (ie have waited minutes). If I load a solution though it then is available shortly after.

[matteo-prosperi]

Is IExtensibilitySettingManager a service you created yourself? If yes, review the sample I linked above and possibly F5 debug it. It does exactly that, so the differences should point you towards the solution.
Also, you shouldn't use LoadedWhen at all. The extension will be loaded automatically when needed, for example when you retrieve a brokered service defined by it.

[mitchcapper]

@matteo-prosperi yes it is. Sorry your sample works but it doesn't autoload the VSDDK. Infact I don't know how to even get the VSDDK side of it to load except through the Extensibility buttons with your sample (to try and trigger this VSDDK before Extensibility issue).

If you change your sample:

diff --git a/New_Extensibility_Model/Samples/AsyncPackageAndMEF/VSSDK/MyPackage.cs b/New_Extensibility_Model/Samples/AsyncPackageAndMEF/VSSDK/MyPackage.cs
index 824260a..5dbf9a1 100644
--- a/New_Extensibility_Model/Samples/AsyncPackageAndMEF/VSSDK/MyPackage.cs
+++ b/New_Extensibility_Model/Samples/AsyncPackageAndMEF/VSSDK/MyPackage.cs
@@ -7,12 +7,15 @@ using System.Runtime.InteropServices;
 using System.Threading;
 using Microsoft;
 using Microsoft.ServiceHub.Framework;
+using Microsoft.VisualStudio;
 using Microsoft.VisualStudio.Shell;
 using Microsoft.VisualStudio.Shell.ServiceBroker;

 [PackageRegistration(UseManagedResourcesOnly = true, AllowsBackgroundLoading = true)]
 [Guid(MyPackage.PackageGuidString)]
 [ProvideService(typeof(MyService), IsAsyncQueryable = true)]
+[ProvideAutoLoad(VSConstants.UICONTEXT.SolutionExistsAndFullyLoaded_string, PackageAutoLoadFlags.BackgroundLoad)]
+[ProvideAutoLoad(VSConstants.UICONTEXT.NoSolution_string, PackageAutoLoadFlags.BackgroundLoad)]
 public sealed class MyPackage : AsyncPackage
 {
        public const string PackageGuidString = "ac1de0e2-bc69-4a63-bb7e-15f3274448c7";

myBrokeredServiceProxy will be null after the GetProxyAsync call.

[matteo-prosperi]

That's because, since the async package is started very early, VS hasn't discovered the brokered service yet.

You can add the following attribute to the async package to instruct VS that this same extension provides the brokered service.

[ProvideBrokeredServiceHubService(IMyBrokeredService.Configuration.ServiceName, Audience = ServiceAudience.Local | ServiceAudience.RemoteExclusiveClient)]
public sealed class MyPackage : AsyncPackage
{

I will update the sample to add the attribute as well.

But I would caution against creating async packages or extensions that are automatically loaded when VS starts since that will degrade the VS startup time.