microsoft/vs-ng-language-service

The extension does not activate

Closed this issue ยท 43 comments

Hi,

I have installed Angular Language Service 2022 v1.0 in Visual Studio 2022 17.3.0.

I have an Angular (v13) only project which I open as a Folder. As far as I can see, installing the extension had no effect.
I have no completions, diagnostic messages, etc. The output window does not contain "Angular Language Service Extension" in "Show output from" dropdown. I have tried to open and edit several .ts and .html files.

Is there anything I should do to start the extension?

@transmogrifix thanks for the report! To ease our investigation, are you able to share the project you're using?

@transmogrifix Also, you mention opening the project as a folder. Have you tried opening the project/solution instead?

@MariaSolOs Any Angular project will do. Here is a simple one https://github.com/transmogrifix/angular-app
There are no project/solution files to open (sln, csproj, etc).

@transmogrifix thanks for the repro! #42 should fix the issue :)

@MariaSolOs Thank you for a quick response, unfortunately v1.0.1 is behaving the same.
Is there any other information I can provide to help you?

@MariaSolOs Thank you for a quick response, unfortunately v1.0.1 is behaving the same.

Is there any other information I can provide to help you?

Hmmm that's strange, it is working for me. Are you still not seeing anything on the output pane?

I've been trying the extension with the Visual Studio 2022 "Angular" templates ("ASP.Net Core with Angular" / "Standalone Typescript Angular Project"), but was unable to observe any effect. (In particular, I can't get the additional output category to show up.)
I've also been unable to try to build the code locally in order to see, if this makes any difference on the behavior.
(Can't log into the nuget repository, and the "global" repository doesn't contain the packages required.)

Is there anything else (except opening an html- or ts-file in an angular project) that needs to be done for the output category to show up?

Is there any way to generate useful diagnostic output that might help you determine the cause of the difference in behavior between the systems?

Is there anything else (except opening an html- or ts-file in an angular project) that needs to be done for the output category to show up?

@Khyalis yes, the extension will only be activated (and hence you will see the pane in the output window) only after opening a TypeScript or a component.html file.

@MariaSolOs Thank you for a quick response, unfortunately v1.0.1 is behaving the same.
Is there any other information I can provide to help you?

Hmmm that's strange, it is working for me. Are you still not seeing anything on the output pane?

The output window still does not contain "Angular Language Service Extension" in "Show output from" dropdown.
I tried several projects including the one I shared. I even tried reinstalling the extension.

The extension is working for you when you open the project I shared using "Open a local folder"?

@Khyalis yes, the extension will only be activated (and hence you will see the pane in the output window) only after opening a TypeScript or a component.html file.

Yes, as far as I understand that is what I did. I tried with app.component.html/.ts in both templates, and also tried opening a component in a folder containing a workspace I created with the angular cli. Also cloned transmogrifix' project.

When I remove the code dependent on Microsoft.WebTools.Languages.Html.Editor and downgrade the PackageReference for Microsoft.VisualStudio.LanguageServer.Protocol to the latest publicly available version, and try to "debug" the extension, the output pane will appear upon opening a .component.html file, and Visual Studio will add "parser errors" to the error window when I break the template.

Edit: After replacing the PackageReference for Microsoft.WebTools.Languages.Html.Editor with references to the local VisualStudio installation, there is a little bit of code completion for .component.html, also. It does only seem to work for elements, but neither for attributes, attribute-values nor text-content (e.g. in interpolations).

The extension is working for you when you open the project I shared using "Open a local folder"?

@transmogrifix Yep. You can see from the solution explorer that I'm opening your repo using open folder:
Screenshot 2022-10-19 100802

@transmogrifix Yep. You can see from the solution explorer that I'm opening your repo using open folder: Screenshot 2022-10-19 100802

For me, the location also was [...]\Microsoft\VisualStudio\17.0_[...]**EXP**\[...], when I tried with the extension compiled locally. (Which also displayed the "Angular Language Service Extension" output pane.)

Could there be a difference between the version on the market place and the version you had been trying which might be worth looking into?

I tried using the Extension with Visual Studio 2022 17.4 Preview.

When complied locally, the extension could be activated.
When using the version from the Market Place, I received a toast message:

Task Failed - Activating language client Angular Language Service Extension: The JSON-RPC connection with the remote party was lost before the request could complete.

For some reason, there does not seem to be a "node_modules" folder in the installation location for the extension installed from the Market Place, while when running a local build, there is.

Maybe this could cause the node process trying to host the angular language service to terminate prematurely?

For some reason, there does not seem to be a "node_modules" folder in the installation location for the extension installed from the Market Place, while when running a local build, there is.

