tintoy / msbuild-project-tools-vscode Goto Github PK

VS Code extension for MSBuild intellisense (including PackageReference completion).

License: MIT License

TypeScript 92.26% PowerShell 4.98% JavaScript 2.75%

language-service msbuild vscode highlighting dotnet-core

msbuild-project-tools-vscode's Introduction

MSBuild project file tools

An extension for VS Code that provides intellisense for MSBuild project files, including auto-complete for <PackageReference> elements.

The language service used by this extension can be found here: tintoy/msbuild-project-tools-server

Usage

Completions for PackageReference and DotNetCliToolReference.
- Completions for Include and Version attributes of these items (invoke the NuGet: toggle pre-release command to include / exclude pre-release packages / package versions).
- Completions to create these elements.
Completions for common top-level elements (e.g. PropertyGroup, ItemGroup, Target).
Completions for import elements.
Completions for property elements.
Completions for item elements.
Completions for common item attributes.
Completions for common property Condition attributes.
Hover the mouse over imports, targets, items, properties, and conditions to see information about them.
Document symbols are supported for imports, targets, items, and properties.
Go-to-definition is implemented for both SDK-style and regular project imports.
Basic syntax highlighting of MSBuild expressions in attribute values.
To see this highlighting, change the editor language from XML to MSBuild.
Completions for $() property, @() item, and %() item metadata expressions.
To enable these completions, ensure that the editor language is MSBuild (not XML).
Completions for task elements and attributes based on metadata for tasks declared in the project and its imported projects.
To enable these completions, add the string Tasks to the msbuildProjectTools.language.completionsFromProject setting.
Useful snippets for common elements of MSBuild project XML (added by @doggy8088).
To use these snippets, ensure that the editor language is MSBuild (not XML).

File extensions

By default, the language service is automatically available for files with the following extensions:

*.*proj
.targets
.props
.tasks

If you want to use it with additional file types:

Open the desired file.
Change the language mode by pressing Ctrl-Shift-P (or Cmd-Shift-P on Mac) and choosing "Change Language Mode".
Choose "configure file association".
Choose language MSBuild.

Installation

You can install this extension from the VS marketplace, Open VSX or simply download the VSIX package for the latest release and install it by choosing "Install from VSIX" from the menu on the top right of the extensions panel.

Building from source

See BUILDING.md.

Design

See architectural overview for details (this is a work-in-progress; if you have questions, feel free to create an issue).

Limitations

The VS Code extension API has changed somewhat since this extension was first created, and some features (such as hyperlinks to files in hover tooltips) are only partially functional at present (broken by VS Code API / behaviour changes).
This is still being worked on :-)
Limited intellisense is available for dynamic PropertyGroup / ItemGroup declarations (i.e. those appearing inside a Target element); these are only evaluated when the project is built and so very little information about them is available to us when statically evaluating the project (see tintoy/msbuild-project-tools-server#5 for details).
Support for task completions is experimental; if you find a problem with it, please create an issue.
If you open more than one project at a time (or navigate to imported projects), subsequent projects will be loaded into the same MSBuild project collection as the first project. Once you have closed the last project file, the next project file you open will become the master project. The master project will become selectable in a later release.

Questions / bug reports

If you have questions, feedback, feature requests, or would like to report a bug, please feel free to reach out by creating an issue. When reporting a bug, please try to include as much information as possible about what you were doing at the time, what you expected to happen, and what actually happened.

If you're interested in collaborating that'd be great, too :-)

msbuild-project-tools-vscode's People

Contributors

Stargazers

Watchers

Forkers

doggy8088 brembow34 productinfo david-driscoll grizzlygrent beatles-hub h-helemons-timmerwerken thurston81 syfimeal dpow40 lsp-implementaions rudyschockaert balbrich 0xninshu

msbuild-project-tools-vscode's Issues

Implement and use an MSBuild language server

Use types from the Microsoft.Build.Construction / Microsoft.Build.Evaluation namespaces to gain a better understanding of the project structure and configuration (e.g. determine active target framework monikers to filter package results).

This would open up a bunch of useful functionality:

Completions for property and item-group names
Go-to-definition / symbol / link providers
Hover / CodeLens providers for evaluating expression values
Improved (i.e. "whole-file") handling of project XML (since stuff in the Construction namespace knows about element locations).

Work is happening in the feature/language-server branch.

We're using the language server protocol implementation from the OmniSharp folks.

Adding a config setting that enables the user to specify / override additional MSBuild toolsets

Example config:

