move msbuild install into a subfolder in CLI

[rohit21agrawal]

Steps to reproduce

1. Install dotnet CLI from https://dotnetcli.blob.core.windows.net/dotnet/Sdk/1.0.0-preview3-003618/dotnet-dev-win-x64.1.0.0-preview3-003618.zip . By installing, i mean extract the downloaded zip into a directory.

2. Run dotnet.exe restore on the attached project

3. Run dotnet.exe build3 to build the project.

4. Run dotnet.exe pack3 to pack - this will trigger a missing method exception.

This is because msbuild.exe loads up the wrong nuget.commands.dll .

NetCoreCsproj.zip

Expected behavior

it should load the nuget.commands.dll from %(UserProfile).nuget\packages\nuget.build.tasks.pack\3.6.0-beta.1.msbuild.10\build\netstandard1.3\nuget.commands.dll

Actual behavior

instead it loads the dll from dotnet-dev-win-x64.1.0.0-preview3-003618\sdk\1.0.0-preview3-003618

This is not critical for preview 5 oob as long as nuget pack3 can work by putting the same dependencies in the sdk and cli.

[livarcocc]

If this is not critical for preview5 OOB, which equates to the CLI preview3, I am moving this to RTM. Let me know if you disagree.

[rohit21agrawal]

can we wait until tomorrow morning? I'll get back with a final answer.

[livarcocc]

Ok, moved it back. Let me know. But what is your ask here for the CLI? You mention msbuild is loading the wrong CLI.

[rohit21agrawal]

basically msbuild.exe should move into a subdirectory and not be placed next to the nuget DLLs under the sdk folder.

[livarcocc]

All right. I got that from the title, but from the description it kind of confused me. So basically, you want to avoid having those dlls there to load tasks from in case your own task depends on a different version of the dll. Is that it?

[rohit21agrawal]

exactly.

[livarcocc]

@rohit21agrawal Do you have a final answer on whether we need this for preview3 or not?

[rohit21agrawal]

@livarcocc sorry i forgot to update this thread - we have a workaround for preview3, so we can move this to RC/RTM milestone.

[rohit21agrawal]

@livarcocc @eerhardt has there been any update on this? We need to get this fixed to make integrations easier, and enable Pack to ship out of band without having to patch the DLLs in the sdk directory.

CC: @rrelyea @emgarten

[rrelyea]

Great. Thanks. Any eta yet? (trying to plan integration dates)

[TheRealPiotrP]

@jonsequitur should start looking at the issue this week. @rrelyea are you blocked? Or this would just make integrations easier?

[rrelyea]

This would make integrations much easier. If we wanted to integrate now, we'd have to do 4+ steps, including disabling tests, and re-enabling them. Instead of just 2 steps otherwise.
We'd love to be able to increase our integration velocity!

[rohit21agrawal]

this also really makes it difficult to get customers to try out latest fixes in pack without doing an insertion in the sdk and cli

[jonsequitur]

For additional context, see dotnet/cli#5012.