I'm setting up some CI with build configurations that require some NuGet packages. These NuGet packages are built on the same server which is nice. I've read that I can use TeamCity's NuGet feed to meet my requirements. I've been following this guide.
I've created the feed on the Build project which has generated the v1, v2, and v3 endpoints. For indexing packages, I've gone for the first option, namely
To index packages published by the selected build configurations only, add the NuGet packages indexer build feature to these build configurations.
as it seemed to be the most straight forward. The NuGet packages indexer feature is applied to the two configurations that build NuGet package artifacts. These artifacts are building correctly as seen below:
If I plug the v3 endpoing into Visual Studio Package Sources for example, I just get an authentication prompt followed by the error Unable to load the service index for source .../v3/index.json. Response status code does not indicate success: 401 (). If I paste the v3 endpoint into a browser, I get a json object with a collection of objects with properties #id, #type, and comment. v1 and v2 in the browser show me an XML file with an empty Packages collection.
How do I confirm my packages actually ended up in the feed and/or am I misunderstanding how the endpoints are used?
Update: Turns out it was indeed a misunderstanding on my part. The /v3/index.json lists actions one can take on the feed. Using /v3/query lists all packages hosted by the feed.
The remaining problem is the error trying to consume packages from the feed. TeamCity throws the following errors:
C:\Program Files\dotnet\sdk\3.1.201\NuGet.targets(124,5): error : Unable to load the service index for source <host>/httpAuth/app/nuget/feed/<project>/<feed_name>/v3/index.json
C:\Program Files\dotnet\sdk\3.1.201\NuGet.targets(124,5): error : Response status code does not indicate success: 401 ().
Alongside the solution file in my vault is the following NuGet.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nugetserver" value="<host>/httpAuth/app/nuget/feed/<project>/<feed_name>/v3/index.json" />
</packageSources>
</configuration>
Is something else required to connect all the dots?
Turns out TeamCity has a neat little feature where it can pretty easily reference a TeamCity feed within the NuGet Installer runner type as a build step by placing the feed into the Packages sources input. By executing this build step before the one that publishes my files, all is well.
Related
I have a Azure pipeline with a MSIX Build and Package step for a WPF solution that started occasionally failing last week (with no changes to the pipeline definition) and is now failing every time with the error:
C:\Program Files\dotnet\sdk\5.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1004: Assets file 'D:\a\8\s\xxxxxx.Packager\obj\project.assets.json' not found. Run a NuGet package restore to generate this file. [D:\a\8\s\xxxxxx.Packager\xxxxxx.Packager.wapproj]
The project in question is the UWP packaging project and has no nuget references and I've had many runs of the pipeline which were successful.
The difference I can see in the logs is the failed builds (before the error above) seem to be missing a line:
Using shared compilation with compiler from directory: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Roslyn
I seem some other questions and answers around the error above but none specifically pointing to the issue above. The wapproj is included in the solution. Carrying out a nuget restore for the .wapproj does not fix the issue.
It's very odd that it was working and suddenly isn't with no changes to the pipeline.
First, you should make sure that you have add nuget restore task under pipeline. The restore should generate the guidance file project.assets.json file under obj folder. And that is necessary for build process.
And, you should moidfy your xxx.wapproj under azure repos and change Microsoft.Windows.SDK.BuildTools nuget package to version 10.0.18362.3-preview. From this document, the other versions are abandoned.
<PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.18362.3-preview" PrivateAssets="all" />
This is my first attempt at Q#. I followed the instructions here: How do I get the missing dependencies? Please see my screen shot
https://learn.microsoft.com/en-us/azure/quantum/install-command-line-qdk?tabs=tabid-vs
Have you tried just building the program? Nuget dependencies are typically downloaded the first time you build the program?
Looks like you're using the most recent version of the QDK (0.17.2105.144881), so you can open your .csproj file and confirm that it's using it. You should see this on the first line:
<Project Sdk="Microsoft.Quantum.Sdk/0.17.2105144881">
You can also confirm that the NuGet.config file in your machine has the public feed in it:
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
If you still get NuGet restore issues, I would also recommend installing .Net Core SDK 3.1.409 (Link). I see that you are using .Net 5.0, but you can have multiple versions side by side.
I hope this information is useful.
It seems like there is an issue with NuGet. If you in Visual Studio select Tools=>Nuget Package Manager=>Package Manager Console and in that write the command: dotnet restore.
And you then get an error similar to:
The package is missing the required nuspec file. Path:
C:\Users\x\.nuget\packages\x.x.x
Then there is something broken with your local NuGet cash, empty it by removing everything inside the packages folder. and then run the command dotnet restore again.
also includes the error messages, since image-texts isn't searchable (so that others also can find this):
No namespace with the name "Microsoft.Quantum.Canon" exists.
No namespace with the name "Microsoft.Quantum.Intrinsic" exists.
No type with the name "EntryPoint" exists in any of the open namespaces.
No identifier with the name "Message" exists. Assets file
'c:\User…\obj\project.assets.json' not fount. Run a Nuget package
restore to generate this file.
I am trying to get SourceLink to work with a private NuGet package.
I am running a netcore2.1 web application which references a netstandard2.0 NuGet package hosted on our Azure Devops NuGet feed.
Question 1: Does Source Link support .NET Standard packages?
I have followed the instructions in the guide here https://learn.microsoft.com/en-us/azure/devops/artifacts/symbols/setting-up-github-sourcelinking?view=vsts, which is basically:
Add the Index Sources and Publish symbols package to my Azure Devops build.
In Visual Studio, add our VSTS server as a symbols server
In Visual Studio, enable Source Link support. I also tried enabling Source server support.
The Build pipeline Publish symbols path appears to be working - in the logs I see:
Succeeded processing D:\a\1\s\src\MyCompany.Core.Services.SnapshotClient\bin\release\netstandard2.0\MyCompany.Core.Services.SnapshotClient.pdb:
When I start debugging my application I see a bunch of output in the VS Output window:
'dotnet.exe' (CoreCLR: clrhost): Loaded 'C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\2.1.4\Microsoft.AspNetCore.Hosting.dll'. Cannot find or open the PDB file.
For my NuGet package I see "Symbols loaded" which seems promising.
FWIW I do not see the prompt from Visual Studio that "Source Link will download from the internet".
When I debug and attempt to Step-In to my NuGet package, it just steps over it.
I then tried:
Headed over to https://github.com/dotnet/sourcelink and followed their instructions and installed the Microsoft.SourceLink.Vsts.Git package (Question 2 is that necessary?)
When that didn't work, I upgraded every darn package in my application, which forced me to install .NET Core SDK 2.1.403
Tried adding some stuff to the .csproj of my NuGet package, after trawling GitHub issues
<PublishRepositoryUrl>true</PublishRepositoryUrl>
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
and
<DebugType>portable</DebugType>
<ci>true</ci>
Now my .nupkg includes .pdb files too, which weren't there before. Still doesn't help me step in debug though.
installed the sourcelink cli tools from https://www.nuget.org/packages/sourcelink/ and ran sourcelink print-urls on the .pdb from my .nupkg. Looks correct, I think? URLs are present.
Disabled indexing after seeing a comment https://github.com/MicrosoftDocs/vsts-docs/issues/1336#issuecomment-414415049 from #mitchdenny . Still doesn't work.
And now I'm stumped as to why it's not working.
I wrote a complete blog on how to do this using .NET Core & AzureDevops, but the steps should work for .NET Standard projects as well.
That said, some key takeaways that are missing from Microsofts documentation that you should know are:
The project's debugging information needs to change from "Portable" to "Full"
The AzureDevOps Nuget(restore, build, pack & push) need to use the .NET Core task.
The .NET Core build task should have an argument "--configuration" that passes in the value "debug". Doing so generates the .PDB file
The .NET Core pack task should use the "custom" command, with the custom command being "pack" and have the following arguments: "--include-symbols -v d" and a "-c" that passes in the value "debug". Doing so tells the pack command to include the .PDB file in the package.
Question 1: Does Source Link support .NET Standard packages?
Yes. I successfully built a .NET Standard 2.0 library on Azure DevOps Pipeline, after which it was pushed to our private Azure DevOps Artifacts NuGet feed. Then, in a local project, I was able to step into the library (Visual Studio prompted me with a pop-up about downloading remote source code).
Here are the changes I had to make in the library's .csproj file:
<PropertyGroup>
<PublishRepositoryUrl>true</PublishRepositoryUrl>
<EmbedUntrackedSources>true</EmbedUntrackedSources>
<AllowedOutputExtensionsInPackageBuildOutputFolder>
$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb
</AllowedOutputExtensionsInPackageBuildOutputFolder>
</PropertyGroup>
...
<ItemGroup>
<PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.0.0-beta-63127-02" PrivateAssets="All"/>
</ItemGroup>
Question 2: is that [PackageReference to Microsoft.SourceLink.GitHub] necessary?
I'm not sure. The docs suggest it is. But I removed the reference, re-built on Azure DevOps, and was still able to step through the library. Perhaps it's necessary for different environments (I'm keeping it just in case).
FWIW:
I'm debugging using Visual Studio 15.8.9
My latest installed .NET Core SDK is 2.1.403
My library's consumer is a .NET Core 2.1 executable
I compiled my library using Cake, which I have call into dotnet msbuild
I have setup my own nuget feed and have hosted that on our dev server.
When I try to push my packages from my local machine to dev machine as below:
dotnet nuget push C:\MyProjects\Common.2.0.0.nupkg -k myapi -s https://mydev.com/AENuget/
I get the error as:
Response status code does not indicate success: 405 (Method Not Allowed).
Now I have read and tried many settings like adding
<remove name="WebDAV" /> <remove name="WebDAVModule" />
Giving permissions to my nuget packages folder, adding app pool account but still I am not able to resolve this issue.
Secondly instead of pushing if I just copy my nuget package file to the package folder being hosted in our dev server and then in visual studio I add the new server source I get the below error:
[Package Source] The V2 feed at 'http://mydev.com/AENuget/Search()?$filter=IsLatestVersion&searchTerm=''&targetFramework=''&includePrerelease=false&$skip=0&$top=26&semVerLevel=2.0.0' returned an unexpected status code '404 Not Found'.
So looks like neither the push from nuget nor the copy is working. Looks like some permission issue which I am not able to resolve.
Would appreciate if someone can provide any inputs to this.
FYI: This works fine if I host this on my local machine.
The problems you are having seem to indicate you are having issues with the NuGet.Server and the system itself. These can be problems with the firewall, hosting configuration (IIS), or a wide variety of problems.
If you are on a very small team, you might just create a shared folder on a network server (with read/write access for the team). You can add the package source to Visual Studio by following this article. The source will be the UNC path to the directory (e.g. \\servername\path\to\nuget\folder).
NuGet.Server is a package provided by Microsoft and NuGet. This is used widely so I do not believe you have a problem with the package. If you encounter a specific problem, we may be able to help.
I'm currently looking at NuGet to solve my dependency problems in TFS and what I wanted to do is to host my own NuGet server that would take care of internal dependencies. I also want to use NuGet to handle my 3rd party dependencies as well. I'm trying to set up automated builds for our company and this is one roadblock I'm trying to overcome with NuGet.
So my question is how do I handle this scenario in which I have to retrieve my dependencies from different servers?
Is there a better way to handle internal dependencies? How is everyone else doing this?
Also just as a note I intend on using NuGet without committing packages to TFS. I planned on using the method outline in this article:
http://blog.davidebbo.com/2011/08/easy-way-to-set-up-nuget-to-restore.html
Glad you're looking into the no commit scenario for NuGet packages on TFS. You can take a look at my blog post on this topic where I explain the concept.
EDIT (2012/06/13): NuGetPowerTools is replaced by NuGet's built-in package restore functionality. However, same concept of changing the PackageSources element in nuget.targets still applies.
You definitely should take a look at David Fowler's NuGetPowerTools.
After installing this package, you can Enable-PackageRestore (newly installed command in Package Manager Console), which will add...
Enabling package restore will add MSBuild targets to your project files. These MSBuild targets will trigger nuget.exe in a pre-build step and fetch any packages required by your project.
No need to check-in NuGet packages in source control, all you need is the packages.config and these msbuild tasks.
To configure multiple, different package sources, you need to set some settings to be used by these MSBuild tasks. One of them is PackageSources. You can set it by editing the NuGet.targets file, which you will find in the .nuget folder once you enabled package restore.
Regarding those package sources, you could set up different internal NuGet galleries, or simply set up different network shares to be used. This is a matter of requirements and preference, so you can choose. All you need to do, is to tell your msbuild targets to use these packagesources. The order in which you define them, will be the order of lookup of packages as well.
Good luck!
Xavier
Little update on accepted answer and question:
When using TFS as a buildmachine without visual studio installed on it, you can do the following so the buildmachine automatically uses your custom packageSources (more than 1 in the same solution) without any further configuration of packagesources in your solution.
Create a machine default config by placing a NuGet.Config in the root ( C:\NuGet.Config ) by using sample from: http://docs.nuget.org/docs/reference/nuget-config-file
Comment out the line with: <add key="repositorypath" value="$\External\Packages" />
Otherwise your packages gets expanded in C:\$\External\packages\'. When commented out, the config gets chained and the right directory will be used.
Config your needed packagesource(s).
For more Info about other options (e.g. user specifc) see: http://docs.nuget.org/docs/reference/nuget-config-file (bottom of the page).