Initialising MSBuild project tools...

[gnimor]

I am using the extension for my build projects, now I am getting a circle icon stating that "Initialising MSBuild project tools..."

And this stays forever. Is this the expected behavior?

[tintoy]

No, it definitely shouldn't do that - if you go to the output window and choose MSBuild Project Tools from the drop-down are there any errors in the log?

[gnimor]

Hmm, there is no "MSBuild Project Tools" from the drop-down.

[tintoy]

Hmm, in that case it sounds like the language server doesn't even launch successfully. Can you try opening a command prompt and running dotnet --info, then post the output?

[joergjo]

Same problem here.

.NET Core SDK (gemäß "global.json"):
 Version:   2.1.403
 Commit:    04e15494b6

Laufzeitumgebung:
 OS Name:     Windows
 OS Version:  10.0.17763
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.403\

Host (useful for support):
  Version: 2.1.5
  Commit:  290303f510

<List of SDKs redacted>

[tintoy]

Hmm, ok, let's try a couple of things to troubleshoot:

1. Can you run dotnet <extension-dir>\out\language-server\MSBuildProjectTools.LanguageServer.Host.dll and see if anything is printed to the console?
2. Enable logging to file (if you have the latest version of the extension, the setting is msbuildProjectTools.logging.file), verbose logging (setting is called msbuildProjectTools.logging.level), and try restarting VS Code. Is anything written to the log file?

[tintoy]

3. Try step one again, but first set environment variable MSBUILD_PROJECT_TOOLS_LOG_FILE to the full path of the log file to write and also set MSBUILD_PROJECT_TOOLS_VERBOSE_LOGGING to 1. See if the log file is written to.

[tintoy]

And can you confirm what version of the extension you have installed? Should be v0.2.42 (latest version).

[tintoy]

Looking at your output, I think there may be a problem due to dotnet --info returning non-english section titles on your system; because Microsoft won't support a machine-readable output format (such as JSON), I have to resort to manually parsing the output of dotnet --info as text in order to find the SDK directory (etc).

This wouldn't explain why the language server process won't launch at all though.

[tintoy]

One more setting to enable:

• Set msbuildProjectTools.logging.trace to true.

[tintoy]

Ugh, looks like there was a bug with parsing of extension settings so the settings specified above will have no effect. I'm about to publish v0.2.44 which fixes that bug (at which point we can start troubleshooting).

[joergjo]

Just launched VS Code and it updated to v0.2.44. The extension works again, thanks!

[tintoy]

Odd, but good to hear :)

[tintoy]

Probably related to #43 (should be fixed in v0.2.45, which was published a couple of minutes ago).

[joergjo]

Uh uh, v0.2.45 on Code 1.29 is broken again on a localized version of Win10. Do you need the same telemetry mentioned as earlier in this thread?

[tintoy]

Do you need the same telemetry mentioned as earlier in this thread?

Yes, please!

[tintoy]

I've added the dotnet --info output you supplied as input to one of the new unit tests and it passes; could the problem be something else perhaps?

Can I just confirm the behaviour you're seeing? Is it that it gets stuck on "Initialising MSBuild Project Tools..."?

If so, then yeah I'll need you to enable logging to file so we can work out what's going on...

[ltrzesniewski]

In my case, the dotnet --info process doesn't seem to quit:

The extension is in the "Loading project..." state indefinitely.

(v0.2.46)

[tintoy]

Is that when you run it from the command-line?

[ltrzesniewski]

No, that's VS Code running it. When I run it from the command line, it exits just fine.
Also, my system language is English, so this may actually be unrelated to the localization issue.

[tintoy]

Ok, can you try enabling the logging (etc) mentioned above and post the resulting log file (if any)?

[joergjo]

OK, now running at v0.2.46, VS Code 1.29.1, and .NET Core SDK 2.1.500, but it's still stuck at "Initialising…".

dotnet .\tintoy.msbuild-project-tools-0.2.46\out\language-server\MSBuildProjectTools.LanguageServer.Host.dll doesn't create any output

I also don't see any log file being written. Should msbuildProjectTools.logging.file point to a directory or a file?

[tintoy]

It should point to a file (the file does not have to exist before running).