Maybe this could cause the node process trying to host the angular language service to terminate prematurely?

Thanks for the investigation @Khyalis. That seems to be the issue indeed. I'll work on a fix for this soon.

@Khyalis @transmogrifix Please feel free to reopen if the issue persists!

@MariaSolOs Still nothing, I have tried v1.0.2 on two different computers this time just to be sure.

@MariaSolOs Still nothing, I have tried v1.0.2 on two different computers this time just to be sure.

Unfortunately, I only checked whether the extension would initialize. And it did seem to do so with a project based on the "Standalone Typescript Angular Project" template. (Using 17.4 Preview, because I am too lazy to roll back to 17.3.)

But looking into your repo and also looking at my local projects again, it seems like the service would only activate when opening a ".ts"-file, but not when opening a ".component.html" (Which quite frankly I might not have thought about verifying).

Does this agree with your observations, or is there no activation at all in your case?

With a local build / in the debugger, activation also occurs for the ".component.html" file type.

I'm unsure as to what might be the reason behind this difference in behavior.

Interestingly, even if I replace the contents of the live extension folder with the local build results, the behavior does not change: Activation still only occurs for ".ts" files, not for ".component.html".

Edit: Conversely, if I copy the live version to the extension folder for "/rootsuffix Exp", it will activate for ".component.html".

But i cannot rule out some sort of internal caching explaining this kind of behavior.

@Khyalis @transmogrifix Please feel free to reopen if the issue persists!

I don't seem to be capable of reopening the issue.

I don't seem to be capable of reopening the issue.

@Khyalis I just reopened the issue.

But looking into your repo and also looking at my local projects again, it seems like the service would only activate when opening a ".ts"-file, but not when opening a ".component.html"

The LSP client is exported with both .ts and .component.html files, so the extension should activate when opening any of those.

I don't seem to be capable of reopening the issue.

@Khyalis I just reopened the issue.

But looking into your repo and also looking at my local projects again, it seems like the service would only activate when opening a ".ts"-file, but not when opening a ".component.html"

The LSP client is exported with both .ts and .component.html files, so the extension should activate when opening any of those.

I agree.
And while this appears to work just fine inside the Visual Studio Experimental instance, with the "normal" instance and installation via the Market Place, the behavior seems to be different.
Unfortunately, this eludes my understanding, leaving me of no use here.

I agree. And while this appears to work just fine inside the Visual Studio Experimental instance, with the "normal" instance and installation via the Market Place, the behavior seems to be different. Unfortunately, this eludes my understanding, leaving me of no use here.

I'm clueless at this difference in behavior. I'll continue investigating, please bear with me โค๏ธ @Khyalis

I now found an explanation for the difference in behavior:

For the "normal" instance, the "Preview Features" by the name of "HTML LSP-based editor" was enabled, for the "experimental" Instance, it was not.

After enabling it in the experimental instance, and disabling it in the normal instance, the behavior is reversed.

Maybe @transmogrifix can confirm, whether the behavior in their case is also related to this feature, or if the behavior there is entirely different.

Meanwhile I will have to revert to 17.3 to figure out if this is just an issue with 17.4 preview.

For the "normal" instance, the "Preview Features" by the name of "HTML LSP-based editor" was enabled, for the "experimental" Instance, it was not.

OHHH that explains a lot. I can tell you what the difference is: When the HTML LSP editor is enabled, HTML documents have a different content type, and so the .component.html type definition that we define here doesn't have the right base definition.

I don't want to just add the other base definition because at some point the HTML LSP editor will be always enabled and in that moment we'll have to make other changes to this extension.

So for the time being, for the time being, users of 17.4 (Preview) need to be aware they decide whether to use the extension, or the preview feature.

Meanwhile I finished rolling back to 17.3.6.

But with it, the extension does not activate for either .ts- or .component.html-files. (And I made sure the Preview Feature "HTML and CSS LSP editors" is disabled there.)

Edit:
With 17.3.6, it does "work" with a locally compiled version in the experimental instance (with all the differences in references), while it does not using the market place version in either case. I made sure both instances were configured with identical preview features.

I have VS 17.3.0 installed, the extension from market place does not activate for either .ts or .component.html files. I haven't tried building it locally.

I'm so sorry.
Today, the activation did work.
Unfortunately, I had performed a Windows update and installed some Visual Studio Features, so I was unable to tell what may have caused it.
I tried to uninstall the Features, but it still worked.

So now I have uninstalled Visual Studio, rebooted, and reinstalled it again, and currently, the extensions is back to not working.

I will next try to reboot the system without any additional change, to see what happens.

