Skip to content
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

move msbuild install into a subfolder in CLI #6863

Open
rohit21agrawal opened this issue Sep 20, 2016 · 19 comments
Open

move msbuild install into a subfolder in CLI #6863

rohit21agrawal opened this issue Sep 20, 2016 · 19 comments
Assignees
Milestone

Comments

@rohit21agrawal
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

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

@livarcocc
Copy link
Contributor

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
Copy link
Contributor Author

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

@livarcocc
Copy link
Contributor

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
Copy link
Contributor Author

exactly.

@livarcocc
Copy link
Contributor

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

@rohit21agrawal
Copy link
Contributor Author

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

@rohit21agrawal
Copy link
Contributor Author

@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
Copy link
Contributor

rrelyea commented Dec 14, 2016

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

@TheRealPiotrP
Copy link
Contributor

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

@rrelyea
Copy link
Contributor

rrelyea commented Dec 15, 2016

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
Copy link
Contributor Author

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
Copy link
Contributor

For additional context, see dotnet/cli#5012.

jonsequitur referenced this issue in jonsequitur/cli Dec 28, 2016
@TheRealPiotrP
Copy link
Contributor

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.

jonsequitur referenced this issue in jonsequitur/cli Jan 6, 2017
jonsequitur referenced this issue in jonsequitur/cli Jan 6, 2017
jonsequitur referenced this issue in jonsequitur/cli Jan 11, 2017
jonsequitur referenced this issue in jonsequitur/cli Jan 13, 2017
jonsequitur referenced this issue in jonsequitur/cli Jan 17, 2017
jonsequitur referenced this issue in jonsequitur/cli Jan 18, 2017
jonsequitur referenced this issue in jonsequitur/cli Jan 19, 2017
pending NuGet/Home#4254. Without this, we have no way to create a NuGet package that doesn't contain a package reference to Microsoft.DotNet.Cli.Utils, preventing a proper repro of https://github.com/dotnet/cli/issues/4214.
jonsequitur referenced this issue in jonsequitur/cli Jan 19, 2017
pending NuGet/Home#4254. Without this, we have no way to create a NuGet package that doesn't contain a package reference to Microsoft.DotNet.Cli.Utils, preventing a proper repro of https://github.com/dotnet/cli/issues/4214.
@blackdwarf
Copy link

Guys, what is the status of the work?

@TheRealPiotrP
Copy link
Contributor

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
Copy link
Member

emgarten commented Jun 9, 2017

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
Copy link
Member

eerhardt commented Jun 9, 2017

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.

@msftgits msftgits transferred this issue from dotnet/cli Jan 31, 2020
@msftgits msftgits added this to the Backlog milestone Jan 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants