CODEWITHSUNDEEP
nugetteamcity
Uli
Uli

Reputation: 1675

How do I use "\\company\network\share\" as a NuGet source in TeamCity?

I've checked that the TeamCity user has access to the network share in question.

All packages from the public NuGet feed are found correctly while packages available on the network share are not.

We use the network share when building via Visual Studio with the exact same path without a problem.

I've tried using "file://ratchet/NuGetRepository" but that doesn't make a difference.

TeamCity log entries and screenshot of the build step configuration shown below:

NuGet command: E:\BuildAgent01\plugins\nuget-agent\bin\JetBrains.TeamCity.NuGetRunner.exe E:\BuildAgent01\tools\NuGet.CommandLine.DEFAULT.nupkg\tools\NuGet.exe restore E:\BuildAgent01\work\95323b7041b60513\MySolution.sln -Source https://nuget.org/api/v2/ -Source \\ratchet\NuGetRepository\

NuGet installer build step configuration.

Upvotes: 4

Views: 2673

Answers (3)

Nicholas Miller
Nicholas Miller

Reputation: 4390

Since the accepted answer did not provide a solution for my setup, I'd like to post what did allow TeamCity to access my network share.

First, a very important note: TeamCity Build Agent may either run as a Windows service or directly in command prompt. For my machine, this had the following consequences:

  1. When run as a Windows service, the build agent was logged in as LocalSystem. For our network share, my machine's credentials were not given permissions.

    Note: while this SO thread indicates that the network share can be configured to allow the machine's LocalSystem account to have permission, this was NOT an option for me.
  2. When run in command prompt, the build agent will use the security context of whoever runs it (for me, it was my domain user). Again, for our network share, all domain users are given permissions.

The quick solution was to simply run the build agent in command prompt and call it a day; however, I did really want to run the build agent as a Windows service, since I think it is a cleaner approach.

Here's my solution:

First, I needed to grant my domain user the privilege to log on as a service. This is needed to run the service with my domain user's security context. I navigated to User Rights Assignment within Local Security Policy:

Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment

Next, I added my domain user to the Log on as a servcie setting. For this, I made sure to include the domain with my user name.

enter image description here

Now that my domain user's security context can be used when starting a service, I navigated to Services (services.msc), located TeamCity Build Agent, and edit its properties:

enter image description here

Now, when relaunching the TeamCity Build Agent Windows service, it would be able to access the network share since it was using the security context of my domain user. I can now access the Nuget repository on our shared drive and keep the build agent running in the background.

Upvotes: 1

Ufuk Hacıoğulları
Ufuk Hacıoğulları

Reputation: 38468

You can include the package sources in NuGet.targets file. Just find the commented lines and add your path.

<PackageSource Include="https://nuget.org/api/v2/" />
<PackageSource Include="\\ratchet\NuGetRepository\" />

Upvotes: 0

Uli
Uli

Reputation: 1675

Was able to solve this by specifying the fully qualified name of the network share, e.g. \\ratchet.hq.local\NuGetRepository.

Upvotes: 1

Related Questions