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

CLI should support building a VS solution that includes non .NET Core projects #5504

Open
dazhao-msft opened this Issue Jan 28, 2017 · 8 comments

Comments

Projects
None yet
6 participants
@dazhao-msft

dazhao-msft commented Jan 28, 2017

If a VS solution contains both .NET Core projects and non .NET Core projects, CLI commands such as 'dotnet restore', 'dotnet publish' won't work against the solution, since the CLI doesn't have necessary MSBuild targets to build those non .NET Core projects.

CLI should be able to detect which projects are .NET Core and only execute commands against them . We can keep the current behavior as default and introduce a new flag the enable this 'partial build' behavior.

@TheRealPiotrP TheRealPiotrP added this to the 2.0.0 milestone Jan 30, 2017

@TheRealPiotrP

This comment has been minimized.

Contributor

TheRealPiotrP commented Jan 30, 2017

@dazhao-msft yea, we really wanted to do something with this for 1.0.0 but there wasn't enough time. In the future we'd actually like to allow the Windows CLI to carry a copy of Desktop MSBuild + targets to fully light up this scenario. Moving to 2.0.0, for now, however.

@JamesNK

This comment has been minimized.

Member

JamesNK commented Feb 11, 2017

This is useful for me. With project.json I could compile PCL and net20 assemblies from dotnet CLI. Now my build script requires VS2017 to be installed so I can use its msbuild to restore/build/pack my csproj. And I have the additional challenge to file the path to VS2017's msbuild. Very annoying compared to just using the CLI.

@JamesNK

This comment has been minimized.

Member

JamesNK commented Mar 16, 2017

When is 2.0 expected to be out? This feature is the one thing blocking me from adopting dotnet cli completely with Newtonsoft.Json.

@eerhardt

This comment has been minimized.

Member

eerhardt commented Mar 30, 2017

@JamesNK - which type of projects are blocking you from adopting dotnet cli completely? Is it only Docker? Or is it a different type of SDK that isn't available?

@JamesNK

This comment has been minimized.

Member

JamesNK commented Mar 30, 2017

I have Portable class library targets I want to compile on my build server with CLI. Right now they aren't supported.

@JamesNK

This comment has been minimized.

Member

JamesNK commented Apr 2, 2017

More info:

I want to be able to compile all of this project with CLI - https://github.com/JamesNK/Newtonsoft.Json/blob/aa5f28c09732db5fb3e316433547ea7cdecd8804/Src/Newtonsoft.Json/Newtonsoft.Json.Roslyn.csproj

Today I have to set DotnetOnly to true when compiling with CLI to avoid errors when building PCL targets.

<TargetFrameworks Condition="'$(DotnetOnly)'==''">net45;net40;net35;net20;netstandard1.0;netstandard1.3;portable-net45+win8+wpa81+wp8;portable-net40+win8+wpa81+wp8+sl5</TargetFrameworks>
<TargetFrameworks Condition="'$(DotnetOnly)'=='true'">netstandard1.0;netstandard1.3</TargetFrameworks>

But not compiling everything means I can't use new CLI features like building a NuGet package from a csproj.

@onovotny

This comment has been minimized.

Member

onovotny commented Apr 2, 2017

Somehow I doubt the old portable targets and reference assemblies will ever make it into the SDK builds, at least not until there's an acquisition story around SDK's that aren't in-box.

@onovotny

This comment has been minimized.

Member

onovotny commented Apr 2, 2017

And your build server can do it all, including build a nupkg, but you need VS 2017 installed on it (possibly just the VS 2017 build tools, but haven't checked what's in them...)

Then just run msbuild /t:restore Newtonsoft.Json.Roslyn.csproj, msbuild /t:pack Newtonsoft.Json.Roslyn.csproj and it'll restore, build and pack it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment