-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
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. |
can we wait until tomorrow morning? I'll get back with a final answer. |
Ok, moved it back. Let me know. But what is your ask here for the CLI? You mention msbuild is loading the wrong CLI. |
basically msbuild.exe should move into a subdirectory and not be placed next to the nuget DLLs under the sdk folder. |
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? |
exactly. |
@rohit21agrawal Do you have a final answer on whether we need this for preview3 or not? |
@livarcocc sorry i forgot to update this thread - we have a workaround for preview3, so we can move this to RC/RTM milestone. |
@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. |
Great. Thanks. Any eta yet? (trying to plan integration dates) |
@jonsequitur should start looking at the issue this week. @rrelyea are you blocked? Or this would just make integrations easier? |
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. |
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 |
For additional context, see dotnet/cli#5012. |
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. |
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.
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.
Guys, what is the status of the work? |
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. |
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. |
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. |
Steps to reproduce
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.
Run dotnet.exe restore on the attached project
Run dotnet.exe build3 to build the project.
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.
The text was updated successfully, but these errors were encountered: