I'm currently publishing some NuGets to my VSTS feed. Is there support for VSTS acting as a Symbol Server as well so I can publish my symbol packages?
You can publish your symbols to a file share. There is not presently support for using VSTS itself as a symbol server.
It is now possible to use VSTS as a symbol server
I've also written a blog post on how to setup a symbol-server using a VSTS build definition where the symbols are published on a file share. It's actually more as a step-by-step guide on how to publish and expose them via IIS
Checkout Source Link. It is becoming a new standard or at least recommended way.
SourceLink is a language- and source-control agnostic system for providing first-class source debugging experiences for binaries. The goal of the project is to enable anyone building NuGet libraries to provide source debugging for their users with almost no effort. Microsoft libraries, such as .NET Core and Roslyn have enabled SourceLink. SourceLink is supported by Microsoft.
In a case of VSTS Git repository and .Net Core project
Add nuget reference of Microsoft.SourceLink.Vsts.Git to your project - the one which will be dotnet pack later (as of now in preview - make sure you tick "Include prereleases" in VS Nuget Manager)
Add <AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder> into PropertyGroup where the TargetFramework element is.
Add .NET Core task with command pack
The nuget package will now contain PDB files so you clients can easily debug your library.
Related
For debugging I need to push my NuGet packages including Symboles to our self-hosted Azure Devops Server.
Therefore I use the dotnet pack task with the flags --include-symbols and --include-source in my build pipeline. As output I get two files package.1.0.0.nupkg and package.1.0.0.symbols.nupkg.
When I try to push the package.1.0.0.symbols.nupkg package in my release pipeline, I get the feedback:
409 (Conflict - The feed already contains "package.1.0.0".
(DevOps activity ID: 766B8BC7-9AE6-4998-A246-47397236122F)).
I found Publish *.snupkg symbol package to private feed in VSTS on stack. The feedback is that the Azure DevOps Server do not support NuGet Symbols and they suggest to use a symbol server.
Is it a possible workaround to simply rename the package.1.0.0.symbols.nupkg to package.1.0.0.nupkg and push this package to the feed? Is Visual Studio with able to open the debugger inside the sources of these kind of package?
Is there another way to provide NuGet Symbols for debugging on a Azure DevOps Server?
There are multiple questions in your post, let us try to solve them one by one.
Is it a possible workaround to simply rename the
package.1.0.0.symbols.nupkg to package.1.0.0.nupkg and push this
package to the feed?
The answer is no. The error 409 (Conflict - The feed already contains "package.1.0.0" means that you already have one package package.1.0.0.nupkg or package.1.0.0.symbols.nupkg with version 1.0.0 in your feed. So you could not push another package with same version in that feed. Package version in the feed is unique. In order to protect the package from stepping on each other because of the same version of the package.
So, to resolve that error, you need to update the package version, like 1.0.1 (Deleting the old version of the package from the feed will not solve this error).
Is Visual Studio with able to open the debugger inside the sources of
these kind of package?
The short answer is yes. The details will be explained in the next question.
Is there another way to provide NuGet Symbols for debugging on a Azure
DevOps Server?
The answer is yes, we need to configure Visual Studio to enable debugging remote packages. You could refer below Official document and detailed blog:
Debug with symbols in Visual Studio
ASP.NET Core Debugging Nuget Packages with AzureDevOps | VSTS Symbol Server
But when I use nuget install package then only the package.dll is part
of the content which get downloaded from the Azure DevOps Artifacts.
Why is that?
This is expected behavior for installing the package. Because most of the time when we install and use the nuget package, we do not need the debug package, so the installation package will only add the dll we need to the project and will not configure the Symbols package. If we want to debug the package, we have to configure the Symbols package like above links.
The feedback is that the Azure DevOps Server do not support NuGet
Symbols and they suggest to use a symbol server.
The feedback you mentioned in the question is for *.snupkg symbol package not the symbols package. Azure DevOps Server should support publish NuGet Symbols packages, not debug packages, we have to manually configure Visual studio to use the Azure DevOps Server.
BTW, since there are many questions in your post and they are more general, my answer is not very specific. If you have any questions about any specific questions, you are welcome to open a new post with detailed questions.
I want to package and publish a .net standard based code as a nuget package using VSTS build. I have created a private nuget feed (in VSTS Artifacts) to which I would like to publish nuget package along with symbols package.
I tried using dotnet CLI tasks to build and publish but it only publish .nupkg and not *.snupkg to the nuget feed.
I googled alot but I only found articles related to publishing to nuget.org and not to a private feed.
Publish *.snupkg symbol package to private feed in VSTS
You can publish the .snupkg symbol package to NuGet.org, or to any NuGet server that opts into this experience. But azure devops private feed does not have this experience.
You can get the detailed info from this wiki NuGet Package Debugging & Symbols Improvements:
When publishing packages, both the symbols package and the .nupkg will be easily published to NuGet.org, or to any NuGet server that opts into this experience.
Reason:
As we know, when we consume .snupkg in Visual Studio, we add a new symbol server location under Symbol file (.pdb) locations:
But Visual Studio can only parse the symbol file (.pdb) directly rather than the .snupkg package, so we need a NuGet server to help us read the .pdb file from the .snupkg package. Azure devops feed is more inclined to be a shared repository of packages.
So, we have to publish *.snupkg symbol package to NuGet.org, or to any NuGet server that opts into this experience.
If you do not want share your package on the nuget.org, You can host your own NuGet server or you can use a lightweight solution to resolve this issue (You can debug the nuget package with private feed).
Hope this helps.
You may well want to just embed the symbol PDB in the main NuGet package itself. IMO that's the best approach here today - it's much simpler, removing the need for the symbol server at all and works well with all repository types, private VSTS/Azure DevOps feeds public repos. The only downside is that clients have to download modestly bigger NuGet packages even if they don't use the debug info, but that seems minor.
Adding the PDB in the NuGet package is normally just a matter of adding this to your project file:
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
See NuGet #4142 and Include pdb files into my nuget (nupkg) files.
Azure Artifacts does not currently support .snupkgs but it does have a symbol server to which you can publish if you're building using Azure Pipelines. This doc walks through setting up a pipeline that publishes symbols.
You can publish the snupkg files to Azure DevOps, but at this point, you cannot consume them from with VS to debug. Here is how I did it:
1) setup a "Use .Net Core" task to upgrade the .net sdk to the version that supports this (as below)
2) setup a custom dotnet pack command (as below)
3) push it to Azure using the dotnet push command (as below)
This results in the snupkg being pushed to Azure DevOps Artifacts, thus:
I want to set up continuous integration and deployment for an XAP Mobile app in Azure Devops.
In order to get CI/CD I need to set up the Azure Pipeline to install the right packages.
There is some information in the docs on Hosting your own NuGet feeds
and Get started with NuGet packages in Azure DevOps
Dev Express explained that they do not currently provide a Nuget feed for XAF, but I can make my own Delegate's DCNugetPackageBuilder
Using DXNugetPackageBuilder to make Nuget packages
As per the instructions I downloaded the .pdb files extracted them to c:\tmp\symbols
I also downloaded DXNugetPackageBuilder and edited buildPackages.bat according to instructions.
Next I ran build.ps1 in elevated Powershell
This created the .nupkg files at C:\tmp\Nuget
By default this uses the files located at
C:\Program Files (x86)\DevExpress 18.1\Components\Bin\Framework
and the .pdb files located at
c:\tmp\symbols
Using Nuget.Exe and the Credential Provider to push the packages to the feed
The Connect To Feed screen mentions I need to download Nuget.exe and the credential provider
Here are the docs on the Credentials Provider
I unzipped the VSTS CredentialProviders Nuget.Exe is included.
The next step is to follow the instructions given by the "add this feed" section of the Connect To Feed screen.
For example
nuget.exe push -Source "SBDDevExpress" -ApiKey VSTS c:\tmp\Nuget\DevExpress.Data.18.1.6.0.nupkg
I ran into an access denied issue that got solved here
then I was able to push all the packages I wanted.
Set the Nuget Package Source
In VS2017 with my solution open I used Tools -> Nuget Package Manager -> Package Manager Settings
I added package settings with the Azure endpoint set up as a package source.
Errors building
When I run the build pipeline I get errors like
The type or namespace DevExpress could not be found are you missing a directive or assembly reference?
From studying Updater.cs and Module.cs
It seems I am missing the following namespaces from the Nuget feed.
DevExpress.ExpressApp.DC;
DevExpress.ExpressApp.Updating;
DevExpress.Persistent.BaseImpl.PermissionPolicy;
[Update]
DevExpress suggested I compare the dlls generated in the bin folder with my package feed.
I found several missing files and pushed their packages.
I now have
XafMobile.Module\Properties\licenses.licx(1.0): Error LC0003: Unable to resolve type 'DevExpress.ExpressApp.ModuleBase"
I can see from the source code that ModuleBase is a public class in DevExpress.ExpressApp
I am wondering if this is something to do with reflection.
There is some mention of it at Dev Express support
[Update]
I tried removing the licence files and syncing the project.
Now the errors show as missing assembly references
Also When I rebuild my solution the license files are missing from the properties folders
I wonder if this helps explain it
[Update]
Manuel Grunder [DevExpress MVP] and DXNugetPackageBuilder author explained that
"
When working with nuget.packages you need to reference them via nuget as well
as he explains here
"
As is explained here
"When working with nuget.packages you need to reference them via nuget as well. Thats the reason why it did not work in the first place."
I have turned on TeamCity's NuGet Server and I want to push in common packages (i.e. from public sources such as NuGet.org) because the build server cannot see outside our company, so restoring packages on the build server from NuGet.org is not possible.
I cannot see how to push these packages on to our TeamCity server. I've seen various answers suggesting to use a package build still or some other means of publishing from within a build, but this is not appropriate for my use case.
If I try to publish from a command line it complains that it cannot find an API key (where do I get that from?) and it won't allow me to enter my credentials (I assume my team city login would be it) as it tells me "Cannot prompt for input in non-interactive mode." (I didn't set that mode and I can't see how to turn that off).
So, how do I push/publish an adhoc package that I obtained elsewhere into team city?
I believe that the nuget functionality provided by TeamCity is an API added on top of TeamCity's builtin artifact functionality.
There are a number of consequences of that:
When a build configuration is executed that produces any .nupkg files that are marked as artifacts, they will be available on the Teamcity nuget feed.
As with all other artifacts nupkgs published in TeamCity are subject to Teamcity's general artifact retention rules.
Access rules for nuget packages are the same as access to the TeamCity projects.
There is however as far as I know no implementation in the Teamcity Nuget API for pushing packages to it. The general practice for storing original or generated packages is to use a stand alone nuget server or service like a normal file share, a Nuget.Core based server, proget or myget.org.
Update:
If you end up with many packages of your own I've heard people reporting that Teamcity becomes quite slow when the clients are resolving the packages.
Update 2:
The last years I've adopted the notion of separating build artifact packages into the two categories library package and deployment package. A separate package repository can be used for both types but a repository such as the one available in for instance Octopus deploy should only be used for deployment packages.
Update 3:
Microsoft have a page for a number of nuget server options.
I have a working Octopus Deploy server which has a library of packages I built.
I have an assembly which depends on one of the assemblies which I have deployed in Octopus Deploy and which is currently in that repository. I tried adding it as a package source in NuGet Package Manager, with my repository's URL (something like:
http://myoctoserver/app#/library
).
It will not populate the list Manage NuGet Packages of Visual Studio 2013, although the Microsoft and .NET and the nugget.org will populate.
Documentation doesn't appear to address this at OctopusDeploy.com. Is this something that can be done, or does my organization need to make an external NuGet feed?
Octopus Server provides a write-only repository and it can't be consumed by other NuGet clients.
There are many options available to you depending on your budget / hardware
ProGet
MyGet
NuGet.Lucene
NuGet Gallery
Octopus built in package repository is not mean't to be consumed by others.
The nuget packages there, are built specifically for Octopus. They have different structure. These packages are meant to be unpacked directly to a specific location, and run by either Windows service or IIS.
Also, from docs:
It is important to understand that the Octopus server provides a
write-only repository; intended for hosting application packages only
. Packages that are pushed to the Octopus server can't be consumed by
other NuGet clients like Visual Studio. If you need a NuGet feed for
sharing libraries between your development projects, a separate NuGet
repository is required.
http://docs.octopusdeploy.com/display/OD/Package+repositories
We host internal nuget server ourselves, which works very nicely.