Jak stworzyć i opublikować pakiet NuGet w .NET (C#)

Chcesz przestać kopiować kod między projektami i zacząć budować prawdziwą architekturę w .NET? W tym artykule pokażę Ci krok po kroku, jak stworzyć własny pakiet NuGet w C#, opublikować go na nuget.org i użyć w aplikacji Web API. Na praktycznym przykładzie Result Pattern zobaczysz, jak wygląda profesjonalne podejście do współdzielenia logiki w wielu projektach.

Jak stworzyć własny pakiet NuGet w .NET?

Tworzenie pakietu NuGet to nie jest wiedza „dla wybranych”.
To podstawowa umiejętność każdego programisty C#, który pracuje przy więcej niż jednym projekcie.

Zamiast:

kopiować klasy między repozytoriami
poprawiać te same bugi w 5 miejscach
utrzymywać kilka wersji tej samej logiki

publikujesz pakiet. Raz. Profesjonalnie.

Czym jest NuGet w .NET?

NuGet to system zarządzania pakietami w .NET.

Dzięki niemu możesz:

instalować gotowe biblioteki
zarządzać zależnościami
aktualizować wersje
publikować własne rozwiązania

Pakiet NuGet to plik .nupkg, który zawiera:

skompilowaną bibliotekę DLL
metadane (wersja, autor, opis)
zależności

To po prostu profesjonalnie zapakowana biblioteka do wielokrotnego użycia.

Zobacz też: Tworzenie klas w C#

Krok 1 – Tworzenie biblioteki classlib

Tworzymy nową bibliotekę klas:

dotnet new classlib -n DevHobby.Utils

Pakiety NuGet najczęściej są właśnie bibliotekami typu classlib.

Implementacja Result Pattern w C#

Tworzymy klasę Result:

namespace DevHobby.Utils;

public class Result
{
    public bool IsSuccess { get; }
    public bool IsFailure => !IsSuccess;
    public string Error { get; }

    protected Result(bool isSuccess, string error)
    {
        IsSuccess = isSuccess;
        Error = error;
    }

    public static Result Success() => new(true, string.Empty);

    public static Result Failure(string error) => new(false, error);
}

Dlaczego Result Pattern zamiast wyjątków?

Wyjątki powinny być wyjątkowe. Nie do sterowania logiką biznesową.

Korzyści:

brak try-catch wszędzie
przewidywalny flow
łatwiejsze testowanie
większa kontrola nad logiką

To już nie jest „trik”. To mindset architektoniczny.

Krok 2 – Generowanie pakietu NuGet

Budujemy wersję produkcyjną:

dotnet pack -c Release

W folderze:

bin/Release/

pojawi się plik:

DevHobby.Utils.1.0.0.nupkg

To Twój gotowy pakiet.

Krok 3 – Publikacja pakietu na nuget.org

Zaloguj się na nuget.org
Wygeneruj API Key
Wypchnij pakiet:

dotnet nuget push bin/Release/DevHobby.Utils.1.0.0.nupkg --api-key YOUR_API_KEY --source https://api.nuget.org/v3/index.json

Po chwili pakiet jest publicznie dostępny. To moment, w którym przestajesz być tylko użytkownikiem NuGet. Zaczynasz być twórcą.

Krok 4 – Użycie pakietu w Web API

Tworzymy nową aplikację:

dotnet new webapi -n DevHobby.Demo
cd DevHobby.Demo

Instalujemy pakiet:

dotnet add package DevHobby.Utils

W pliku .csproj zobaczysz:

<ItemGroup>
  <PackageReference Include="DevHobby.Utils" Version="1.0.0" />
</ItemGroup>

Przykładowe użycie w serwisie

public class UserService
{
    private static readonly List<string> _users = new();

    public Result RegisterUser(string email)
    {
        if (string.IsNullOrWhiteSpace(email))
            return Result.Failure("Email nie może być pusty.");

        if (_users.Contains(email))
            return Result.Failure($"Użytkownik {email} już istnieje.");

        _users.Add(email);
        return Result.Success();
    }
}

Teraz tworzymy kontroler UsersController.cs

using Microsoft.AspNetCore.Mvc;
using DevHobby.Utils;

[ApiController]
[Route("api/[controller]")]
public class UsersController : ControllerBase
{
    private readonly UserService _service = new();

    [HttpPost("register")]
    public IActionResult Register([FromBody] string email)
    {
        Result result = _service.RegisterUser(email);

        if (result.IsFailure)
            return BadRequest(result.Error);

        return Ok("Rejestracja zakończona sukcesem!");
    }
}

Zero kopiowania. Zero duplikacji. Jedno źródło prawdy.

Wersjonowanie pakietu NuGet (Semantic Versioning)

Zmiana wersji w .csproj:

Zmiana wersji w .csproj:
<Version>1.1.0</Version>

Zasady SemVer:

1.0.0 – wersja stabilna
1.0.1 – patch (bugfix)
1.1.0 – minor (nowa funkcja)
2.0.0 – major (breaking change)

Pakiet to odpowiedzialność.
Breaking change bez planu = chaos w projektach.

Kiedy warto tworzyć własny pakiet NuGet?

✔ Gdy masz wiele mikroserwisów
✔ Gdy współdzielisz logikę między projektami
✔ Gdy budujesz narzędzia wewnętrzne
✔ Gdy tworzysz open source
✔ Gdy chcesz skalować architekturę

Jeśli masz jeden mały projekt — może to być overkill. Ale jeśli myślisz długoterminowo — to inwestycja.

Checklist – Czy Twój kod powinien być pakietem?

Czy używasz tej samej logiki w 2+ projektach?
Czy aktualizacje tej logiki są powtarzalne?
Czy chcesz mieć jedno centralne źródło wersji?
Czy planujesz skalowanie systemu?

Jeśli zaznaczyłeś 2 lub więcej – czas na NuGet.

Podsumowanie

W tym artykule pokazałem Ci:

jak stworzyć pakiet NuGet w .NET
jak go opublikować
jak użyć w Web API
jak działa wersjonowanie
jak wykorzystać Result Pattern w praktyce

To nie jest trik. To sposób myślenia o systemach.

Jeśli ten artykuł był pomocny:

👉 Zostaw komentarz i napisz, czy publikowałeś już własny pakiet
👉 Udostępnij artykuł programiście, który wciąż kopiuje klasy