-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable support for MSBuild Authoring projects #4
Comments
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 |
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! 😁 |
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. |
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? |
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 Or you can simply open the root 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. |
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 |
Perhaps we could start documenting some of this stuff in the project wiki? |
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. |
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 |
If you want to build and run the server, I'd suggest recursively cloning |
WOW! I don't know where to start, but first thanks for accepting my suggestions! For comment#1For the 1st issue: E.g.: Consider this
^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#2For my Project that uses custom Sdk and overrides some global properties, this doesn't work.
Yes, You can do with this idea. A config file that can set some project specific and env overrides. That would be god send! |
Ah, so are you saying you'd like to see each of the individual sub-expressions in the condition displayed separately? |
For comment#6I will look at existing extensions like Qub's and others to come up with a generic solution! For comment#7If 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#8I will definitely do that once I read your docs and understand your project and LSP! |
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. |
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 |
I see, so there would be not evaluation of property, metadata and global functions? |
We can see evaluated values of entire expressions via properties like |
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! |
Fom memory, someone from Xamarin has built one for VS for Mac that is the MSBuild team's preferred solution. Michaela Hutchins maybe? |
BTW, make sure the language for the current file is |
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). |
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). |
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... |
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! I did some reading yesterday, I'll start by doing some tinkering with the help area! |
One Q though, what made you to build this extension? |
Scratching my own itch - wanted package reference completion, just sort of grew from there :) |
Only found out later that there were other extensions for MSBuild and none were open-source at the time so I built my own. |
I also wanted to learn about compilers and languages and since I'd done a lot of MSBuild stuff it made sense |
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:
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!
The text was updated successfully, but these errors were encountered: