Cannot select new .slnx solution file for NuGet installer step

Hi,

When trying to change the solution file in the step configuration I get an error message that only .sln files are allowed.

This error occurs because the NuGet Installer build step currently only supports solution files with the .sln extension. You can find more details in the official documentation: Nuget installer.

Path to solution file Specify the path to your solution file (.sln) where packages are to be installed.

If possible, we recommend using the .NET runner (dotnet restore) instead of the NuGet Installer runner, as it provides broader support for different project types. 

For the TeamCity .NET runner, it simply wraps the dotnet command and displays the output in the UI. According to the documentation, SLNX is supported starting from .NET SDK version 9.0.200.

Therefore, as long as .NET SDK 9.0.200 or later is installed on the build agent, it should be supported.

Switching to dotnet restore worked for me. Thank you for the quick reply.

Hi,

nuget.exe supports the SLNX format since 7.0 (released alongside .NET 10). Is there any way to bypass this arbitrary extension validation?

We can't use dotnet restore as it only works with .NET projects, and we recently started migrating our C++ code-base to SLNX.

We have managed to get the NuGet Installer build step to take SLNX files by using a parameter in the “Path to solution file” field, but it feels like a hacky way of doing things.

We'd appreciate if it was supported as is.

Thanks.

It is recommended to switch to the .NET build runner and use the restore command, as Tom suggested above. This should be considered the preferred path for future projects. The .NET runner contains the same functionality, and more. 

However, if you would really like to use the NuGet Install build runner, it is possible to bypass the extension check by passing the SLNX file as a Build Configuration Parameter, as you've already discovered. Alternatively, you could also run the whole command from a Command Line build runner. 

If you're using the <PackageReference> in the .vcxproj format, I believe dotnet restore calls MSBuild's restore target, which works for any project type that uses <PackageReference>. So, I would expect this should restore cleanly. Is that not the case for you?

Hi Eric and thanks for your response.

We're not using PackageReference for our .vcxproj projects, as it doesn't work well with C++ projects. That's why the NuGet Install build runner is needed. We didn't try using the command line as you propose, but will TeamCity automatically inject the built-in NuGet server's credentials in that case? We have a bunch of NuGet packages published internally.

Anyway, we're fine using a build parameter as long as it remains supported. Thanks!

Yes, the credentials should work with the Command Line runner. TeamCity injects the NuGet credential provider at the build level via environment variables (NUGET_PLUGIN_PATHS, and the newer NUGET_NETCORE_PLUGIN_PATHS / NUGET_NETFX_PLUGIN_PATHS). I expect any runner will use them, including the Command Line runner. So as long as nuget.exe honors the standard credential provider plugin protocol, it picks up the TeamCity provided credentials regardless of which runner invoked it.

For the built-in TeamCity NuGet feed specifically, authentication is automatic. You don't even need the NuGet Feed Credentials build feature configured. TeamCity handles those credentials directly.

The parameter workaround in the NuGet Installer step is fine to keep using. It's not officially supported, but I would expect it would continue working. It's certainly an easy workaround for now.