search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.61k stars 1.04k forks source link

move msbuild install into a subfolder in CLI #6863

Open rohit21agrawal opened 7 years ago

rohit21agrawal commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

livarcocc commented 7 years ago

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 commented 7 years ago

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

livarcocc commented 7 years ago

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 commented 7 years ago

exactly.

livarcocc commented 7 years ago

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

rohit21agrawal commented 7 years ago

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

rohit21agrawal commented 7 years ago

@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 commented 7 years ago

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

TheRealPiotrP commented 7 years ago

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

rrelyea commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

For additional context, see dotnet/cli#5012.

TheRealPiotrP commented 7 years ago

This has been an onion-peeling exercise I'm afraid. There are a lot of dependencies in CLI components regarding their relative paths to both dotnet.dll and msbuild.dll. We made some great progress today with @jeffkl's help and should have a better estimate tomorrow.

blackdwarf commented 7 years ago

Guys, what is the status of the work?

TheRealPiotrP commented 7 years ago

It's not going to happen for 1.0. The surgery required is quite extensive, both from a CLI perspective as well as from a component composition perspective. There are simply too many cross-dependencies to tease apart this late in the game.

emgarten commented 7 years ago

Is there an ETA on when this might happen? Tools using NuGet libraries are seeing breaks whenever NuGet APIs change in the copy used by the CLI.

eerhardt commented 7 years ago

That's going to happen regardless right? If 2 separate tasks have a dependency on different versions of NuGet, and both NuGet assemblies have the same AssemblyVersion, and there is a breaking change between versions, you will have the same problem.

Do the different NuGet versions have the same AssemblyVersion?

Another thought/option is to not have ABI breaking changes between versions with the same major version.