Question about msbuild dependencies

[valeriob]

Hi,
in R4MVC we use MSBuildWorkspace to navigate the project and generate code.
To make it work we need to add references to msbuild nuget packages :
Microsoft.Build and Microsoft.Build.Tasks.Core.
If we do not add those references a simple main does not work :

Problem is that every time the sdk ships a new version we are forced to update that reference because it's not compatible in some way. See #T4MVC/R4MVC#99

Is there a way to avoid this issue ?

[livarcocc]

@rainersigwald @DustinCampbell any ideas?

[DustinCampbell]

You should not add references to any MSBuild packages when using MSBuildWorkspace. In fact, if there are any Microsoft.Build.* assemblies in your application's directory, you should remove them. Then, use the Microsoft.Build.Locator package to register an instance of MSBuild on the current machine.

Here's a pull request where I showed an MSBuildWorkspace consumer how to modify their project to use MSBuildWorkspace successfully: FizzerWL/ErrorRepro#1.

In addition, we are releasing a new version of MSBuildWorkspace soon and we're including some documentation. Here is a gist with an early look at the docs that show how to be successful with MSBuildWorkspace: https://gist.github.com/DustinCampbell/32cd69d04ea1c08a16ae5c4cd21dd3a3.

What is R4MVC?

[valeriob]

Thanks @DustinCampbell it works!
But i really can't understand why i have to have visual studio installed to generate code from a simple command line application ? I would like the tool to be independent from the environment and just work, that's why msbuild was bundled, but we had problem running it because it conflicted with dotnet core sdk.
Do you think it's possible to have a selft contained way to do that ?

R4MVC is a tool to generate aspnet core helper methods to generate links (like t4mvc was for aspnet) and avoid the messy string parameters.

Thanks!

[DustinCampbell]

You could do it in a self-contained way, but you would need to ship MSBuild and all of the tasks/targets needed to process any project that you want to throw at it. If you only care about .NET Core projects, this is a smaller set, but it's up to you to deploy them. At a minimum, you would need the following packages for .NET Core projects:

• Microsoft.Build.Runtime
• Microsoft.Build
• Microsoft.Build.Framework
• Microsoft.Build.Tasks.Core
• Microsoft.Build.Utilities.Core

Then, you would also deploy the SDK resolvers which are used by MSBuild to locate the .NET Core SDK appropriate for a particular project.

[DustinCampbell]

Sorry, I also forgot that you would likely need to deploy the NuGet.Build.Tasks since the latest MSBuild common targets depend on that.

Essentially, this is just not a simple thing to do. And the steps I provided only work for SDK-style projects. Supporting .NET Framework projects is another problem entirely from a deployment perspective. Even worse, your application will need to be updated to support any new MSBuild features, which can put you in a bad spot.

[valeriob]

Thanks for the explanation ! it's very helpfull !
So what would be the way to depend only on dotnet core sdk instead of the whole visual studio ?

[DustinCampbell]

Everything I outlined above is how you do that today.

[artiomchi]

Awesome, this looks like it should let us move forward. Thanks!

Are there any plans to make MSBuildWorkspace compiled against .NET Standard? It would be great if it were available in any environment where dotnet apps can be built and compiled

[valeriob]

Just one more thing, how do we do this ? I tried without luck to find any doc related

you would also deploy the SDK resolvers which are used by MSBuild to locate the .NET Core SDK appropriate for a particular project.

[DustinCampbell]

@artiomchi: Potentially. There is some investigation being done on that.

[DustinCampbell]

@valeriob: are firmly in undocumented and unsupported territory if you're deploying MSBuild yourself. 😄 However, we do exactly this same thing successfully in OmniSharp: https://github.com/OmniSharp/omnisharp-roslyn.

The SDK resolvers are available from the nightly dotnet-core feed on MyGet (https://dotnet.myget.org/gallery/dotnet-core). The following packages are available:

• runtime.linux-x64.Microsoft.NETCore.DotNetHostResolver
• runtime.osx-x64.Microsoft.NETCore.DotNetHostResolver
• runtime.win-x64.Microsoft.NETCore.DotNetHostResolver
• runtime.win-x86.Microsoft.NETCore.DotNetHostResolver

Note that these are native packages that our OS dependent. In addition, they have to be laid out in a specific way on the disk. You should be able to gleen that from how OmniSharp does it if you want to go down this route.

[artiomchi]

@valeriob You don't necessarily need the full VS install either - we just need a version of MSBuild installed on the system.

From what I understand, you could just install the VS Build tools, which is a MUCH lighter install. It will install the compilers on the system without the whole IDE, and should still be picked up by the MSBuildLocator

[artiomchi]

@DustinCampbell Thanks again by the way - I just tested your approach in R4MVC and it worked perfectly. I have no idea how I haven't noticed this package (and haven't read about it before). It's exactly what I've been looking for.

Regarding the workspace support with .NET Standard - is there a GitHub issue or some other thread that I can subscribe to to follow the progress on this?

[DustinCampbell]

There are many issues, though this one looks most relevant: dotnet/roslyn#17968.

[valeriob]

Yep thanks,
i'm asking if it's possible to detect msbuild bundled with dotnet sdk instead of visual stduio, this will lower the barrier so much for people using vscode !
Something like MSBuildLocator.QueryDotNetSdkInstances()

[rainersigwald]

@valeriob That's tracked by microsoft/MSBuildLocator#30. An attempt was started, but it's turning out to be surprisingly complicated and hasn't been completed.

[valeriob]

Thanks ! /subscribed 😄

[github-actions]

Due to lack of recent activity, this issue has been labeled as 'stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.

[github-actions]

This issue will now be closed since it has been labeled 'stale' without activity for 30 days.