[tintoy]

BTW, I'm publishing a new version of the extension (v0.2.47) which has more logging during language server startup which may help when troubleshooting.

@joergjo when you try it out, can you also make sure that msbuildProjectTools.logging.level is set to Verbose?

[joergjo]

OK, so after updating to v0.2.47 the extension works again. Was that expected?

[tintoy]

Nope, only changes were some extra logging statements during start-up :)

Perhaps it's something environmental?

[tintoy]

Ok, I'm at work so I can't look further into this until later this evening but I'll try again tonight and see if I can do anything to improve the extension-side logging / error reporting.

Can I just confirm - are you on Windows, Linux, or Mac?

[ltrzesniewski]

I'm on Windows.

BTW here's my dotnet --info output in case it helps (I have a couple preview SDKs, maybe it plays a role):

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview-009744
 Commit:    f1b5e95981

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.0.100-preview-009744\

Host (useful for support):
  Version: 3.0.0-preview-27109-05
  Commit:  2eee399494

.NET Core SDKs installed:
  1.0.0 [C:\Program Files\dotnet\sdk]
  1.0.4 [C:\Program Files\dotnet\sdk]
  1.1.0 [C:\Program Files\dotnet\sdk]
  2.1.2 [C:\Program Files\dotnet\sdk]
  2.1.103 [C:\Program Files\dotnet\sdk]
  2.1.104 [C:\Program Files\dotnet\sdk]
  2.1.201 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.300-preview2-008533 [C:\Program Files\dotnet\sdk]
  2.1.302 [C:\Program Files\dotnet\sdk]
  2.1.400 [C:\Program Files\dotnet\sdk]
  2.1.401 [C:\Program Files\dotnet\sdk]
  2.1.402 [C:\Program Files\dotnet\sdk]
  2.1.403 [C:\Program Files\dotnet\sdk]
  2.1.500 [C:\Program Files\dotnet\sdk]
  2.2.100-preview3-009430 [C:\Program Files\dotnet\sdk]
  3.0.100-preview-009744 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0-preview2-final [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.0-preview3-35497 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 3.0.0-alpha1-10663 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0-preview2-final [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.0-preview3-35497 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-alpha1-10663 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.DesktopUI.App 3.0.0-alpha-27106-4 [C:\Program Files\dotnet\shared\Microsoft.DesktopUI.App]
  Microsoft.NETCore.App 1.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0-preview2-26406-04 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.3-servicing-26724-03 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.0-preview3-27014-02 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview-27109-05 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

[tintoy]

Thanks! I'll take a look as soon as I can :)

[tintoy]

Just as a quick experiment, if you temporarily move the directory C:\Program Files\dotnet\sdk\3.0.100-preview-009744 outside the C:\Program Files\dotnet\sdk directory, do you still see this problem while initialising? I'm just trying to work out whether it's trying to use a newer version of the .NET Core SDK that it doesn't understand...

If not, I'll try installing the latest 3.x preview SDK when I get home and give it a try myself.

[tintoy]

I have found and fixed an issue where dotnet --info hangs because its STDOUT buffer fills up (because the command now produces longer output than before).

But it has exposed a separate issue; if you have a .NET Core v3.x preview SDK installed, you won't be able to load projects unless you have a global.json that locks your SDK to v2.x in the same directory as your solution file (the structure of the SDK directory has changed, and MSBuild project tools can't automatically determine where the correct .props and .targets files live when they are included by loaded projects).

You may be able to work around the issue (once I've released a new build of the extension) by setting the MSBuildSDKsPath environment variable to something like C:\Program Files\dotnet\sdk\2.1.401.

[tintoy]

Published v0.2.49 - can you give it a try and see how far you get?

[ltrzesniewski]

Thanks! This works fine on my work computer (where I don't have the v3 SDK installed). The previous version didn't work.
I'll tell you how it goes on my home computer tonight.

[joergjo]

Good news, it works for me as well and I also found why logging didn't before.

It seems that at some point I've accidentally created an invalid user setting section for msbuildProjectTools.* which silently broke the extension--the log settings I had created ath the workspace level were simply ignored. After removing the invalid section, everything started working again, and a logfile was written.

[ltrzesniewski]

I tested it a bit on my home PC with the v3 SDK. Evaluation works fine, but completion inside Condition attributes doesn't seem to produce useful results. As I haven't really used this extension until now I can't tell if it's normal or not. I'll use it at work a bit so I will be able to tell if it's an issue or if I was just expecting too much.
Thanks for the fix! 😄

[tintoy]

No problem glad it's working now :)

Do other completions work for you, or none at all? Support for expression completions should work so if it's not, feel free to open a new issue. If possible, post the project file you're working with and where you're expecting a completion (line and column).

[tintoy]

Just remembered - if you want intellisense for expressions make sure the editor language is "MSBuild", not "XML".

[tintoy]

Closing this issue for now, since it seems to be resolved. Feel free to reopen if the problem occurs again :)

[ltrzesniewski]

facepalm

Yeah, the file mode was XML actually, but I didn't pay attention since I still got the tooltips from the extension. I didn't expect this extension to be active in XML mode at all.

So yeah, completion works fine now, thanks! 😉

[randre70]

Good news, it works for me as well and I also found why logging didn't before.

It seems that at some point I've accidentally created an invalid user setting section for msbuildProjectTools.* which silently broke the extension--the log settings I had created ath the workspace level were simply ignored. After removing the invalid section, everything started working again, and a logfile was written.

Still applies today (v0.2.54), check your settings for an invalid section.

[dmitry64]

I'm running Linux, and I have the same issue after upgrading my dotnet core to 3.0. I tried

MSBuildSDKsPath=/usr/share/dotnet/sdk/3.0.100 code

But that did not help. Is there any other way to fix that or should I just wait for the update?

[tintoy]

I’m still having trouble making this happen on demand for some reason - can you tell which distro and version of Linux you are running? And can you post the output of dotnet —info?

I’m going to see if I can get you to capture a dump of the hung process (but I’m not sure how to do this for Linux yet).

[dmitry64]

Here is my dotnet --info

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100
 Commit:    04339c3a26

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  19.04
 OS Platform: Linux
 RID:         ubuntu.19.04-x64
 Base Path:   /usr/share/dotnet/sdk/3.0.100/

Host (useful for support):
  Version: 3.0.0
  Commit:  95a0a61858

.NET Core SDKs installed:
  3.0.100 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

[tintoy]

Note to self: give dotnet-dump a try (via WSL).

[dmitry64]

You can try installing Ubuntu in virtual machine and installing dotnet core 3.0 + vscode there.

[tintoy]

Will do, just need to free up some space on my laptop’s SSD :)

[tintoy]

Ok - finally got to try this out (sorry for the delay).

I think the problem may be that you have only the 3.0 runtime installed (which comes with the 3.0 SDK), not the 2.0 runtime (the language server targets netcoreapp2.0 which isn't directly supported by the 3.0 SDK). If you install the 2.0 runtime package, does it start working for you?

https://dotnet.microsoft.com/download/linux-package-manager/ubuntu16-04/runtime-2.0.9

[dmitry64]

Yeah, the issue seems to be fixed 👍 Although keeping 2 different versions is not the best solution.

[tintoy]

Yeah I’ll have to upgrade to .NET Core 3 - hopefully over the weekend :)

[mateusdeap]

Hi there, I've been having the same issue on Ubuntu 19.04. I ran /home/mateus/Projects/Dotnet/hwapp/hwapp.csproj and had this output:

A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/home/mateus/.vscode/extensions/tintoy.msbuild-project-tools-0.2.55/out/language-server/'.
Failed to run as a self-contained app. If this should be a framework-dependent app, add the /home/mateus/.vscode/extensions/tintoy.msbuild-project-tools-0.2.55/out/language-server/MSBuildProjectTools.LanguageServer.Common.runtimeconfig.json file specifying the appropriate framework.

Do you believe the 2.0 runtime might have this missing library as well?

[divinebovine]

Maybe this issue could be opened back up? I was about to create a new one and just so happened to check the closed issues.

[tintoy]

Hi - there is an issue tracking the upgrade to 3.0 in the language server repository (tintoy/msbuild-project-tools-server#17). I’m hoping to get this done sometime tomorrow :)