Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Allow runtime packs to be resolved from the packs folder
See original GitHub issueFor targeting packs, the SDK first checks if they are in the dotnet packs folder. If they are it uses them from there, otherwise it generates a PackageDownload item so that they will be downloaded to the packages folder as part of NuGet restore.
Currently, we don’t check for runtime packs in the packs folder. This is because we haven’t shipped any with the .NET SDK, as they are only used for self-contained apps and there are many different runtime packs for different RuntimeIdentifiers which represent different OS/architecture combinations.
For .NET 6, iOS and Android apps will need runtime packs, and the set of target RuntimeIdentifiers will be more limited. So they would like to deliver runtime packs as part of their optional SDK workloads.
This means we should update the SDK runtime pack resolution logic to first look in the dotnet packs folder and resolve from there if possible, before generating a PackageDownload item to download the runtime pack if necessary.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:5
- Comments:7 (6 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
/cc @pranavkm
note from workload meeting: This is a rather easy change. At the same time, not having the feature in not end of the world (use library pack with waste disk space). We should pick up this task after –architecture os work,