Edit:
This is speculation.
I believe it working until I deinstalled VS may have had to do with my previous attempts of overwriting the installation folder with the local build results.
I did not succeed in getting it to work no matter what Workloads/Components I installed.

I have VS 17.3.0 installed, the extension from market place does not activate for either .ts or .component.html files. I haven't tried building it locally.

You're not supposed to build the extension locally, so please don't use that as a workaround.

Oh. I may have misinterpreted the "Local Build" section on the Extensions Market Place page as being targeted towards me.
In case any questions come up, I will be around.

Oh. I may have misinterpreted the "Local Build" section on the Extensions Market Place page as being targeted towards me.

In case any questions come up, I will be around.

Those instructions are for contributors (like you) that want to build the extension locally. You're absolutely welcome to do that! What I meant is that people shouldn't need to build the extension this way in order to use it, just downloading it from the market place should be enough :)

@Khyalis I think I know what's wrong. Could you please check if you have any errors in AppData\Local\Microsoft\VisualStudio\XXXX\ComponentModelCache\Microsoft.VisualStudio.Default.err?

Yes, I also get the Could not load file or assembly 'Microsoft.VisualStudio.Threading, Version=17.4.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

Fantastic, thanks @transmogrifix @Khyalis for confirming! I'll fix the issue first thing tomorrow. Thanks for sticking with me!

@transmogrifix @Khyalis As promised, I just published a new release of the 2022 version of the extension that should hopefully fix this issue.

Please keep me updated! I won't close this for now until I hear back from you.

Hi, I just installed the version 1.0.3 of the Angular Language Service extension and it's not working. This is the error I have:

----- Catalog construction errors -----
Error n1
Microsoft.VisualStudio.Composition.PartDiscoveryException: Unable to load assembly "C:\Users\xxx\AppData\Local\Microsoft\VisualStudio\17.0_963c871d\Extensions\4xycgkus.l2o\AngularLanguageService.2022.dll" for scanning. ---> System.IO.FileLoadException: Could not load file or assembly 'AngularLanguageService.2022, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A)
--- End of inner exception stack trace ---
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.Assembly.Load(AssemblyName assemblyRef)
at Microsoft.VisualStudio.ExtensibilityHosting.FaultCatchingAssemblyLoader.b__17_0(AssemblyName assemblyNameParam)
at Microsoft.VisualStudio.ExtensibilityHosting.Utilities.SafeGetOrAdd[TKey,TValue](IDictionary2 dictionary, TKey key, Object lockObj, Func2 valueFactory)
at Microsoft.VisualStudio.ExtensibilityHosting.FaultCatchingAssemblyLoader.LoadAssembly(AssemblyName assemblyName)
at Microsoft.VisualStudio.Composition.PartDiscovery.<>c__DisplayClass12_0.b__0(String path)
--- End of inner exception stack trace ---
----- CompositionError level 1 ------
Microsoft.CodeAnalysis.ExternalAccess.FSharp.Internal.GoToDefinition.FSharpFindDefinitionService.ctor(service): expected exactly 1 export matching constraints:
Contract name: Microsoft.CodeAnalysis.ExternalAccess.FSharp.GoToDefinition.IFSharpFindDefinitionService
TypeIdentityName: Microsoft.CodeAnalysis.ExternalAccess.FSharp.GoToDefinition.IFSharpFindDefinitionService
but found 0.
part definition Microsoft.CodeAnalysis.ExternalAccess.FSharp.Internal.GoToDefinition.FSharpFindDefinitionService

Microsoft.NodejsTools.TestAdapter.TestMethodResolver.ctor(discoverer): expected exactly 1 export matching constraints:
Contract name: Microsoft.NodejsTools.TestAdapter.TestContainerDiscoverer
TypeIdentityName: Microsoft.NodejsTools.TestAdapter.TestContainerDiscoverer
but found 0.
part definition Microsoft.NodejsTools.TestAdapter.TestMethodResolver

Microsoft.CodeAnalysis.Editor.TypeScript.ScriptContexts.DefaultTypeScriptWorkspace.ctor(typeScriptWorkspaceCore): expected exactly 1 export matching constraints:
Contract name: Microsoft.CodeAnalysis.Editor.TypeScript.ScriptContexts.ITypeScriptWorkspaceCore
TypeIdentityName: Microsoft.CodeAnalysis.Editor.TypeScript.ScriptContexts.ITypeScriptWorkspaceCore
but found 0.
part definition Microsoft.CodeAnalysis.Editor.TypeScript.ScriptContexts.DefaultTypeScriptWorkspace

