Enable support for MSBuild Authoring projects

[Nirmal4G]

I'm doing a lot of MSBuild Sdk projects, I was using Qub's MSBuild Tools when I was first beginning to use VSCode, and then I found your's after some time. I was using them both until now.

Here are few feature suggestions for your extension that relates to language server:

1. For Conditions, Please show the detailed Evaluated result.

E.g:

<Individual Properties/Expression>: <value>
Evaluated: <Evaluated Exp>
Result: <true/false>

2. Let us set a context project to which against the props/targets for both Sdk-style and regular projects will be Evaluated!

E.g: When working on set of targets/props either separately or through Sdk pattern, the opened props/targets are evaluated as if they are used directly so, most of the properties would turn up empty or undefined which leads to serious Item issue, where a code fragment like this one:

https://github.com/nirin/msbuild-sdks/blob/feature/sdks/Source/MSBuild.NET.Extras.Sdk/Build/MSBuild.NET.Extras.Items.props#L39-L55

3. Qub's tools link docs to the known MSBuild xml element and attributes, so if possible please add this feature too!

P.S.: I'm willing to help, but I'm new at MSBuild, right now I'm learning MSBuild authoring so that I can use it in my own projects. Yours and Qub's extension really helped me a lot!

[tintoy]

Hi! Thanks for the suggestions, and I'm glad it's been useful :)

I'll take a look at these first thing tomorrow morning (it's dinner time here in Australia) and see what can be done. Any assistance would be both welcome and appreciated, BTW

[Nirmal4G]

It'll take some time to learn LSP and it's internals. I'll give it a try over this weekend, in the meantime, I'll help you with the common scenarios that we face. And enjoy your Dinner! 😁

[tintoy]

Ok - item 1 is pretty easy to implement :)

Item 2 probably requires some design work; I'll have a think about what's involved and get back to you as soon as I think I have a workable design (but feel free to suggest one if you already have ideas).

Item 3 is pretty easy to do; the only tricky bit may be working out how to calculate the URL for a given element / attribute.

I'll create separate issues to track this work.

[tintoy]

Item 1 is already implemented, as far as I can tell - when you hover over a condition attribute, it shows the following:

Is that what you had in mind, @Nirmal4G?

[tintoy]

Item 2 sort of works already, but there's no pick-list to select the root project. Instead, the first project you open becomes the root project. In other words, if you want to work with a .props file, just open the .csproj file that imports it and ctrl-click on the Import element's Project attribute to open the .props file (or ctrl-click on the root Project element's Sdk attribute to open the associated .props / .targets files.

Or you can simply open the root .csproj file and then manually open the file you actually want to edit.

Some of this stuff is mentioned in the README for msbuild-project-tools-vscode but the docs could certainly do with some improvement :)

But I could probably add a pick-list to allow you to select 1 of the currently-open projects to become the root if that helps.

[tintoy]

This might help you get an idea of how the language server is put together:

https://github.com/tintoy/msbuild-project-tools-server/blob/master/docs/architecture/overview.md

[tintoy]

Perhaps we could start documenting some of this stuff in the project wiki?

[tintoy]

I've started adding help links for well-known elements as part of #5, but I'll need to work out how to best present these as part of the hover content.

[tintoy]

