Developer's Local Environment
When managing large solutions with several dependencies, including nuget, 3rd party dll's (DevExpress), etc... it is key to ensure whatever solution is used is not dependent upon a developer's local directory structure.
For example, if the solution is always looking to restore / find / copy some dependencies from:
D:\org-name\dependencies\third-party-1\
Then you will run into issues when the developer does not have a "D" drive, in this case. This may not be the convention for you, but the point is to not lock down dependency resolution to a hard-coded directory.
3rd Party Dependencies
I understand the desire to not want the dll's stored in your git repo. However, when it comes to 3rd party assemblies, relying on their company nuget feed1 or some other external URL will eventually come to bite you in the a** when their server goes offline, or your internet has gone offline. Or worse yet, their service goes out of business.
1 This is a 3rd party nuget feed. Not the official nuget/ms feeds.
The most reliable method of ensuring a project's 3rd party assemblies can be restored is to include them in your repo.
The strategy we used was to include a folder in the root of the solution which contained the current version of the assemblies from the 3rd party. And then reference those assemblies in the project; not from their company's nuget feed (or similar).
Example
\Solution Root
\Binaries (or name it whatever you want)
\DevExpress
- DevExpress.Utils.v16.1.dll
- DevExpress.Utils.v16.1.xml
- etc..
\Another-Third-Party
- foo.dll
- foo.xml
- etc...
\ProjectA
- ProjectA.csproj
\ ProjectB
- {you get the idea...}
- .gitignore
- your-solution.sln
The great thing about this strategy is that you will always have the exact version of the dll's referenced in your solution for the current release. There will never be a need to fetch them from an external server.
A word of caution: this strategy can back-fire if one of your dev's adds another DevExpress assembly through their installer or the DevExpress nuget feed. So your team has to understand that all DevExpress assemblies are always referenced from your \Solution Root\Binaries\DevExpress directory. You will know there is an incorrect reference when your build server blows up (never install DevExpress crap on your build server!)
Nuget Dependencies
Nuget assemblies do not need to be stored in your repo as they are guaranteed to always be available for the version you reference.
However, I would recommend you always add the nuget dependencies being referenced into your repo for every release. This will ensure you will always have them available no matter what may happen.
As far as packages.config vs project.csproj nuget package references, you'll need to work through those on a case-by-case basis, re: the very old nuget convention was to have a packages.config. The current convetion is to reference nuget packages in your .csproj file. What I'd recommend is extracting the references out of packages.config and pulling them into your .csproj files. This may be a bit time-consuming, but you'll end up with a common convention across all projects in the solution.
NPM
NPM is package manager. Nuget is a package manager. Neither will package up commercially purchased packages; they are almost always added through a manual process or the company's nuget feed which requires authorization.
In other words, as you're dealing with commercially purchased dependencies from DevExpress, you're going to have to either use their private nuget feed, or use a strategy similar to what I've outlined above.
Summary
Although not mentioned, you could provision your own private nuget server which maintains all your 3rd party dependencies. However, it is a PITA to keep it up to date. The strategy I outlined above worked really well and was incredibly easy to maintain.
Hopefully, this gets you going in a good direction.
