Would love to see a follow up video for recommendations and best practices on how to debug the nuget package from the consuming application locally and how to easily handle hot swapping between the local nuget package and real one from the live nuget server.
Thank you! Excellent tutorial. By the way, for local operations you can use "add" command instead of the push. It was made specifically for adding packages to a non-HTTP package source (a folder or UNC path) in a hierarchical layout.
hello, Steve! I'm a bit stuck with a project and could use your help. So, I have a large project with several web API projects using some of the same class libraries in the same solution. I'm not sure whether to include my code as a project reference or as a NuGet package. Any ideas on the best approach? Thanks a bunch!
If the web api projects are all in the same repo, then use proj references. Can have a single large solution, or multiple solutions for each web api if you'd like (along with the projects that each of them need), and just reference the projects directly.
I agree with @JasonLeBel. Prefer project references if it's all really one solution/application. If you're shipping separate independent apps (or microservices) then nuget packages start to make sense. But they are a lot more friction to update so ideally only shift to packages when they're somewhat stable and not changing multiple times per day.
Great video! Everything you would need to know in under 6 minutes!! Thank you.
You're welcome!
Explained really simply and works. Thanks.
You're welcome!
Would love to see a follow up video for recommendations and best practices on how to debug the nuget package from the consuming application locally and how to easily handle hot swapping between the local nuget package and real one from the live nuget server.
Great suggestion! Do you have any experience to share, yourself?
Thank you! Excellent tutorial. By the way, for local operations you can use "add" command instead of the push. It was made specifically for adding packages to a non-HTTP package source (a folder or UNC path) in a hierarchical layout.
Great tip!
Hey Steve, I did like this video. Do you have to first install a NuGet server locally, to do what you've done here?
It's just a folder. I usually use c:\LocalNuget. No install needed.
Thanks, Jack Burton!
Just remember what ol' Jack Burton does when the earth quakes, and the poison arrows fall from the sky, and the pillars of Heaven shake...
Are these instructions basically the same for .NET Framework 4.x?
Yes, 100%.
hello, Steve! I'm a bit stuck with a project and could use your help. So, I have a large project with several web API projects using some of the same class libraries in the same solution. I'm not sure whether to include my code as a project reference or as a NuGet package. Any ideas on the best approach? Thanks a bunch!
If the web api projects are all in the same repo, then use proj references.
Can have a single large solution, or multiple solutions for each web api if you'd like (along with the projects that each of them need), and just reference the projects directly.
I agree with @JasonLeBel. Prefer project references if it's all really one solution/application. If you're shipping separate independent apps (or microservices) then nuget packages start to make sense. But they are a lot more friction to update so ideally only shift to packages when they're somewhat stable and not changing multiple times per day.
You camera blocked the whole push command
yeah sorry, it's hard to always catch that.
Nope! Any folder will do!
What he said! :)