BTW, looking at the project you linked it might be worth mentioning that we host the language server in .NET Core (so we use the netstandard-compatible MSBuild engine, not the desktop one). Since we load the project in design mode (i.e. we don't run any targets / tasks) this is probably be fine but it's still worth keeping in mind.

[tintoy]

If you want to build and run the server, I'd suggest recursively cloning msbuild-project-tools-vscode (which includes msbuild-project-tools-server as a submodule in the correct location). See the docs for info on how to build / run and let me know if you have any questions :)

[Nirmal4G]

WOW!

I don't know where to start, but first thanks for accepting my suggestions!

For comment#1

For the 1st issue:

E.g.: Consider this "$(_1) != $(_2) and ($(_1.Contains('xyz')) or $(_2.Trim('abc')) == $(_3)) and [RegEx]::IsMatch($(_3), 'regex')"

$(_1): <value>
$(_2): <value>
$(_2.Trim('abc')): <value> ^
$(_3): <value>
[RegEx]::IsMatch($(_3), 'regex'): <value> ^
Evaluated: <the one you're already dispalying>
Result: <true/false>

^The expression parts displayed may be global functions and but if it's possible we can include complex property functions like '.Trim*', etc...

This is how I want it to be displayed!

For comment#2

For my Project that uses custom Sdk and overrides some global properties, this doesn't work.

I could probably add a pick-list to allow you to select 1 of the currently-open projects to become the root if that helps.

Yes, You can do with this idea. A config file that can set some project specific and env overrides. That would be god send!

[tintoy]

Ah, so are you saying you'd like to see each of the individual sub-expressions in the condition displayed separately?

[Nirmal4G]

For comment#6

I will look at existing extensions like Qub's and others to come up with a generic solution!

For comment#7

If we're not loading tasks then there is not need to distinguish between desktop and core, besides I only need to debug props/targets before it reaches the first target. So I have only to check until 2nd pass to validate my props/targets. I can then do a build to check whether the targets are performing properly!

For comment#8

I will definitely do that once I read your docs and understand your project and LSP!

[Nirmal4G]

Ah, so are you saying you'd like to see each of the individual sub-expressions in the condition displayed separately?

Yes, that might sum it up, but see the layout, that includes properties too, if those are counted as expressions, Are those!? And we don't need to include all of the expressions just ones that complex like regex and contains more than one sub expressions.

[tintoy]

The language service has some understanding of MSBuild expressions - I wrote a parser for them because the MSBuild engine doesn't expose theirs directly. We can probably do what you need - it's certainly an opportunity for improving the expression parser :) note that msbuild can expand expressions into strings for us, but it won't evaluate them for us

[Nirmal4G]

I see, so there would be not evaluation of property, metadata and global functions?
That's why I have been seeing Value would have been? So there's no Evaluation!?

[tintoy]

We can see evaluated values of entire expressions via properties like ProjectItem.EvaluatedCondition, but not necessarily of individual components (but we can experiment to see exactly where the line is).

[Nirmal4G]

I'll also ask if MSBuild team have any plans for their own Language Server, since the .NETCore and Xamarin teams have been asking for it!

[tintoy]

Fom memory, someone from Xamarin has built one for VS for Mac that is the MSBuild team's preferred solution. Michaela Hutchins maybe?

[tintoy]

BTW, make sure the language for the current file is MSBuild, not XML, if you want intellisense for MSBuild expressions. There are a lot of tests for the parser if you want to see examples of how to use it.

[tintoy]

We can almost certainly show any properties in expressions separately (the parser can find them even if they're nested), but probably not stuff like item transforms (since MSBuild provides no way to evaluate them separately).

[tintoy]

Given how complex some of your expressions appear to be perhaps it's worth adding a separate view where we can decompose the expression rather than trying to cram it into a tool tip. VSCode supports custom views like the markdown preview so we can probably use that facility (data comes from the language server via custom request / response but is rendered by the extension).

[tintoy]

And if it's a separate view we can probably use item trickery with project snapshots to evaluate just about anything. I've also been thinking about a tree view showing targets and tasks...

[Nirmal4G]

I did mark props, targets, tasks, items, *proj as MSBuild, Thanks, I read it in your ReadMe

I hate the idea of a separate page but with what you are proposing, we can do a lot in that document!
Might as well give it a try.

I did some reading yesterday, I'll start by doing some tinkering with the help area!
I'm also thinking Visual Studio IDE Integration. Mads at Microsoft Web Tools team has a lot of helpful extensions for authoring VS Extensions. It might be time to try some of them!
The one built by the Xamarin team, Is it open source?

[Nirmal4G]

One Q though, what made you to build this extension?

[tintoy]

Scratching my own itch - wanted package reference completion, just sort of grew from there :)

[tintoy]

Only found out later that there were other extensions for MSBuild and none were open-source at the time so I built my own.

[tintoy]

I also wanted to learn about compilers and languages and since I'd done a lot of MSBuild stuff it made sense