NuGet and .NET Core Builds with Artifactory - Declarative Pipeline Syntax

The Artifactory Plugin's integration with the NuGet and .NET Core clients allow build resolve dependencies, deploy artifacts and publish build-info to Artifactory.

To run NuGet / DotNet Core builds with Artifactory from your Pipeline script, you first need to create an Artifactory server instance, as described in the Creating an Artifactory Server Instance section.

The next step is to define an rtNugetResolver or rtDotnetResolver (depending on whether you're using using NuGet or DorNet Core), which defines the dependencies resolution details. Here's an example:

rtNugetResolver (
    id: 'resolver-unique-id',
    serverId: 'Artifactory-1',
    repo: 'libs-nuget'
)

// OR

rtDotnetResolver (
    id: 'resolver-unique-id',
    serverId: 'Artifactory-1',
    repo: 'libs-nuget'
)

As you can see in the example above, the resolver should have a unique ID, so that it can be referenced later in the script, In addition, it includes an Artifactory server ID and the name of the repository.

Now we can use the rtNugetRun or rtDotnetRun closure, to resolve the NuGet dependencies. Notice that the closure references the resolver we defined above.

rtNugetRun (
    resolverId: "resolver-unique-id",
    args: "restore ./Examples.sln",
        // Optional - Jenkins spawns a new java process during this step's execution.
        // You have the option of passing any java args to this new process.
        javaArgs: "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005",
    // Optional - By default, the build uses NuGet API protocol v2. If you'd like to use v3, set it on the build instance as follows.
    apiProtocol: "v3"
    // If the build name and build number are not set here, the current job name and number will be used:
    buildName: 'my-build-name',
    buildNumber: '17',
    // Optional - Only if this build is associated with a project in Artifactory, set the project key as follows.
    project: 'my-project-key'
)

// OR

rtDotnetRun (
    resolverId: "resolver-unique-id",
    args: "restore ./Examples.sln",
        // Jenkins spawns a new java process during this step's execution.
        // You have the option of passing any java args to this new process.
        javaArgs: "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005",
    // Optional - By default, the build uses NuGet API protocol v2. If you'd like to use v3, set it on the build instance as follows.
    apiProtocol: "v3" 
    // If the build name and build number are not set here, the current job name and number will be used:
    buildName: 'my-build-name',
    buildNumber: '17',
    // Optional - Only if this build is associated with a project in Artifactory, set the project key as follows.
    project: 'my-project-key'
)

In most cases, your build also produces artifacts. The artifacts can be NuGet packages, DLL files or any other type of artifact. The artifacts produced can be deployed to Artifactory using the rtUpload closure, as described in the Uploading and Downloading Files section in this article.

The last thing you might want to do, is to publish the build-info for this build. See the Publishing Build Info to Artifactory section for how to do it.

More about build-info: You also have the option of customising the build-info module names. You do this by adding the module property to the rtNugetRun or rtDotnetRun closures as follows:

rtNugetRun (
    resolverId: "resolver-unique-id",
    args: "restore ./Examples.sln",
        module: 'my-custom-build-info-module-name'
)

// OR

rtDotnetRun (
    resolverId: "resolver-unique-id",
    args: "restore ./Examples.sln",
        module: 'my-custom-build-info-module-name'
)