Retire Redgate.ThirdParty.*
Closed this issue · 4 comments
What change would you like to make to the tech radar?
I'd like to add RedGate.ThirdParty.*
to retire
Why do you believe this is valuable to Redgate?
Third party libraries make it much harder for us to keep packages up to date. Each time a third-party library needs an update, we'd have to create a new NuGet package and republish it. This is work we don't need to do.
Examples of this include
- RedGate.ThirdParty.SQLite
- NGit
- Mono - not directly but it seems we reference
RedGate.ThirdParty.Mono.Security
from here.
We sometimes have reasons to do this. Some examples that have been given are:
- Because we've backported something to an older .NET version
- Because we don't want to duplicate WiX fragments
I don't the benefits are worth the cost!
Where should this be on the tech radar?
Retire
If this should be in the Explore ring, who is committed to exploring it?
N/A
I don't the benefits are worth the cost!
I totally agree with this for the examples you've provided, although there are a couple other reasons we do this as well:
- Sometimes the nuget package we want just doesn't exist on nuget.org.
This seems to be true for eg Actipro and most DevExpress packages (Actipro actually recommend creating your own). I don't think there's any alternative to nuget for consuming libraries that we want to use?
For a lot of other packages on our feed, IIRC the nuget package didn't exist whenever we first wanted it (probably many years ago) but has been added since, so we should definitely migrate onto the official packages for those things where possible. - Sometimes we want to add strong-naming to an existing package.
eg CredentialManagement - we could potentially drop these packages and move the strong-name-adding-logic to the relevant product's build scripts, but I'm not sure if that would work for in-VS builds as well since they wouldn't have the strong-named dll available? Might need some more investigation.
It looks like there's something like 150 of these thirdparty
packages on https://red-gate.visualstudio.com/NugetFeed/_packaging?_a=feed&feed=Main , so definitely a big cleanup job for anybody that wants to take that on :)
- Sometimes the nuget package we want just doesn't exist on nuget.org.
Another example of this is SonarScanner
, see https://github.com/red-gate/Versioning/pull/2366 for more details. Maybe in such a situation, our default approach should be to open a PR in the public repo that just adds nuget package creation?
@nyctef Thanks, I think you've demonstrated there are good reasons to do it but maybe this is veering into Coding Guidelines territory as it's not easy to get a blanket statement. I've created an issue at https://github.com/red-gate/CSharpGuidelines/issues/80 and I'll seed it with your comment 😄
This issue is far too general so closing out this discussion and letting the https://github.com/red-gate/CSharpGuidelines/issues/80 do its thing.