{
    "msbuildProjectTools.msbuild.toolsets": {
        "15.0": {
            "baseDirectory": "C:\\MyToolsetBaseDirectory",
            "globalPropertyOverrides": {
                "MyProperty": "SomeValue"
            }
        },
        "Current": {
            "baseDirectory": "C:\\AnotherToolsetBaseDirectory"
        }
}

MSBuild appends the toolset version to the base directory (e.g. 15.0 -> C:\MyToolsetBaseDirectory\15.0 or Current -> C:\AnotherToolsetBaseDirectory\Current) to find common .propsand.targetsfiles. If15.0orCurrent` toolset is specified, then this will (depending on .NET Core SDK version) override the default toolset configuration.

Relates to #46.

System.InvalidOperationException: Cannot determine base directory for .NET Core.

this extension never work for me.

[Error - 10:02:09 AM] Error loading MSBuild project '"e:\Projects\Other\WebApp21\WebAp2\WebAp2.csproj"'.
System.InvalidOperationException: Cannot determine base directory for .NET Core.
   at ProjectCollection MSBuildProjectTools.LanguageServer.Utilities.MSBuildHelper.CreateProjectCollection(string solutionDirectory, DotNetRuntimeInfo runtimeInfo) in D:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer.Common\Utilities\MSBuildHelper.cs:line 73
   at ProjectCollection MSBuildProjectTools.LanguageServer.Utilities.MSBuildHelper.CreateProjectCollection(string solutionDirectory) in D:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer.Common\Utilities\MSBuildHelper.cs:line 45
   at bool MSBuildProjectTools.LanguageServer.Documents.MasterProjectDocument.TryLoadMSBuildProject() in D:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer.Engine\Documents\MasterProjectDocument.cs:line 151

Check if it's still possible to render file-system hyperlinks in hover tooltips

Currently, they are rendered as raw markdown (e.g. [link](file://C:/Foo/bar.targets)) instead of hyperlinks.

May relate to microsoft/vscode#33577.

Server Not Initialized Error

I am attempting to add your language server within Eclipse. When starting the server I only receive the following message back:
{"protocolVersion":"2.0","message":{"code":-32002,"message":"Server Not Initialized"}}

To confirm, I am meant to launch the LS by following the build instructions then executing /out/language-server/MSBuildProjectTools.LanguageServer.Host.dll?

Are there any dependencies that would stop the server from initializing? Am I unaware of a required step?

Fix incorrect handling of non-Windows line endings

Caused by Microsoft.Language.Xml.

Previously the parser used Environment.NewLine but this causes portability issues because on non-Windows systems that's \n (instead of \r\n), leading to different calculations of absolute position within the source text.

Attribute completions are erroneously offered when creating a new element under an `ItemGroup` element

This is because ItemAttributeCompletion needs to check if the "element" where the attributes would be inserted has an empty name (i.e. we're inserting a new element) and avoid offering completions.

Please stop auto focussing the output window when I hover in a proj file

Please stop auto focussing the output window when I hover in a proj file.

https://cl.ly/0N172K3Y0403

XML Properties

Hello, thanks for this great extension!

There seems to be an issue when using XML properties with this extension. It seems to think that it is an invalid property when it isn't. The tooling give the error: "MyProperty" is not a valid child element of a "Property" element.

https://github.com/MicrosoftDocs/visualstudio-docs/blob/master/docs/msbuild/msbuild-properties.md#storing-xml-in-properties

Prefer descending over ascending in package versions

Nice tool!

Is it possible to change order of package versions so that newest is at top on autocomplete? Currently it shows oldest first which is bit strange.

Any plan on code snippets for MSBuild project file?

Hi,

Do you have any plan on code snippets for MSBuild project file? Any ideas?

Initialising MSBuild project tools...

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?

Support in the semantic model for XML namespaces

Currently, we pretty much ignore these; might be useful to capture this information at some point if we wanted to support XML schema (or similar) within the model.

Should be able to insert elements by triggering completion on element text or whitespace

Currently, if you press Ctrl+Space instead of < when inside text or whitespace, no element names are offered because the completions are currently designed to only replace an existing element (e.g. <> which is inserted when they press <).

Modify them to handle insertion of new elements, too (which is totally doable; just use the target position as an empty range).

Intellisense for MSBuild expressions

Maybe using something like this?

Probably too much work to handle invalid expressions, but at least we can handle the simple cases.

Cannot install on VSCode 1.13.0

I get Counldn't find a compatible version of MSBuild project tools with this version of Code

.csproj package autocomplete not working

I'm obviously missing something obvious but I cannot get Nuget package autocomplete to work at all. I've tried on Windows, Mac and Linux all seem to give the same output in debug mode.

(even tried fresh install inside VM's with just this extension and C# extension same thing)

Debug output: (note it seems to be looking for suggestions for Newtonsoft.Json but that's not even in the csproj package list.

Result was "System.Threading.Tasks.Task`1[[OmniSharp.Extensions.LanguageServer.Protocol.Models.InitializeResult, OmniSharp.Extensions.LanguageProtocol, Version=0.7.9.0, Culture=neutral, PublicKeyToken=null]]"
Response value was "OmniSharp.Extensions.LanguageServer.Protocol.Models.InitializeResult"
Finished: Routing Request (0) "initialize" in 35ms
Finding descriptor for "initialized"
Finding descriptor for "workspace/didChangeConfiguration"
Starting: Routing Notification "initialized"
Finished: Routing Notification "initialized" in 1ms
Starting: Routing Notification "workspace/didChangeConfiguration"
Converting params for Notification "workspace/didChangeConfiguration" to "MSBuildProjectTools.LanguageServer.CustomProtocol.DidChangeConfigurationObjectParams"
Finished: Routing Notification "workspace/didChangeConfiguration" in 76ms
Finding descriptor for "textDocument/didOpen"
Created attribute "xml::file:///c%3A/Users/Adam/Source/Repos/console31/console31.csproj"
Looking for handler for method ["OmniSharp.Extensions.LanguageServer.Server.HandlerDescriptor"]
Checking handler ["OmniSharp.Extensions.LanguageServer.Server.HandlerDescriptor"]:"MSBuildProjectTools.LanguageServer.Handlers.DocumentSyncHandler"
Registration options "OmniSharp.Extensions.LanguageServer.Protocol.Models.TextDocumentRegistrationOptions"
Document Selector "[msbuild, file, **/*.*], [xml, file, **/*.*proj], [xml, file, **/*.props], [xml, file, **/*.targets]"
Starting: Routing Notification "textDocument/didOpen"
Converting params for Notification "textDocument/didOpen" to "OmniSharp.Extensions.LanguageServer.Protocol.Models.DidOpenTextDocumentParams"
Language server initialised by client.
Finding descriptor for "textDocument/documentSymbol"
Found attributes 1, ["msbuild::file:///c%3A/Users/Adam/Source/Repos/console31/console31.csproj"]
Looking for handler for method ["OmniSharp.Extensions.LanguageServer.Server.HandlerDescriptor"]
Checking handler ["OmniSharp.Extensions.LanguageServer.Server.HandlerDescriptor"]:"MSBuildProjectTools.LanguageServer.Handlers.DocumentSymbolHandler"
Registration options "OmniSharp.Extensions.LanguageServer.Protocol.Models.TextDocumentRegistrationOptions"
Document Selector "[msbuild, file, **/*.*], [xml, file, **/*.*proj], [xml, file, **/*.props], [xml, file, **/*.targets]"
[Info  - 1:02:36 pm] 1 package sources configured for project "c:\Users\Adam\Source\Repos\console31\console31.csproj".
[Info  - 1:02:36 pm]   Locally-configured package source "nuget.org" (v3) => https://api.nuget.org/v3/index.json
Launching "dotnet --info"...
Launched "dotnet --info". Waiting for process 9376 to terminate...
"dotnet --info" terminated with exit code 0.
"dotnet --info" returned the following text on STDOUT / STDERR.

.NET Core SDK (reflecting any global.json):
 Version:   3.1.101
 Commit:    b377529961

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18363
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.1.101\

Host (useful for support):
  Version: 3.1.1
  Commit:  a1388f194c

.NET Core SDKs installed:
  2.1.401 [C:\Program Files\dotnet\sdk]
  3.1.101 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

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



Finding descriptor for "$/cancelRequest"
Finding descriptor for "textDocument/documentSymbol"
Found attributes 1, ["msbuild::file:///c%3A/Users/Adam/Source/Repos/console31/console31.csproj"]
Looking for handler for method ["OmniSharp.Extensions.LanguageServer.Server.HandlerDescriptor"]
Checking handler ["OmniSharp.Extensions.LanguageServer.Server.HandlerDescriptor"]:"MSBuildProjectTools.LanguageServer.Handlers.DocumentSymbolHandler"
Registration options "OmniSharp.Extensions.LanguageServer.Protocol.Models.TextDocumentRegistrationOptions"
Document Selector "[msbuild, file, **/*.*], [xml, file, **/*.*proj], [xml, file, **/*.props], [xml, file, **/*.targets]"
Requesting suggestions for NuGet package Ids matching prefix "Newtonsoft.Json" (include pre-release: False)...
[Info  - 1:02:39 pm] Successfully loaded project "c:\Users\Adam\Source\Repos\console31\console31.csproj".
===========================
 - Project uses package source "nuget.org" ("https://api.nuget.org/v3/index.json")
===========================
MSBuild project loaded (4 MSBuild objects).
MSBuildSdkImport: SdkImport "Microsoft.NET.Sdk" spanning "[1,10..1,33)"
MSBuildProperty: Property "OutputType" spanning "[4,5..4,33)"
MSBuildProperty: Property "TargetFramework" spanning "[5,5..5,53)"
MSBuildItemGroup: Item "PackageReference" spanning "[9,5..9,66)"
Finished: Routing Notification "textDocument/didOpen" in 3044ms
Starting: Routing Request (1) "textDocument/documentSymbol"
Converting params for Request (1) "textDocument/documentSymbol" to "OmniSharp.Extensions.LanguageServer.Protocol.Models.DocumentSymbolParams"
Result was "System.Threading.Tasks.Task`1[[OmniSharp.Extensions.LanguageServer.Protocol.Models.DocumentSymbolInformationContainer, OmniSharp.Extensions.LanguageProtocol, Version=0.7.9.0, Culture=neutral, PublicKeyToken=null]]"
Response value was "OmniSharp.Extensions.LanguageServer.Protocol.Models.DocumentSymbolInformationContainer"
Finished: Routing Request (1) "textDocument/documentSymbol" in 14ms
Starting: Routing Notification "$/cancelRequest"
Converting params for Notification "$/cancelRequest" to "OmniSharp.Extensions.LanguageServer.Protocol.Models.CancelParams"
Request 1 was not found to cancel
Finished: Routing Notification "$/cancelRequest" in 0ms
Starting: Routing Request (2) "textDocument/documentSymbol"
Converting params for Request (2) "textDocument/documentSymbol" to "OmniSharp.Extensions.LanguageServer.Protocol.Models.DocumentSymbolParams"
Result was "System.Threading.Tasks.Task`1[[OmniSharp.Extensions.LanguageServer.Protocol.Models.DocumentSymbolInformationContainer, OmniSharp.Extensions.LanguageProtocol, Version=0.7.9.0, Culture=neutral, PublicKeyToken=null]]"
Response value was "OmniSharp.Extensions.LanguageServer.Protocol.Models.DocumentSymbolInformationContainer"
Finished: Routing Request (2) "textDocument/documentSymbol" in 0ms
Found 9 suggestions for NuGet package Ids matching prefix "Newtonsoft.Json" (include pre-release: False).

Discussion: merging MSBuild project tools into OmniSharp / C# for VS Code

As briefly discussed with @DustinCampbell in dotnet/vscode-csharp#1156 and dotnet/vscode-csharp#1780.

If it's practical to do so, my preference would be for merging (over time) all of the extension's functionality into OmniSharp and deprecating the original extension (as opposed to keeping both extensions around which would, IMHO, be a poorer experience for users since there are bound to be conflicts when they compete to provide intellisense for the same file).

A quick architectural overview is available here. Most of the components are pretty modular so it should be possible to bring over only the bits that constitute the actual MSBuild language service (i.e. understanding what a given location in the .xxproj file actually means, either at the XML or MSBuild level). @DustinCampbell if you have a spare couple of moments, would you mind looking over the architectural overview to see if there's anything in there that looks immediately incompatible with how you know OmniSharp works? It's all targeting netstandard2.0 so should build fine against net461 / mono (which is what I assume OmniSharp builds against).

Alternatively, if the idea is simply to use the MSBuild language service as-is from the "C# for VS Code" extension that's even easier from my perspective :)

Parser support for MSBuild item-transform expressions

Currently, we can parse item expressions (@(XXX)), but not item-transform expressions (@(XXX->'YYY')).

Create new extension icon

Currently it's using the one from DocFX assistant.

Leaves behind processes when restarting vscode on linux

Expected Behavior

Opening a C# project in vscode, and reloading the vscode window does not spawn additional extension processes

Current Behavior

A new process is started each time vscode is reloaded and leaves old processes around

Steps to Reproduce

Open a C# project in vscode
View processes ps -ef | grep msbuild-project
In vscode, reload the window ctrl+shift+p -> Reload Window
View processes. Note there are now 2 instances of the extension running
Repeat step 3 to spawn additional processes

Environment

kubuntu 17.10
msbuild project tools 0.2.27 (happened in older versions as well)

Target dependency graph

Consider building a tree data provider that shows the dependency graph of targets in an MSBuild project .

Extension Package (VSIX) size is bit big!

The current package contains entire source code tree and including the pdb/xml files which causes the package size to be >10Mb!

Is this intended?
If so Why?

If not, Can we not include unnecessary files, I know the license states that you include source distribution but that's why we have git/GitHub and commit hashes right?

Would be easier to tag'em and put the hash in the ChangeLog?

Move help files to language server repository

Update language server to expect help files in help sub-directory of the server's deployment directory.

Project file parse error with dotnet-sdk-3.0-preview

Environment

msbuild extension version is "0.2.50"

here is the dotnet --info result;

.NET Core SDK (global.json を反映):
 Version:   3.0.100-preview-009812
 Commit:    e3abf6e935

ランタイム環境:
 OS Name:     Windows
 OS Version:  6.3.9600
 OS Platform: Windows
 RID:         win81-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.0.100-preview-009812\

Host (useful for support):
  Version: 3.0.0-preview-27122-01
  Commit:  00c5c8bc40

.NET Core SDKs installed:
  1.0.0-preview2-003121 [C:\Program Files\dotnet\sdk]
  1.0.0-preview2-003131 [C:\Program Files\dotnet\sdk]
  1.0.0-preview2-003133 [C:\Program Files\dotnet\sdk]
  1.0.0-preview2-003156 [C:\Program Files\dotnet\sdk]
  1.0.0-preview2-1-003177 [C:\Program Files\dotnet\sdk]
  1.0.4 [C:\Program Files\dotnet\sdk]
  2.0.0 [C:\Program Files\dotnet\sdk]
  2.0.2 [C:\Program Files\dotnet\sdk]
  2.1.2 [C:\Program Files\dotnet\sdk]
  2.1.3 [C:\Program Files\dotnet\sdk]
  2.1.4 [C:\Program Files\dotnet\sdk]
  2.1.100 [C:\Program Files\dotnet\sdk]
  2.1.104 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.300 [C:\Program Files\dotnet\sdk]
  2.1.301 [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 [C:\Program Files\dotnet\sdk]
  3.0.100-preview-009812 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.1 [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 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.1 [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 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview-18579-0056 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.0-rc2-3002702 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.3 [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.0 [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.0 [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.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.5 [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.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.1 [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 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview-27122-01 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0-alpha-27128-4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

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

Steps to reproduce

install dotnet-sdk-3.0-preview from https://dotnet.microsoft.com/download/dotnet-core/3.0
create c# console project with dotnet new console
open with vscode
open csproj

Expected Result

project file can be opened with no error

Actual Result

Almost extension seems to work correctly, but the following error is always occured.

The imported project "C:\Program Files\dotnet\sdk\3.0.100-preview-009812\15.0\Microsoft.Common.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

this is because dotnet-sdk renamed Microsoft.Common.props's directory from "15.0" to "Current" since dotnet-sdk-3.0.
(perhaps since this commit)

Feature Request: Use regular MSBuild Binary Location

Using this VSCode Extension for opening some CSProj Files gives out errors because the well-known MSBuild variables link to very different locations than the build system actually uses.

Example:
When editing CSProj Files for Portable Class Libraries you'll see that the line
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\Portable\$(TargetFrameworkVersion)\Microsoft.Portable.CSharp.targets" />

shows an error, because it relies on the fact that PCL Supports Libraries and Targets are available using the provided path from the given default MSBuild binary directory: in this case: $(MSBuildExtensionsPath32)

When actually validating the csproj (through building e.g.) MSBuild provides this variable as part of "well
-known MSBuild Properties" that are preset by the binary itself.

But because the vscode extension provides the msbuild binary itself as part of the language server, those well-known Properties are skewed towards

....\extensions\tintoy-msbuild-project-tools-0.2.27\out\language-server\

where there are no extensions for msbuild.
Most pre-installed extensions for MSBuild, like WiX Toolset or PCL-Support are installed next to the visual studio / msbuild binaries, where they can then use well-known MSBuild properties to move towards their relative directory.

I would request that the vscode-extension lets me override the default msbuild binary location via settings, so it can use my Visual Studio install MSBuild binaries instead of the binaries pre-deployed with the language-server components.

Improve performance of task completions

This is still slower than I'd like (seems to have a floor of around 200ms, which is way too long).

Consider scanning task assembly metadata in the background and only using the cached results (i.e. no on-demand scanning).

Extension causes high cpu load

Issue Type: Performance
Extension Name: msbuild-project-tools
Extension Version: 0.2.53
OS Version: Windows_NT x64 10.0.18305
VSCode version: 1.31.1

⚠️ Make sure to attach this file from your home-directory: C:\Users\hp\tintoy.msbuild-project-tools-unresponsive.cpuprofile.txt ⚠️

Find more details here: https://github.com/Microsoft/vscode/wiki/Explain:-extension-causes-high-cpu-load

Leaves behind processes when restarting vscode on linux - Part Deux - Risen From The Dead

Reference: #36 (comment)

Version: 1.36.0-insider
Commit: c089daa858f34631f5f827ff8a0313bf1e2ded6d
Date: 2019-06-07T05:15:26.964Z
Electron: 4.2.3
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Linux x64 5.1.15.a-1-hardened

MSBuild project tools: 0.2.55

2019-08-25 12:29:24.536 -05:00 [Verbose/] Logger initialised.
2019-08-25 12:29:25.623 -05:00 [Debug/] Creating language server...
2019-08-25 12:29:26.244 -05:00 [Debug/] Waiting for client to initialise language server...
2019-08-25 12:29:26.730 -05:00 [Debug/] Finding descriptor for "initialize"
2019-08-25 12:29:30.271 -05:00 [Debug/] Starting: Routing Request (0) "initialize"
2019-08-25 12:29:30.395 -05:00 [Debug/] Converting params for Request (0) "initialize" to "OmniSharp.Extensions.LanguageServer.Protocol.Models.InitializeParams"
2019-08-25 12:29:30.524 -05:00 [Debug/] Result was "System.Threading.Tasks.Task`1[[OmniSharp.Extensions.LanguageServer.Protocol.Models.InitializeResult, OmniSharp.Extensions.LanguageProtocol, Version=0.7.9.0, Culture=neutral, PublicKeyToken=null]]"
2019-08-25 12:29:30.581 -05:00 [Debug/] Response value was "OmniSharp.Extensions.LanguageServer.Protocol.Models.InitializeResult"
2019-08-25 12:29:30.602 -05:00 [Debug/] Finished: Routing Request (0) "initialize" in 295ms
2019-08-25 12:29:30.917 -05:00 [Debug/] Finding descriptor for "initialized"
2019-08-25 12:29:30.919 -05:00 [Debug/] Finding descriptor for "workspace/didChangeConfiguration"
2019-08-25 12:29:30.965 -05:00 [Debug/] Starting: Routing Notification "initialized"
2019-08-25 12:29:30.983 -05:00 [Debug/] Finished: Routing Notification "initialized" in 15ms
2019-08-25 12:29:31.000 -05:00 [Debug/] Starting: Routing Notification "workspace/didChangeConfiguration"
2019-08-25 12:29:31.002 -05:00 [Debug/] Converting params for Notification "workspace/didChangeConfiguration" to "MSBuildProjectTools.LanguageServer.CustomProtocol.DidChangeConfigurationObjectParams"
2019-08-25 12:29:31.311 -05:00 [Debug/] Finished: Routing Notification "workspace/didChangeConfiguration" in 310ms
2019-08-25 12:29:31.326 -05:00 [Debug/] Language server initialised by client.
2019-08-25 17:31:53.219 -05:00 [Debug/] Finding descriptor for "shutdown"
2019-08-25 17:31:54.480 -05:00 [Debug/] Starting: Routing Request (1) "shutdown"
2019-08-25 17:31:54.489 -05:00 [Debug/] Converting params for Request (1) "shutdown" to "System.Object"

Opened:

$ ps -ef |grep -P ".*(1309|tintoy).*"
username     1309     1  0 12:29 ?        00:02:43 /<pathTo>/VSCode-linux-x64/code-insiders
username     1311  1309  0 12:29 ?        00:00:00 /<pathTo>/VSCode-linux-x64/code-insiders --type=zygote --no-sandbox
...
username     1638  1438  0 12:29 ?        00:00:23 /<pathTo>/.vscode-insiders/extensions/tintoy.msbuild-project-tools-0.2.55/out/language-server/MSBuildProjectTools.LanguageServer.Host.dll

Closed:

$ ps -ef |grep -P ".*(1309|tintoy).*"
username     1638     1  0 12:29 ?        00:00:23 /usr/bin/dotnet /<pathTo>/.vscode-insiders/extensions/tintoy.msbuild-project-tools-0.2.55/out/language-server/MSBuildProjectTools.LanguageServer.Host.dll

EDIT0:
Mind you, it doesn't happen all of them time, only when I'm working on stuff.
For example, I just did another quick test by opening vscode to include your extension version here and then closed it and there's only that same instance (1638) listed.

I don't know if it matters if I also had another vscode window open to also work on a c++ project.
I hadn't even worked on any msbuild stuff in this session.
But whatever the difference, ALL vscode instances had been closed and the extension remained.

After upgrading to VS 2017 15.5.x, all projects in VS Code now show "Invalid static method invocation syntax" error

More specifically, Invalid static method invocation syntax error: "[MSBuild]::IsRunningFromVisualStudio()".

See tintoy/msbuild-project-tools-server#1 for details.

UserSecretsId Missing From PropertyGroup

I'm making the assumption that this extension is used to expose things like the PropertyGroup UserSecretsId (https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-2.2&tabs=linux#set-a-secret), but the closest I get is "GenerateUserSecretsAttribute".

I know the limitation mentioned for PropertyGroups, but wasn't sure if this applied. Maybe it's something best left for the msbuild folks to figure out.

This is something I brought up in a comment at dotnet/aspnetcore#2867 (comment)

Missing GenerateDocumentationFile property

There is a common property called <GenerateDocumentationFile>true</GenerateDocumentationFile> which is missing from this extension. Is it possible to add this?

Support for private feeds requiring authentication

I might be wrong but I have the feeling that when it comes to PackageReference Intellisense it does not support private feed which are requiring authentication.

[Error - 12:39:05] Failed to provide completions.
NuGet.Protocol.Core.Types.FatalProtocolException: The source does not have a Search service!
   at async Task<IEnumerable<string>> NuGet.Protocol.AutoCompleteResourceV3.IdStartsWith(string packageIdPrefix, bool includePrerelease, ILogger log, CancellationToken token)
   at async Task<SortedSet<string>> MSBuildProjectTools.LanguageServer.Utilities.NuGetHelper.SuggestPackageIds(IEnumerable<AutoCompleteResource> autoCompleteResources, string packageIdPrefix, bool includePrerelease, ILogger logger, CancellationToken cancellationToken) in D:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer.Common\Utilities\NuGetHelper.cs:line 142
   at async Task<SortedSet<string>> MSBuildProjectTools.LanguageServer.Documents.ProjectDocument.SuggestPackageIds(string packageIdPrefix, bool includePrerelease, CancellationToken cancellationToken) in D:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer.Engine\Documents\ProjectDocument.cs:line 377
   at async Task<List<CompletionItem>> MSBuildProjectTools.LanguageServer.CompletionProviders.PackageReferenceCompletion.HandlePackageReferenceAttributeCompletion(ProjectDocument projectDocument, XSAttribute attribute, CancellationToken cancellationToken) in D:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer.Engine\CompletionProviders\PackageReferenceCompletion.cs:line 155
   at async Task<CompletionList> MSBuildProjectTools.LanguageServer.CompletionProviders.PackageReferenceCompletion.ProvideCompletions(XmlLocation location, ProjectDocument projectDocument, CancellationToken cancellationToken) in D:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer.Engine\CompletionProviders\PackageReferenceCompletion.cs:line 92
   at async Task<CompletionList> MSBuildProjectTools.LanguageServer.Handlers.CompletionHandler.OnCompletion(TextDocumentPositionParams parameters, CancellationToken cancellationToken) in D:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer.Engine\Handlers\CompletionHandler.cs:line 193

Upgrade to .NET Core 3.1.x

3.1.x is the next LTS release so it's worth targeting if possible.

May relate to #62.

More clearly split Language Server and VSCode extension

The language server in this repo is reusable out of vscode and doesn't require node nor typescript to build/run. In order to make it easier for other IDEs to consume it, it would be great to more clearly separate the pure LSP parts and the VSCode parts so consumers could pick only the LSP part.
cc @LucasBullen

Null response for empty completion requests

Request:

{
  "jsonrpc":"2.0",
  "id":"2",
  "method":"textDocument/completion",
  "params":{
    "textDocument":{
      "uri":"file:///home/lbullen/runtime-EclipseApplication/NewDotnetProject1/NewDotnetProject1.csproj"
    },
    "uri":"file:///home/lbullen/runtime-EclipseApplication/NewDotnetProject1/NewDotnetProject1.csproj",
    "position":{
      "line":0,
      "character":0
    }
  }
}

Response:

{
  "protocolVersion":"2.0",
  "id":"2",
  "result":null
}

Looking at the LSP for completion-requests, the expected response should be CompletionItem[] | CompletionList.

null is not accepted or else the protocol would look like the Goto Definition Request Protocol: Location | Location[] | null

Be able to filter out pre-release packages in the auto-complete drop-down

Is it possible to add a way to filter whether you want to include or not pre-release package versions in the auto-complete drop-down. I'm not sure how much UI control and flexibility is possible in the drop-down (i.e. is it a built-in component of VSCode or completely custom?), but maybe just a small section down at the bottom of the drop-down that has a checkbox for Pre-Release?

(BTW, love your tool!)

Simplify configuration schema

Configuration is getting a little crusty and organisation is tending towards nonsensical. Rationalise it.

Old schema:

{
    "msbuildProjectTools": {
        "language": {
            "enable": true,
            "disableHover": false,
            "logLevel": "Information",
            "logFile": "",
            "trace": false,
            "seqLogging": {
                "logLevel": "Debug",
                "url": "http://localhost:5341/",
                "apiKey": "whatever"
            },
            "completionsFromProject": [
                "ItemType",
                "ItemMetadata",
                "Property"
            ],
            "experimentalFeatures": [
                "expressions"
            ]
        },
        "nuget": {
            "newestVersionsFirst": true,
            "includePreRelease": true,
            "disablePrefetch": false
        }
    }
}

New schema:

{
    "msbuildProjectTools": {
        "schemaVersion": 1,
        "logging": {
            "level": "Debug",
            "file": "Log.txt",
            "trace": true,
            "seq": {
                "level": "Debug",
                "url": "http://localhost:5341/",
                "apiKey": "whatever"
            }
        },
        "language": {
            "useClassicProvider": false,
            "disable": {
                "hover": false
            },
            "completionsFromProject": [
                "Property",
                "ItemType",
                "ItemMetadata",
                "Target",
                "Task"
            ]
        },
        "nuget": {
            "newestVersionsFirst": true,
            "includePreRelease": false,
            "disablePrefetch": true
        },
        "experimentalFeatures": [
            "expressions"
        ]
    }
}

Invalid static method invocation syntax

Invalid static method invocation syntax: "[Microsoft.Build.Utilities.ToolLocationHelper]::GetPathToStandardLibraries($(TargetFrameworkIdentifier), $(TargetFrameworkVersion), $(TargetFrameworkProfile), $(PlatformTarget)

Add .msbuild extension as MSBuild known file

Completions don't always work correctly in .props files

If a *.props file is opened without first having opened a *.*proj file, then completions don't work correctly. Work out why this is happening and fix it :)

(I suspect it's due to an assumption about project SDK somewhere in the the semantic model?)

The expression cannot be evaluated.

Here are the repro steps:

Create MVC site
```
dotnet new mvc -n m1
cd m1
```
Open VSCode
```
code .
```

Open m1.csproj

You will see the following red line:

The error message is:

The expression ""Controllers\HomeController.cs".GetPathsOfAllDirectoriesAbove()" cannot be evaluated. System.String.GetPathsOfAllDirectoriesAbove
g:\Projects\m1\m1.csproj(MSB4184)

Support for custom file extensions

My msbuild files have a .build extension and I would like to use this tool, is it possible to configure somehow ?

CSPROJ package autocomplete not working

Autocomplete for packages not working

System.InvalidOperationException: Cannot determine base directory for .NET Core

Seems to be a dupe of #43

System.InvalidOperationException: Cannot determine base directory for .NET Core (check the output of 'dotnet --info').
at ProjectCollection MSBuildProjectTools.LanguageServer.Utilities.MSBuildHelper.CreateProjectCollection(string solutionDirectory, DotNetRuntimeInfo runtimeInfo, Dictionary<string, string> globalPropertyOverrides) in /////

Fresh install on Ubuntu 18.04 with only C# extension and this one installed.

Output of dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 2.2.203
Commit: e5bab63eca

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

Host (useful for support):
Version: 2.2.4
Commit: f95848e524

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

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

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

Implement default values for well-known property completions

These will go in help/properties.json alongside the description attribute for each property. For example:

"AllowUnsafeBlocks": {
        "description": "Allow unsafe code blocks.",
        "defaultValue": "true"
}

CC: @doggy8088

Language server is not correctly reporting server capabilities when first initialised

As first reported in tintoy/msbuild-project-tools-vscode#12, the server's response to the initialize request does not correctly report server capabilities.

This was due to a bug in the OmniSharp LSP implementation, but was rectified in v0.4.1.

CC: @LucasBullen

Unit tests for completion providers

We may need to implement a couple of stubs for this to work, but I'd like to see tests similar to the ones for the XmlLocator API's CanCompleteXXX but with actual offers of completion.

Completions do not work for packages that have only pre-release versions available

This is due to a bug in the NuGet v3 protocol client that fails to correctly inform the NuGet AutoComplete API end-point that pre-release packages should be included (see NuGet/Home#7540 for details).

Transferred from #44.

CC: @SimantoR

Add completions for item metadata expressions

Feature comes in 2 parts:

Unqualified metadata expression - %(MetadataName): when the user types %() in an expression under an item element or in the body of an item-transform expression, offer metadata names for completion from the following sources:
- Built-in metadata
- Metadata defined on the item itself
- Metadata from the ItemGroupDefinition (if any).
Qualified metadata expression - %(ItemType.MetadataName): when the user types %() anywhere it's legal to refer to item metadata, offer a list of item types.
- When they select an item type, append a . and re-trigger completion, offering a list of metadata names from the following sources:
  - Built-in metadata
  - Metadata defined on the item itself
  - Metadata from the ItemGroupDefinition (if any).

If the second approach (for item-qualified metadata expressions) proves impractical, we could simply offer a list of ItemType.WellKnownMetadata combinations (providing this doesn't blow out the completion list to an unmanageable size).

tintoy / msbuild-project-tools-vscode Goto Github PK

msbuild-project-tools-vscode's Introduction

MSBuild project file tools

Usage

File extensions

Installation

Building from source

Design

Limitations

Questions / bug reports

msbuild-project-tools-vscode's People

Contributors

Stargazers

Watchers

Forkers

msbuild-project-tools-vscode's Issues

Expected Behavior

Current Behavior

Steps to Reproduce

Environment

Environment

Steps to reproduce

Expected Result

Actual Result

Recommend Projects

Recommend Topics

Recommend Org