📦 Include symbols (snupkg's) when creating nuget packages. #1780
Conversation
|
At the moment snupkgs won't be necessary as the pdbs are already shipped in the nupkg. The other changes (deterministic & SourceLink) would be great! I'd be happy to help create PRs once an approach is agreed 🙂 |
@slang25 so why would MS offer the option of creating snupkgs? what is the advantage of having snupkgs vs pdbs, as you've said above? Becuase you're doing something now, that might not be best practice? |
|
I agree regarding best practice, this might be a good time to re-evaluate. What I mean is it's redundant right now to create snupkgs, as they exist as a mechanism to retrieve the pdbs, which are still today being shipping directly in the main package. So they should either be removed from the main package, or we remove snupkgs from this change. Personally, I favor pdbs shipped in the main package as they are today (it's a better acquisition experience IMO, you already have them), however snupkgs are the .NET teams recommendation 🤷 (I'm writing a long blog post to clarify). This is really a choice for the aws sdk team here to decide. |
|
@slang25 Heya Stewart 👋🏻
Did you ever get around to writing this blog post? |
|
We have noticed this issue has not received attention in 1 year. We will close this issue for now. If you think this is in error, please feel free to comment and reopen the issue. |
|
👋 still interested in this addition! |
|
Closing this PR. This is something we would like to do sometime but the work is a lot more involved then just this PR which manually updates a copy of the hundreds of projects we have. There is also lot of work that has to be done to our internal build system. Like I said this is something we would like to do but this is something that we have to track as an epic across all of the affected pieces. |
Description
As discussed in #1777 this PR is one of potentially many to come (not necessarily from me, though).
To help developers debug their applications, if a NuGet package (which is being consumed by the developers project) has Source link enabled, then a developer could optionally "step into" a method that is provided by the 3rd party NuGet package.
So in the case of this AWS .NET Sdk, a developer could step into some of the public methods provided in the AWS SDK NuGet's!
To enable this, I had up update the
.csprojfile for the relevant project which will bedotnet packinto a NuGet package.As of the time of me creating the code changes today, there was 260+ projects in the .NET Standard solution! Egads! That's a lot. As such:
I've only started with the S3 project (in this PR).
the S3 project takes a dependency on the AWS SDK "Core" project, so I've also enabled that.
I'm not planning on enabling Source link for all of the other projects because that's too time consuming (for me) and I don't use 99% of them.
🚀 If this PR is successful, I'll also do 2x more for SNS and SQS (more services I use).
Motivation and Context
Testing
Testing requires
dotnet pack'ing to occur.In the
sdk\services\s3folder, type:dotnet pack -c RELEASE -o C:\temp\Nuget /p:ContinuousIntegrationBuild=true /p:version=100.2.3.4 .\AWSSDK.S3.NetStandard.csproj/p:ContinuousIntegrationBuild=true== deterministic builds, I believe./p:version=100.2.3.4is just me making a version of the NuGet so it is to find in a NuGet package manager or on the hard disk.Before (the current vesrion on NuGet.org):
And after running the
dotnet packcommand:NOTE: similar info should also apply to the
AWSSDK.CoreNuGet package.Types of changes
Checklist
License
I couldn't find any documentation about how this solution/repo handles CI/CD.
As such, I couldn't find where to update the code where/how
dotnet packis ran. THIS STEP IS IMPORTANT and requires a possible modification (as listed above in this readme). Specifically the/p:ContinuousIntegrationBuild=true