Microsoft.VisualStudio.DesignTools.Xaml.LanguageService.ResourceResolver.XamlResourceService.ctor(projectMetadataService): expected exactly 1 export matching constraints:
Contract name: Microsoft.VisualStudio.DesignTools.Xaml.LanguageService.Metadata.IProjectMetadataService
TypeIdentityName: Microsoft.VisualStudio.DesignTools.Xaml.LanguageService.Metadata.IProjectMetadataService
but found 0.
part definition Microsoft.VisualStudio.DesignTools.Xaml.LanguageService.ResourceResolver.XamlResourceService

Microsoft.VisualStudio.DesignTools.Xaml.LanguageService.ResourceResolver.XamlResourceService.ctor(projectService): expected exactly 1 export matching constraints:
Contract name: Microsoft.VisualStudio.DesignTools.DesignerContract.IHostProjectService
TypeIdentityName: Microsoft.VisualStudio.DesignTools.DesignerContract.IHostProjectService
but found 0.
part definition Microsoft.VisualStudio.DesignTools.Xaml.LanguageService.ResourceResolver.XamlResourceService

Microsoft.VisualStudio.DesignTools.Xaml.LanguageService.ResourceResolver.XamlResourceService.ctor(textBufferProvider): expected exactly 1 export matching constraints:
Contract name: Microsoft.VisualStudio.DesignTools.DesignerContract.IHostTextBufferProvider
TypeIdentityName: Microsoft.VisualStudio.DesignTools.DesignerContract.IHostTextBufferProvider
but found 0.
part definition Microsoft.VisualStudio.DesignTools.Xaml.LanguageService.ResourceResolver.XamlResourceService

Microsoft.CodeAnalysis.ExternalAccess.Pythia.PythiaSignatureHelpProvider.ctor(implementation): expected exactly 1 export matching constraints:
Contract name: Microsoft.CodeAnalysis.ExternalAccess.Pythia.Api.IPythiaSignatureHelpProviderImplementation
TypeIdentityName: Microsoft.CodeAnalysis.ExternalAccess.Pythia.Api.IPythiaSignatureHelpProviderImplementation
but found 0.
part definition Microsoft.CodeAnalysis.ExternalAccess.Pythia.PythiaSignatureHelpProvider

Microsoft.CodeAnalysis.Editor.TypeScript.LSP.LSPCommandSupportProvider.ctor(serviceBroker): expected exactly 1 export matching constraints:
Contract name: SVsFullAccessServiceBroker
TypeIdentityName: Microsoft.ServiceHub.Framework.IServiceBroker
but found 0.
part definition Microsoft.CodeAnalysis.Editor.TypeScript.LSP.LSPCommandSupportProvider

Please let me know if you need any additional info. Thanks.

@transmogrifix @Khyalis As promised, I just published a new release of the 2022 version of the extension that should hopefully fix this issue.

Please keep me updated! I won't close this for now until I hear back from you.

@MariaSolOs The extension activates successfully now (for me at least)!

Now that it is active, the only difference I see is when I open a .component.html and make a typo it gets underlined:
image
But there are no completions, or anything else. Should I report this in a new issue?

Thank you!

@MariaSolOs I'm just trying to not get in the way too much while you're doing all the work.
Using 17.3.6, after updating the extension, it activates for both .component.html files and .ts files for both the project @transmogrifix provided as well as the templates that came with Visual Studio. Thanks a lot.

@transmogrifix When entering an opening "<", for me it also includes existing components (eg. 'app-root') in the suggestion (Except sometimes when trying it the first time after loading).
I think completion for attributes / attribute values / interpolation expressions and inline-templates would be very nice, but currently, support appears to be limited to "children" in the html text.
Is this a regression or more of a feature request?

@transmogrifix When entering an opening "<", for me it also includes existing components (eg. 'app-root') in the suggestion (Except sometimes when trying it the first time after loading). I think completion for attributes / attribute values / interpolation expressions and inline-templates would be very nice, but currently, support appears to be limited to "children" in the html text. Is this a regression or more of a feature request?

I am not sure if this a regression, the old VS2019 extension was far too unstable for me when I tried it several months (or maybe a year) ago, so I don't remember what exactly worked and what didn't.

@amoroso81 could you please open a separate issue? This seems to be a different problem. Please include your Visual Studio version :)

@transmogrifix @Khyalis thanks both for confirming and your patience <3!
Because the original problem linked to this issue seems solved now, I'll close this.

As for things not working properly inside {{ }}, that's sadly to be expected (see #20). Now that you can start the extension, I'll work on this next, but it might need to wait for the HTML LSP editor to be enabled by default (currently is a preview only feature).