carlosaortiz (28) [Avatar] Offline
#1
In a last entry I asked this, but I want to ask again because this is something that scratches my head and I don't know where to start.

The nuget concept is something that all platforms have today, a package manager for the .net ecosystem. In java it is managed via Maven or Gradle, in Node with NPM, etc.

It is quite desirable that .NET core book has a section or a chapter devoted to this important part of the piece as all of .NET Core works via nuget packages, besides my concerns are:

1. How to have a local repository.
2. How to create nuget packages with source code.

This is minimun but wonder if other readers have had these concerns.
Dustin Metzgar (23) [Avatar] Offline
#2
I only cover NuGet a little bit in chapter 2. It makes sense as a section or at least an appendix.
carlosaortiz (28) [Avatar] Offline
#3
I guess it will make sense as an Appendix, provided Manning allows you a great space therein. Why I want to see Nuget coverd? Because it is a very new topic for me. In Java I use Maven to package JARS (something like DLLss) and if I want a component in my local repository I just issue a maven command and it is deployed there, no need to a server.

Of course, one would have a centralized server (be it private or public) for these chores, but it is a matter of usage.

In Nuget Arena and now that .NET is cross platform, how do I create my own nuget server, say, in Mac OSX and how to deploy to it and how to create nugets and how to create nugets with source in order to debug.

Hope you give me rest to this thinkings.
458052 (6) [Avatar] Offline
#4
I agree with carlosaoritz that Nuget is worth a more deep overview because there is not much information about the nuget packages creation with the source code
Dustin Metzgar (23) [Avatar] Offline
#5
I'll do a bit of research into it. Originally, I didn't want to cover NuGet packaging because project.json essentially gutted most of the customization and capabilities. It simplified NuGet packages to being a zip file with some metadata. With the MSBuild approach, we may get back the ability to run scripts, modify existing files in a project, etc. Then at least the section would have more than "run 'dotnet package', upload nupkg to feed".
lupestro (7) [Avatar] Offline
#6
One really nice thing is that NuGet is even more integrated into the build than before. Adding a package version to the project becomes a simple one-liner in the csproj - no separate json to keep sync'd. Unlike old csproj's, the new trimmed-down csproj is less of a pain to maintain by hand, quite feasible without Visual Studio. The XML syntax is a bit noisy but it's no longer machine-manageable-only, as it was designed to be before.

The new NuGet 4.x caches at the user level rather than the solution level. For VS2017 .NET Core projects, solution/packages is gone and hence unavailable to put in source control. "Get packages at build time" (whether from server or local cache) has been considered "best practice" anyway, and has been a "done deal" in the client side for a long time - checking in a 2000 directory node_modules area and keeping them up to date is an act of self-flagellation. smilie With decent caching, it just makes sense to load your modules on build and be done with it. Oh, and the new NuGet doesn't seem to get confused about things as readily as the old one did, if at all.

Looking forward to the next installment... While I forge ahead, figuring out how all the new technologies are going to fit into our strategies and plans, what we're going to migrate over and what we're going to leave on its existing track, I've got a team to train up, and it's really useful to have something to hand them to read before we dig into tactics. smilie
Dustin Metzgar (23) [Avatar] Offline
#7
I added a lot more on NuGet packages to the latest chapter "Preparing for Release". Have a look when it goes to MEAP.