Decoupling Nuget Packages from .csproj for Docker Optimization
Aight so this is a puzzle I have been noodling on for awhile and I am curious if anyone has come up with an easy to maintain, platform agnostic solution that doesnt add additional onboarding steps for new developers.
Which means:
Right now, nuget packages are tightly coupled to a .csproj file for projects. csproj files also handle a lot of other random stuff like file includes and build steps and whatnot.
When you try and optimize a dockerfile, you typically start things off via these 4 steps:
Except... any modification to the .csproj file itself will still trigger a recache of steps 1-2 as it "dirty"s step 1, since the file's hash has changed.
And turns out, a whole lot of random stuff can cause your .csproj file to change...
So, is there a way you:
Which means:
- It doesnt require a powershell or bash script
- It doesnt require installing of extra software on the machine
- Literally just
docker buildshould be sufficient enough to achieve the desired result
Right now, nuget packages are tightly coupled to a .csproj file for projects. csproj files also handle a lot of other random stuff like file includes and build steps and whatnot.
When you try and optimize a dockerfile, you typically start things off via these 4 steps:
- Copy just the .csproj over
nuget restorethe project to load in nuget packages, which takes a long time usually for large projects- Okay now copy all the rest of the project over
dotnet publishto build the project
Except... any modification to the .csproj file itself will still trigger a recache of steps 1-2 as it "dirty"s step 1, since the file's hash has changed.
And turns out, a whole lot of random stuff can cause your .csproj file to change...
So, is there a way you:
- sanely and easily extract out all the nuget package data to its own file, that only gets changes specifically when nuget packages get changed, uninstalled, added, updated
- Keep the rest of the project intact and a fresh git checkout of the project still can build and run as is with visual studio (if you run it, it will still be able to automatically detect missing packages and install them for local dev)
