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.
Consider moving to the official "centralized package version" support
See original GitHub issueNuGet has had an official way to centrally manage package versions for some time now (https://github.com/NuGet/Home/wiki/Centrally-managing-NuGet-packages, https://docs.microsoft.com/en-us/dotnet/core/compatibility/sdk/5.0/directory-packages-props-imported-by-default, https://github.com/NuGet/Home/wiki/Centrally-managing-NuGet-package-versions).
It does this via a Directory.Packages.props file and has better integration with the IDE and other tooling.
We should look at migrating arcade dependent repositories to using the official tooling shipped alongside the produce where possible, rather than relying on custom solutions. If the official tooling is missing minor support, then we should ensure the relevant tracking issues are filed to enable the scenarios or that our custom needs are built on top where feasible.
Issue Analytics
- State:
- Created a year ago
- Reactions:4
- Comments:29 (29 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
I would prefer that the package versions actually exist in the Directory.Packages.props file though, for the IDE support that may be coming.
It appears that the latest version of dotnet has a nuget version that is high enough for us to try this again. Going to drop this in Operations. We should think of doing it next time we have to upgrade packages