-
Notifications
You must be signed in to change notification settings - Fork 17
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
Feature Request: Use regular MSBuild Binary Location #35
Comments
Hey, thanks for the detailed report! I'm pretty sure we can find a way to make it work correctly for your use-case. It's 11pm here in AU, but I'll look into this first thing tomorrow :) |
Just one thing to be aware of; task assemblies that truly require the full framework rather than netcoreapp2.0 probably won't work because the language service has to target that for cross-platform support (but let's see what we can do) |
No problem. Take your time. This is nothing stopping me from work. As for the netcoreapp2.0 thing; Indeed that could be an issue, although.... all the extension needs is the targets/props files right? It doesn't try to load the DLL to read properties right? The target file itself should be framework independent. The DLLs are only required at runtime, at which point the whole thing isn't in your hand anymore? |
No, you're correct :) It's only if you have targets that compute items dynamically using inline tasks (or netfx ones) that you'd even notice I think. |
We deliberately use the MSBuild equivalent of the ReflectionOnly assembly-load context (i.e. can't invoke targets). |
Does the extension even support inline tasks? We're talking about those
CDATA blocks right?
|
Correct, it can't (at this stage) because the version of MSBuild that's
part of .net core doesn't support them. Their cross-compatibility story is
still evolving though so maybe one day...
|
Here's where we set up the project collection: I just need to make the extensions directory customisable (and make sure that doesn't break anything by making the .net core targets inaccessible). |
For example, SDK imports |
Ok, so having had a look at the code, we default to using This directory does contain the targets required to make I can provide settings to override I might be able to detect whether the root |
Just out of curiosity, if you run "dotnet build" on your PCL project, does it build correctly? |
This issue makes me think that perhaps it might all work if you only override |
If I can get you a custom build would you be willing to try it out? |
At purely windows shops you don't actually run the dotnet cli all that much. |
@MeikTranel that would be fantastic! If it helps, here's a branch where I was playing around with the ideas we've been discussing: https://github.com/tintoy/msbuild-project-tools-server/tree/feature/msbuild-extensions-directory (the language server is in a separate repository because other editors, such as Eclipse, use the language service without the VSCode extension) It might be worth making the property overrides more generic, though - perhaps if the configuration looked something like this: "msbuild": {
"overrideGlobalProperties": {
"MSBuildExtensionsPath32": "C:\\Program Files (x86)\\MSBuild"
}
} What do you think? Anyway, feel free to have a play around, open a PR and we can discuss further. Thanks for getting involved! |
PS. See the |
PPS. On the extension side, here's the example configuration change I was playing with: a05fa2a |
Oh, and finally - all you need to do to build and use the language service is:
|
@MeikTranel - have you had a chance to play around with this yet? If you don't have the time, I'm happy to implement the option I mentioned above (override MSBuild global properties) which should get you 80% of the way towards what you need to do... |
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
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.
The text was updated successfully, but these errors were encountered: