TeamCity Professional 2019.1.2 (build 66342)
NuGet.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="globalPackagesFolder" value=".\packages" />
</config>
<packageSources>
<add key="TFS" value="https://tfs.mydomain.com/nuget/nuget" />
</packageSources>
</configuration>
I have a .NET CLI (dotnet) restore build step including Build Feature NuGet feed credentials
The corresponding command works fine when run from local shell :
> "C:\Program Files\dotnet\dotnet.exe" restore MySolution.sln
> --packages \\packages --source https://tfs.mydomain.com/nuget/nuget --runtime win-x64 --configfile NuGet.config
But TeamCity job run on agent fails with 401 unauthorized :
[15:30:52][restore] C:\Program Files\dotnet\sdk\2.2.101\NuGet.targets(114,5): error : Failed to retrieve information about 'Dapper' from remote source 'https://tfs.mydomain.com/nuget/nuget/FindPackagesById()?id='Dapper'&semVerLevel=2.0.0'.
[15:30:52][restore] C:\Program Files\dotnet\sdk\2.2.101\NuGet.targets(114,5): error : Response status code does not indicate success: 401 (Unauthorized).
I assume shell dotnet restore uses my Windows login creds - exactly what's specified in my Build Feature NuGet feed credentials
Note that I can successfully use same creds in VisualStudio to Manage NuGet Packages ( restore packages on build ).
Try to use the key of the source (TFS) and not the url itself.
Like this;
"C:\Program Files\dotnet\dotnet.exe" restore MySolution.sln --packages \\packages --source tfs --runtime win-x64 --configfile NuGet.config
If that doesn't work, try to add your user credentials manually
nuget sources add -name foo.bar -source C:\NuGet\local -username foo -password bar -StorePasswordInClearText -configfile %AppData%\NuGet\my.config
Related
I am trying to build on TFS an API which contains several projects in dotnet.core3.1
When I run the dotnet build Api.sln command on TFS here is the result
[error] Dotnet command failed with non-zero exit code on the following projects: D: \ TFS \ Agent01 \ _work \ 18 \ s \ PMTApi.sln
Context:
TFS 2017
Dotnet Core 3.1 projects
Source code management on TFS git
Agents unable to connect to the outside (internet)
The dependency imports are done from a private server thanks to the NuGet.Config file set up to redirect the dependency imports not on the https://api.nuget.org/v3/index.json server but well on that of our private company.
Explanation:
On the TFS git source manager, the PMTApi.sln project contains 7 .csproj files
But in the PMTApi.sln file there are only 4 .csproj which are included
Local result:
Is good dotnet build completes the 5 successful projects.
Result on TFS:
Not good.
[error] Dotnet command failed with non-zero exit code on the following projects: D: \ TFS \ Agent01 \ _work \ 18 \ s \ PMTApi.sln
Observation:
I have the impression that TFS is based on all the .csproj files from the TFS git source manager and not from PMTApi.sln
Conclusion the projects which are not referenced in PMTApi.sln still try to restore the dependencies which causes the top error.
Test:
I tried to exclude these 3 .csproj projects in my NuGet.Config file like this, but it doesn't work
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="XXX NuGet Packages" value="http://privateServer/nuget" />
</packageSources>
<ItemGroup>
<ProjectReference Exclude="..\folderName1\projectName1.csproj" />
<ProjectReference Exclude="..\folderName2\projectName2.csproj" />
<ProjectReference Exclude="..\folderName3\projectName3.csproj" />
</ItemGroup>
</configuration>
Do you have any ideas for a successful dotnet build task?
The construction:
TFS Return:
Local configuration:
1- here you have to right click on the solution
2- manage package Nuget for solution
3- add the url of your private server
4- and uncheck the server of api.NuGet.org
for my case I also uncheck the visual studio packages
You should specify the csproj file(s) to use in the Project(s) argument, not sln file. Check the description of this argument:
The path to the csproj file(s) to use. You can use wildcards (e.g.
**/*.csproj for all .csproj files in all subfolders). This field follows glob pattern, and is run against root of the repository at all
times irrespective of Working Directory.
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops
I am trying to use .NET Core + Ionide + VS Code + Fake + Paket on macOS High Sierra.
Using the project generator, I have created a Suave application called Test. Ionide seems to have generated the appropriate files. After tweaking the TargetFramework to .NET Core, I can build successfully:
$ ./build.sh
...
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:03.72
Finished Target: Build
---------------------------------------------------------------------
Build Time Report
---------------------------------------------------------------------
Target Duration
------ --------
Clean 00:00:00.0026904
InstallDotNetCLI 00:00:01.2292511
Restore 00:00:04.2731055
Build 00:00:07.1234434
Total: 00:00:12.7035334
---------------------------------------------------------------------
Status: Ok
---------------------------------------------------------------------
There are now some files in Test/bin, but none of them are .exe, which is what I would expect as output from fsharpc.
Where does Ionide + Fake put the output executable?
My project has OutputType executable:
<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Compile Include="Test.fs" />
</ItemGroup>
<Import Project="..\.paket\Paket.Restore.targets" />
</Project>
.Net Core compiles all projects (even executable applications) to .dll not .exe that can be run with dotnet PATH_TO_DLL. In the bin folder, in the subfolder for given framework target there should be file YOUR_PROJECT_NAME.dll that can be run with dotnet CLI.
To generate an exe you need to supply a run-time identifier. You can include this in the fsproj with
<PropertyGroup>
<RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>
</PropertyGroup>
but you don't need to do that. You can use VSCode's tasks.json file to set up a build task.
My suggestion is just to run the dotnet CLI:
dotnet build -c Release -r win10-x64
This will create an exe in the bin\release\netcoreapp2.0\win10-x64 folder. You can also dotnet publish if you want a self-contained directory to deploy (this can get large). The id for OSX will be something like osx-x64.
By default ionide generates an fsproj file that is targetting net461, and you might also need Fake 5 for dotnetcore. I also suggest you use paket in magic-mode, and commit the .exe to github (if you use git).
Update. With Matt Ward's help I traced this to a bad config file. The following ~/.config/NuGet/NuGet.Config works for me
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://www.nuget.org/api/v2/" protocolVersion="2" />
</packageSources>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
</configuration>
I can do the following without any problems:
/opt/mono/mono-5.2.0.196-tarball/bin/mono ~/nuget.exe install -version 2.6.4 nunit
However, when I try to compile fsharp under the same installation of Mono, I get the following error. This is in the fsharp4 branch. What might I be doing wrong, please? Many thanks.
Project "/dir/src/fsharp/FSharp.Build-proto/FSharp.Build-proto.fsproj"
(default target(s)): Target CallFsSrGen: Created directory
"obj/proto/./" Tool
/dir/src/fsharp/FSharp.Build-proto/../../../lib/bootstrap/4.0/fssrgen.exe
execution started with arguments:
/dir/src/fsharp/FSharp.Build/FSBuild.txt obj/proto/./FSBuild.fs
FSBuild.resx Target BeforeBuild: Executing: mono
--runtime=v4.0.30319 /dir/src/fsharp/FSharp.Build-proto/../../../.nuget/NuGet.exe restore
packages.config -PackagesDirectory packages Unable to find version
'2.6.4' of package 'NUnit'. Unable to find version '2.6.4' of
package 'NUnit.Runners'. /dir/src/FSharpSource.targets: error :
Command 'mono --runtime=v4.0.30319
/dir/src/fsharp/FSharp.Build-proto/../../../.nuget/NuGet.exe restore
packages.config -PackagesDirectory packages' exited with code: 1.
Task "Exec" execution -- FAILED Done building target "BeforeBuild"
in project
Check what version of NuGet you are using and what NuGet package sources are enabled. Either there no NuGet package sources enabled or you are using a NuGet v2 .exe with a NuGet v3 package source.
If there is no NuGet.Config file that is provided with the FSharp build source code you are using then check the package sources listed in the file ~/.config/NuGet/NuGet.config. I suspect that it only has the v3 package source https://api.nuget.org/v3/index.json which cannot be used with a NuGet.exe (v2). So you would either need to update the nuget.exe to a later version or add the NuGet v2 package source into your NuGet.Config file: https://www.nuget.org/api/v2/
I am running .NET Core 1.1.0 on Ubuntu 14.04, with the goal of hosting my Web APIs in Docker on Ubuntu. I want to build my packages on Ubuntu, but some of the NuGet references are hosted on an internal NuGet repository (Artifactory). This works fine in VS2015 on Windows after I add the package source, but when I run:
dotnet restore
on Ubuntu, the packages hosted on the public NuGet repo download fine, but those on Artifactory fail:
error: Unable to resolve 'Mercury.BaseModel (>= 1.1.0)' for '.NETCoreApp,Version=v1.1'.
I found a NuGet config file at \home\<user>\.nuget\NuGet\NuGet.Config and added the Artifactory repository as follows:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
<add key="Artifactory-DEV" value="https://theluggage-agct.gray.net/artifactory/api/nuget/nuget-institutional-development-local" protocolVersion="3"/>
</packageSources>
</configuration>
but I am still getting the same error.
NuGet itself does not work after installing the .NET Core SDK, I am using dotnet restore as mentioned - is there similar config I must edit for the dotnet CLI (which must be using NuGet?) or is there something else I need to do?
Thanks!
Dotnet CLI restore can take -s as source feed url, so if you have Artifactory with Remote repository to nuget.org.
dotnet restore -s https://artifactory.example.com/api/nuget/nuget.org
Reference :
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-restore?tabs=netcore2x
https://www.jfrog.com/confluence/display/RTF/NuGet+Repositories
After all that I quickly identified 2 problems I had missed:
I had used sudo -i to run as root attempting to resolve the problem, as as a result the NuGet config I setup in my \home folder was not being picked up.
Moving back to my own logon, I then got an error:
error: Unable to load the service index for source https://theluggage-agct.gray.net/artifactory/api/nuget/nuget-institutional-development-local.
error: The content at 'https://theluggage-agct.gray.net/artifactory/api/nuget/nuget-institutional-development-local' is not a valid JSON object.
error: Unexpected character encountered while parsing value: <. Path '', line 0, position 0.
Turns out that our Artifactory NuGet repo returns XML which is NuGet v2 compliant. I changed the config file to set the repo as v2 and it is now working. So, from above, edit the file at
\home\<user>\.nuget\NuGet\NuGet.Config
adding your new repo URL, and get the version setting right:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
<add key="Artifactory-DEV" value="https://theluggage-agct.gray.net/artifactory/api/nuget/nuget-institutional-development-local" protocolVersion="2"/>
</packageSources>
</configuration>
I've got TFS doing some continuous integration builds. Today, it broke for one solution. It seems it can't find AutoMapper. All the other packages can be found just fine.
A couple relevant points:
None of the packages are in source control, we're letting TFS restore them.
We have an internal NuGet feed, but it doesn't seem to be a problem in other solutions, and in this solution we are still getting Entity Framework to restore - just not AutoMapper.
I tried removing and re-adding the NuGet Packages. No luck.
If I use Remote Desktop to connect to the build server and open the project in Visual Studio there, it restores the packages and builds fine.
I can build manually by executing D:\"Program Files"\"Microsoft Team Foundation Server 12.0"\Tools\Nuget.exe restore followed by msbuild MySolutoin.sln
Our TFS server is installed on our D:\ drive.
This is from the TFS Logs:
D:\Program Files\Microsoft Team Foundation Server 12.0\Tools\nuget.exe restore "C:\Builds\1\MyCompany Web\FclQuoteWcfService\src\FclQuoteWcfService.sln" -NonInteractive
Installing 'EntityFramework 6.1.3'.
Installing 'InternalPackage 1.0'.
Successfully installed 'InternalPackage 1.0'.
Successfully installed 'EntityFramework 6.1.3'.
Unable to find version '3.3.1' of package 'AutoMapper'.
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe /nologo /noconsolelogger "C:\Builds\1\MyCompany Web\FclQuoteWcfService\src\FclQuoteWcfService.sln" /nr:False /fl /flp:"logfile=C:\Builds\1\MyCompany Web\FclQuoteWcfService\src\FclQuoteWcfService.log;encoding=Unicode;verbosity=normal" /p:SkipInvalidConfigurations=true /m /p:OutDir="C:\Builds\1\MyCompany Web\FclQuoteWcfService\bin\\" /p:VCBuildOverride="C:\Builds\1\MyCompany Web\FclQuoteWcfService\src\FclQuoteWcfService.sln.vsprops" /dl:WorkflowCentralLogger,"D:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;BuildUri=vstfs:///Build/Build/230;IgnoreDuplicateProjects=False;InformationNodeId=12;TargetsNotLogged=GetNativeManifest,GetCopyToOutputDirectoryItems,GetTargetPath;TFSUrl=http://ctidev2k8:8080/tfs/MyCompany;"*WorkflowForwardingLogger,"D:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;" /p:BuildId="9aa9f8af-c9b9-4d0a-ba06-7cc959231d8e,vstfs:///Build/Build/230" /p:BuildLabel="FclQuoteWcfService_20150330.2" /p:BuildTimestamp="Mon, 30 Mar 2015 20:40:07 GMT" /p:BuildSourceVersion="LFclQuoteWcfService_20150330.2#$/MyCompany Web" /p:BuildDefinition="FclQuoteWcfService"
Exception Message: MSBuild error 1 has ended this build. You can find more specific information about the cause of this error in above messages. (type BuildProcessTerminateException) Exception Stack Trace: at System.Activities.Statements.Throw.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
I've seen this too. It seems to be triggered as soon as NuGet package restore switches to the internal feed. Once it does this is doesn't switch back to the official nuget.org feed and continues to look for the packages on the internal feed.
Ensure both package sources are added to your NuGet.config file. Also ensure both sources are 'active'.
<configuration>
<packageSources>
<add key="nuget.org"
value="https://www.nuget.org/api/v2/" />
<add key="example.com"
value="http://example.com/feed/nuget/" />
</packageSources>
<activePackageSource>
<add key="All"
value="(Aggregate source)" />
</activePackageSource>
</configuration>
See NuGet configuration file documentation.
Matt's answer put me on the right track but we don't use an internal feed so I had to do some more digging. This answer works, at least, for a project created in Visual Studio 2015 and built by TFS 2015.
In Visual Studio, open the NuGet package manager settings (Tools menu > NuGet Package Manager > Package Manager Settings). Choose "Package Sources" from the options list on the left.
Create the nuget.config file at the root of the solution. This should be the same folder location as your ".sln" solution file. Copy the following into the config file:
<configuration>
<packageSources>
</packageSources>
<activePackageSource>
<add key="All"
value="(Aggregate source)" />
</activePackageSource>
</configuration>
Within the <packageSources> tag, create an <add key="" value="" /> entry for each source listed in the "Package Sources" options window. The key is the name of the source as shown above the URL, and the value is the URL itself. Include those listed in both "Available package sources" and "Machine-wide package sources". I did not create an entry for the local filesystem as it wasn't used in this solution. Based on the screenshot above, the complete config file now contains the following:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org"
value="https://api.nuget.org/v3/index.json" />
<add key="Microsoft and .NET"
value="https://www.nuget.org/api/v2/curated-feeds/microsoftdotnet/" />
</packageSources>
<activePackageSource>
<add key="All"
value="(Aggregate source)" />
</activePackageSource>
</configuration>
After committing the nuget.config file to source control, TFS was able to download all the necessary NuGet packages and successfully build the solution.
In addition to Matt's answer, I'd like to highlight the following well-hidden stuff from the NuGet documentation:
NuGet config files are treated in the following priority order
(closest to the folder nuget.exe runs from wins), for example assuming
the solution directory is c:\a\b\c:
c:\a\b\c\.nuget\nuget.config - This file is only used for solution
level packages, and is not supported in nuget 3.0 - 3.4
c:\a\b\c\nuget.config
c:\a\b\nuget.config
c:\a\nuget.config
c:\nuget.config
User specific config file,
%AppData%\NuGet\nuget.config.
Or the user specified file thru option
-ConfigFile.
This could explain some weird behaviour in specific scenario's where a restore does or does not pick up a configured feed, depending on whether youre restoring with nuget 2.x or 3.x
Edit: and I found yet another reason why packages might not be detected:
I have package "A" with version 1.1.1.0 .
Prior 3.4 this command works well:
nuget install A -version 1.1.1.0
With NuGet 3.4 RC I get:
An error occurred while retrieving package metadata for 'A.1.1.1' from
source 'N'. An error occurred while retrieving package metadata for
'A.1.1.1' from source 'N'. Data at the root level is invalid. Line
1, position 1.
...
The client treats 1.1, 1.1.0, 1.01.0 and 1.1.0.0 as the same version
using SemVer rules. The reason non-normalized versions were special
cased in the past is because for v2 http calls the client would first
send the version string exactly as the user specified it