From bcfa7c7df94ad0e29c1d1c7eee8a191aa20aeaa3 Mon Sep 17 00:00:00 2001 From: Daniel Cazzulino Date: Tue, 20 Oct 2020 18:02:14 -0300 Subject: [PATCH 1/3] Add automatic cleanups to improve the inner devloop When working with packages built locally, it's quite common to dogfood those packages from sample projects locally. This can use a fixed package version for the locally produced packages, or auto-incremented versions. Also, the referencing projects might choose to use wildcards when testing local packages too. The caching mechanisms built into NuGet make this process a bit more cumbersome than necessary: if you build a fixed version package, you will never get a newly built version restored in a project elsewhere in the machine because NuGet will believe the one in the cache is already the latest. The HTTP-level cache implemented on top of the package cache also works against you in that case even if you clean that folder. And wildcards don't make things much better unless you clean those caches too. In addition, if you increment package versions when building locally too, the package output path will continuously be filled up with older versions unnecessarily. This commit adds support for automatically fixing all those issues while still causing minimal disruption or performance problems for other packages and projets in your machine, as follows: * The entire cleanup only is in place for packable projects, and in local (non-CI) builds * It can be turned off entirely by setting `EnablePackCleanup=false`. * It cleans the specific package folder in the cache for the current PackageId: nuget creates a subfolder in the package cache dir for each package id, and places all versions inside. By removing just that folder, you effectively clean the cache for that package and no others. * It cleans the HTTP cache too: this cannot be done selectively for a specific package id, and therefore can be turned off by setting `CleanHttpNuGetCacheOnPack=false` if it causes performance issues. In my experience, it doesn't since the HTTP cache is just an optimization for offline scenarios (I think?). I have used this approach for years on multiple projects with multiple packaging approaches and at this point I think it deserves being built-in in nugetizer. --- README.md | 28 +++++++++- src/NuGetizer.Tasks/NuGetizer.Cleanup.targets | 54 +++++++++++++++++++ src/NuGetizer.Tasks/NuGetizer.Shared.targets | 5 ++ src/NuGetizer.Tasks/NuGetizer.props | 14 ++++- 4 files changed, 99 insertions(+), 2 deletions(-) create mode 100644 src/NuGetizer.Tasks/NuGetizer.Cleanup.targets diff --git a/README.md b/README.md index 29f5afd5..2acdd888 100644 --- a/README.md +++ b/README.md @@ -183,7 +183,7 @@ Package: Sample.1.0.0.nupkg Finally, you can focedly turn a project reference build output into a private asset even if it defines a `PackageId` by adding `PrivateAssets=all`. This is very useful for build and analyzer packages, which typically reference the main library project too, but need its output as private, since neither can use dependencies at run-time. -### dotnet-nugetize +## dotnet-nugetize Carefully tweaking your packages until they look exactly the way you want them should not be a tedious and slow process. Even requiring your project to be built between changes can be costly and reduce the speed at which you can iterate on the packaging aspects of the project. Also, generating the final `.nupkg`, opening it in a tool and inspecting its content, is also not ideal for rapid iteration. @@ -198,3 +198,29 @@ After installation, you can just run `nugetize` from the project directory to qu Here's a sample output screenshot: ![nugetize screenshot](img/dotnet-nugetize.png) + +## Inner DevLoop + +Authoring, testing and iterating with your nuget packages should be easy and straightforward. So NuGetizer has built-in support for this process that makes it even enjoyable. The following are some notes and advise on how to make the best of it. + +1. Use single `PackageOutputPath`: if you create multiple packages, it's helpful to place them all in a single output directory. This can be achieved easily by adding the property to a `Directory.Build.props` file and place it at your repository root (or your `src` folder).: + + ```xml + $(MSBuildThisFileDirectory)..\bin + ``` + +2. Use `` in your consuming projects: this allows you to point to that common folder and even do it selectively only if the folder exists (i.e. use local packages if you built them, use regular feed otherwise). You can place this too in a `Directory.Build.props` for all your consuming/sample/test projects to use: + + ```xml + https://api.nuget.org/v3/index.json;$(RestoreSources) + + $([System.IO.Path]::GetFullPath('$(MSBuildThisFileDirectory)..\..\bin'));$(RestoreSources) + + ``` + +3. NuGetizer will automatically perform the following cleanups whenever you build a new version of a package: + a. Clean previous versions of the same package in the package output path + b. Clean NuGet cache folder for the package id (i.e. *%userprofile%\.nuget\packages\mypackage*) + c. Clean the NuGet HTTP cache: this avoids a subsequent restore from a test/sample project from getting an older version from there, in case you build locally the same version of a previously restored one from an HTTP source. + +These cleanups only apply in local builds, never in CI, and you can turn them all off by setting `EnablePackCleanup=false`. \ No newline at end of file diff --git a/src/NuGetizer.Tasks/NuGetizer.Cleanup.targets b/src/NuGetizer.Tasks/NuGetizer.Cleanup.targets new file mode 100644 index 00000000..a0f968d4 --- /dev/null +++ b/src/NuGetizer.Tasks/NuGetizer.Cleanup.targets @@ -0,0 +1,54 @@ + + + + + $(LocalAppData)\NuGet\v3-cache + + true + + $(UserProfile)\.nuget\packages + + + + + <_ExistingPackage Include="$(PackageOutputPath)\$(PackageId)*.nupkg" /> + <_PackageToDelete Include="@(_ExistingPackage)" + Condition="$([System.Text.RegularExpressions.Regex]::IsMatch('%(Filename)', '$(PackageId)\.\d\.\d\.\d.*'))" /> + + + + + + + + + + + $(NuGetCache)\$(PackageId.ToLowerInvariant()) + + + + + + + + + + + + + + diff --git a/src/NuGetizer.Tasks/NuGetizer.Shared.targets b/src/NuGetizer.Tasks/NuGetizer.Shared.targets index 88df9ca4..f825a81e 100644 --- a/src/NuGetizer.Tasks/NuGetizer.Shared.targets +++ b/src/NuGetizer.Tasks/NuGetizer.Shared.targets @@ -18,6 +18,9 @@ Copyright (c) .NET Foundation. All rights reserved. true + + true + true @@ -271,5 +274,7 @@ Copyright (c) .NET Foundation. All rights reserved. + + diff --git a/src/NuGetizer.Tasks/NuGetizer.props b/src/NuGetizer.Tasks/NuGetizer.props index 03526310..ed43497f 100644 --- a/src/NuGetizer.Tasks/NuGetizer.props +++ b/src/NuGetizer.Tasks/NuGetizer.props @@ -25,7 +25,19 @@ Copyright (c) .NET Foundation. All rights reserved. $(MSBuildThisFileDirectory)NuGetizer.PackageMetadata.targets true - + + + false + + true + + From 2d3817cd2bc474eb41e4cb7b2cd905295da0915c Mon Sep 17 00:00:00 2001 From: Daniel Cazzulino Date: Tue, 20 Oct 2020 18:48:36 -0300 Subject: [PATCH 2/3] Use latest sleet which is now required for my CI feed --- .github/workflows/build.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index fe38d259..a19f8aa7 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -34,5 +34,5 @@ jobs: run: msbuild -t:pack -p:nobuild=true -p:versionsuffix=$($env:VERSION_SUFFIX) - name: sleet run: | - dotnet tool install -g --version 2.3.33 sleet + dotnet tool install -g --version 3.2.0 sleet sleet push bin --config none -f --verbose -p "SLEET_FEED_CONTAINER=nuget" -p "SLEET_FEED_CONNECTIONSTRING=${{ secrets.SLEET_CONNECTION }}" -p "SLEET_FEED_TYPE=azure" \ No newline at end of file From d83509f38ef9a069674d440f53b1ddaa4a5507b2 Mon Sep 17 00:00:00 2001 From: Daniel Cazzulino Date: Tue, 20 Oct 2020 19:25:51 -0300 Subject: [PATCH 3/3] Add badges --- README.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/README.md b/README.md index 2acdd888..6545b7db 100644 --- a/README.md +++ b/README.md @@ -3,6 +3,17 @@ Simple, flexible, intuitive and powerful NuGet packaging. +[![Version](https://img.shields.io/nuget/vpre/NuGetizer.svg?color=royalblue)](https://www.nuget.org/packages/NuGetizer) +[![Downloads](https://img.shields.io/nuget/dt/NuGetizer?color=darkmagenta)](https://www.nuget.org/packages/NuGetizer) +[![License](https://img.shields.io/badge/license-Apache%202.0-blue.svg)](https://github.com/kzu/nugetizer/blob/main/LICENSE) +[![Discord Chat](https://img.shields.io/badge/chat-on%20discord-7289DA.svg)](https://discord.gg/AfGsdRa) +[![GitHub](https://img.shields.io/badge/-source-181717.svg?logo=GitHub)](https://github.com/kzu/stunts) + +[![CI Version](https://img.shields.io/endpoint?url=https://shields.kzu.io/vpre/nugetizer/main&label=nuget.ci&color=brightgreen)](https://pkg.kzu.io/index.json) +[![GH CI Status](https://github.com/kzu/nugetizer/workflows/build/badge.svg?branch=main)](https://github.com/kzu/nugetizer/actions?query=branch%3Amain+workflow%3Abuild+) +[![AzDO CI Status](https://dev.azure.com/kzu/oss/_apis/build/status/nugetizer?branchName=main)](http://build.azdo.io/kzu/oss/44) + + # Why The .NET SDK has built-in support for packing. The design of its targets, property