{"id":56371,"date":"2025-04-30T10:05:00","date_gmt":"2025-04-30T17:05:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=56371"},"modified":"2025-04-30T10:05:00","modified_gmt":"2025-04-30T17:05:00","slug":"dotnet-maui-libraries-github-actions","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/dotnet-maui-libraries-github-actions\/","title":{"rendered":"Packaging and Publishing a .NET MAUI Library with GitHub Actions"},"content":{"rendered":"

This is a continuation of the blog Getting Started with DevOps and .NET MAUI<\/a> showcasing how to build a .NET MAUI Library using DevOps. This blog uses a sample project made Mike Parker<\/a> that shows how to use MSBuild files in NuGet packages. In this blog, the focus is on the GitHub Actions workflow to automate the building, packaging, and publishing of the sample .NET MAUI Library<\/a>.<\/p>\n

Overall Workflow Overview<\/h2>\n

The build_publish_nuget.yml<\/code><\/a> defines the end-to-end workflow for building and publishing the .NET MAUI Library NuGet Package. The versioning step<\/a> handles versioning of the NuGet package for every build via GitHub Actions. The workflow consists of two main jobs: buildLibrary<\/code> and publish<\/code>. These jobs use dotnet<\/code> commands to build and pack the .NET project. The publish<\/code> job depends on the buildLibrary<\/code> job completing successfully. Once you have created the NuGet package, we can push it to nuget.org<\/a> (or an Azure DevOps Internal Feed).<\/p>\n

\"<\/p>\n

Versioning of the NuGet Package<\/h2>\n

The versioning of the NuGet package is handled dynamically within the GitHub Actions workflow. The version is composed of the major version and the GitHub run ID, ensuring a unique version number for each workflow run.<\/p>\n

Setting the Version<\/h3>\n

In the buildLibrary<\/code> job, the VERSION<\/code> variable is set using the MAJORVERSION<\/code> environment variable and the GITHUB_RUN_ID<\/code>:<\/p>\n

- name: Set VERSION variable from tag\n  run: |\n    echo \"VERSION=$MAJORVERSION-$GITHUB_RUN_ID\" >> $GITHUB_ENV<\/code><\/pre>\n
This results in a version format like 1.0.0-1234<\/code>, where 1.0.0<\/code> is the major version and 1234<\/code> is the GitHub run ID.<\/p>\n
Using the Version<\/h3>\n
The VERSION<\/code> variable is then used in the dotnet pack<\/code> command to set the package version:<\/p>\n
- name: Pack Library\n  run: |\n    dotnet pack <PATH TO PROJECT> -p:PackageVersion=$VERSION -c Release<\/code><\/pre>\n
This ensures that each NuGet package, built by the workflow, has a unique version preventing conflicts and making it easy to track and manage different builds.<\/p>\n
Secure and Sign NuGet Package<\/h2>\n
A signed package allows for content integrity verification checks which provides protection against content tampering. The package signature also serves as the single source of truth about the actual origin of the package and help prove package authenticity for the consumer.<\/p>\n
The NuGet Documentation provides detailed steps on how to sign the package<\/a> along with how to get a signing certificate. To implement this step in the workflow, update the Pack Library step:<\/p>\n
- name: Pack Library\n  run: |\n    dotnet pack <PATH TO PROJECT> -p:PackageVersion=$VERSION -c Release\n    dotnet nuget sign MyPackage.nupkg --certificate-path <PathToTheCertificate> --timestamper <TimestampServiceURL>\n<\/code><\/pre>\n
The certificate can be added to GitHub Actions by following the deployment documentation<\/a>.<\/p>\n
Pushing to NuGet.org or Azure DevOps Internal Feed<\/h2>\n
The workflow sample shows how to create a GitHub Release and push to GitHub Actions artifacts as a basic use case. The workflow also includes steps for pushing the NuGet package to NuGet.org or Azure DevOps internal feed as well, based on your use case. Let’s look at how these steps can be customized to different use cases.<\/p>\n
Pushing to NuGet.org<\/h3>\n
To push the package to NuGet.org, use the following steps in the publish<\/code> job and add your NuGet API key:<\/p>\n
- name: Push nuget to NuGet.org\n  run: |\n    dotnet nuget push <your_package_name>.nupkg -k ${{ secrets.NUGET_API_KEY }} -s https:\/\/api.nuget.org\/v3\/index.json --skip-duplicate<\/code><\/pre>\n
You can obtain the API key from your NuGet.org account<\/a>. Make sure to set the NUGET_API_KEY<\/code> secret variable in your GitHub repository’s secrets. The publish with nuget push<\/a> documentation explains the other overrides available and provides troubleshooting steps for errors.<\/p>\n
Pushing to Azure DevOps Internal Feed<\/h3>\n
To push the package to an Azure DevOps internal feed, use the following steps in the publish<\/code> job and configure the feed URL and API key:<\/p>\n
\n- name: Setup .NET Core\n  uses: actions\/setup-dotnet@v1\n  with:\n    dotnet-version: ${{ env.DOTNETVERSION }}\n    source-url: ${{ env.AZURE_ARTIFACTS_FEED_URL }}\n  env:\n    NUGET_AUTH_TOKEN: ${{ secrets.AZURE_DEVOPS_TOKEN }} \n\n- name: Push nuget to Azure DevOps Internal Feed\n  run: |\n    dotnet nuget push --api-key AzureArtifacts -s <your_package_name>.nupkg\n<\/code><\/pre>\n
Replace <AZURE_ARTIFACTS_FEED_URL><\/code> with the URL of your Azure Artifacts feed. Make sure to set the AZURE_DEVOPS_TOKEN<\/code> secret variable in your GitHub repository’s secrets. The Azure Artifacts Documentation<\/a> explains the how to get the AZURE_DEVOPS_TOKEN<\/code> in detail.<\/p>\n
Storing and Using Secret Values in GitHub Actions<\/h2>\n
To securely store and use sensitive information, such as API keys and tokens, in your GitHub Actions workflows you can use GitHub Secrets<\/a>. Follow these steps to store and access secret values:<\/p>\n
    \n
  1. Navigate to your repository on GitHub and click on the “Settings”<\/strong> tab.<\/li>\n
  2. In the left sidebar, click on “Secrets and variables”<\/strong>, then click on “Actions”<\/strong>.<\/li>\n
  3. Click the “New repository secret”<\/strong> button and add a new secret:\n