Use csproj as pack input instead of nuspec #1119
Conversation
ViktorHofer
force-pushed
the
UsePackTaskInsteadOfNuspec
branch
from
c4c0f00
to
13aebe2
Compare
|
Does the team intend to keep publishing sourcelink NuGet packages for use with older SDKs? |
ViktorHofer
force-pushed
the
UsePackTaskInsteadOfNuspec
branch
from
13aebe2
to
b117671
Compare
I'm not the owner of sourcelink but AFAIK yes and this PR doesn't change that. The .NET 9 source link packages will work on all the officially supported MSBuild flavours and supported runtimes. |
ViktorHofer
force-pushed
the
UsePackTaskInsteadOfNuspec
branch
from
4fb3860
to
b117671
Compare
|
Unfortunately I can't reproduce the failures locally: |
Example of the usage of NetToolMinimum: dotnet/sourcelink#1119
ViktorHofer
force-pushed
the
UsePackTaskInsteadOfNuspec
branch
2 times, most recently
from
c575a10
to
42c31c5
Compare
|
cc @tmat |
|
@davidwengier can you take a look at this? |
src/Microsoft.Build.Tasks.Git/build/Microsoft.Build.Tasks.Git.props
Outdated
Show resolved
Hide resolved
ViktorHofer
force-pushed
the
UsePackTaskInsteadOfNuspec
branch
12 times, most recently
from
a8489fb
to
481ba16
Compare
|
I finally found time to continue to work on this. @tmat, please take a look. I used the same approach that we came up with in arcade for build task projects. Btw, it would be good to switch this repository to Central Package Management with a future change. |
ViktorHofer
force-pushed
the
UsePackTaskInsteadOfNuspec
branch
from
aa1832b
to
90685b6
Compare
Now that sourcelink is a native part of the .NET SDK, Arcade doesn't bring sourcelink packages in anymore. Now that the cyclic package dependency is avoided, these projects don't need to use nuspecs anymore. This removes custom infrastructure and allows better source build controls. I diffed the produced packages and the content in the .NETCoreApp folder is identical (a deps.json file is added but that's recommended by msbuild for build tasks these days). The .NET Framework output is significantly different as it now includes all dependencies that aren't supplied by the MSBuild inside Visual Studio.
ViktorHofer
force-pushed
the
UsePackTaskInsteadOfNuspec
branch
from
90685b6
to
c056a87
Compare
Would you mind listing the differences? |
| @@ -0,0 +1,4 @@ | |||
| <!-- Licensed to the .NET Foundation under one or more agreements. The .NET Foundation licenses this file to you under the MIT license. See the License.txt file in the project root for more information. --> | |||
| <Project> | |||
| <Import Project="..\build\$(MSBuildThisFileName).props"/> | |||
There was a problem hiding this comment.
buildTransitive is necessary so when a package references Microsoft.Build.Tasks.Git.nupkg, the end consumer then receives the msbuild props and targets files from it transitively. That's necessary when using NuGet's Pack task as it emits a slightly different nuspec in regards to IncludeAssets as the current ones.
NuGet/Home#6091 has all the details.
Sure. I will post the nuspec diffs next week. |
| - The consumer of the package also needs Visual Studio 2017 Update 9 debugger. | ||
| - The consumer of the package also needs Visual Studio 2022 or newer. |
There was a problem hiding this comment.
IIRC, neither NuGet restore nor the Visual Studio debugger is able to read symbols from snupkg, but NuGet.org indexes the symbols from uploaded snupkg files and provides them to debuggers via the symbol server protocol. Did nupkg.org change its symbol server so that it no longer works with VS2017? If not, what's the reason of this doc change?
Now that sourcelink is a native part of the .NET SDK, Arcade doesn't bring sourcelink packages in anymore. Now that the cyclic package dependency is avoided, these projects don't need to use nuspecs anymore.
This removes custom infrastructure and hacks, and allows better source build controls.
I diffed the produced packages and the content in the .NETCoreApp folder is identical (a deps.json file is added but that's recommended by msbuild for build tasks these days). The .NET Framework output is significantly different as it now includes all dependencies that aren't supplied by the MSBuild inside Visual Studio.