We have an in-house TFS (Azure DevOps 2019) server and many Visual Studio solutions, some of which reference various 3rd-party DLLs (a dozen at most). These are typically purchased libraries, so don't exist as NuGet packages. We store these DLLs in source control, within the branch alongside the source code.
Storing binaries in source control is generally frowned upon, and we're now considering moving from TFS to Git, where this seems to be even more of an issue. What are my options? Given that these DLLs rarely if ever change, would it really be a problem if they were stored in Git? Some of the files haven't changed in 5+ years.
Just looking for any guidance on how to deal with such dependencies. Could we wrap up the 3rd-party libraries as NuGet packages and store them in our Azure DevOps "repository" instead of source control, or is it not worth the effort?
You have 2 options:
Use git lfs which is used to store binaries as Azure DevOps provide this feature. It often a good idea to setup and configure git lfs in a project to prevent accidental commit of binary files.
Create nuget packages and push them into a custom Nuget feed as it is really easy to create one (in the Artifact part of Azure DevOps). This option is perhaps slightly better if you want to clearly see/manage the versioning of the dependencies.
Both are not too difficult to do. Choose the one that you find better suits your project or that you think is more perennial for your project.