I'm using Azure Pipeline to build and publish NuGet packages to the Azure Artifact feed. The pipeline includes the Publish Symbols task as below:
- task: PublishSymbols#2
inputs:
SearchPattern: '**/bin/**/*.pdb'
SymbolServerType: 'TeamServices'
However, when installing the package into the sample console app I can not debug the package (the body of the methods is not visible).
I'm using C# .NET Core 3.1
Pipeline Type: YAML
Used this article to config the Visual Studio
https://learn.microsoft.com/en-us/azure/devops/artifacts/symbols/setting-up-github-sourcelinking?view=azure-devops
For those who face this issue needs to take into consideration some issue/case related to Azure DevOps API and the Symbol file (PDB) packaging mechanism. The PDB contains the information regarding all the cs files regarding the package and because the package packing process is done on the Agent itself the information regarding the cs files is like this: $(Build.SourcesDirectory)/RepoName/SomeDirectory/File.cs
However, when the Visual Studio tries to download the file (the reference is in the PDB file) from the Azure DevOps API, it can not find the file. Because the API wants to get the cs file like this: https://azureDevOpsAPIURI/OrganizationID/RepoID/path=/SomeFirectory/File.cs
And this is a conflict between API and PDB files' reference. I have managed to solve this problem by Moving all the CS files from the Agent's checkout path to $(Build.SourcesDirectory) in order to get rid of the RepoName in the call to Azure DevOps API. I'm not sure if it's a conflict or there is a native way to do this or no.
Related
There are several documented ways on internet on how to use Symbols Source files and Source Link to debug inside a Nuget Package but it's honestly hard to understand what is the good way for me.
We have an Azure DevOps Server on which we generate Nuget packages and at the same time publish the .pdb files to the Azure DevOps Symbol Server using an Index Sources & Publish Symbols task in our build pipelines as described here
My project' also has a reference to Microsoft.SourceLink.Vsts.Git and this code in the .csproj file
<PublishRepositoryUrl>true</PublishRepositoryUrl>
<EmbedUntrackedSources>true</EmbedUntrackedSources>
I've read several blog posts but the source I trust the most to be up to date is of course the official Source Link Git repository.
The readme.md file says
Including PDBs in the .nupkg is generally no longer recommended as it increases the size of the package and thus restore time for projects that consume your package, regardless of whether the user needs to debug through the source code of your library or not
I agree with that point that's why I want to use the Symbol Server, not to include the .pdb file in the Nuget Package. Therefore please don't flag my question as a duplicate of this one, because the accepted answer is exactly what I don't want to do.
The readme file also states that
.snupkg symbol packages have some limitations:
They do not currently support Windows PDBs (generated by VC++, or for managed projects that set build property DebugType to full)
They require the library to be built by newer C#/VB compiler (Visual Studio 2017 Update 9).
The consumer of the package also needs Visual Studio 2017 Update 9 debugger.
Not supported by Azure DevOps Artifacts service.
so at least I know I can't use that.
But what is the proper way to set Source Link up and working then?
When I debug my test console application it successfully downloads the .pdb file to my Symbols cache folder but if I try to step in the code coming from my Nuget Package using F11, it just doesn't work. (However it steps in System.String.Concat because my simple test Nuget Package is actually concatenating some strings)
I tried to run sourcelink test TestSourceLink.pdb but I get a error: url hash does not match. I read here that sourcelink test is a legacy thing and doesn't support authentication to private repositories like ours.
With my browser, if I visit the URL given by sourcelink print-json TestSourceLink.pdb I can see the latest source code. But now the question is, why is Visual Studio not able to download the source code? I'm authenticated to this Azure DevOps server in VS because I'm able to install Nuget Packages coming from this server.
Here are my debugging settings:
Thanks a lot. I really can't figure out what's the missing piece of this puzzle
Well, I should have read and followed this answer before posting my question because this was the missing piece of the puzzle.
I needed to follow steps 5 and 6 of Eric's blog post but I actually didn't need to modify my pack command because I'm not including the .pdb file in the Nuget Package.
[EDIT 2]:
Note: So far I could only get this working if the Nuget Package is generated with the Debug Build Configuration. If you find a way to get Source Link working with a Release DLL inside the Nuget Package, please answer my other question. Thank you
[EDIT]: Since I wrote a documentation for my company, here it is:
Summary:
This requires two things:
Having access to the Symbol file of the project (.pdb) which is a mapping file used by the debugger
Enable Source Link support so Visual Studio knows where it should look to download the source code while debugging
Set Up:
Component's project
For each project in your solution:
Only if you plan consumers of the Nuget package to use Visual Studio 2017. This step isn't required with you want to use Source Link with Visual Studio 2019:
In Visual Studio, right click on your project -> Properties then go to Build -> Advanced and change the Debugging Information from Portable (default value) to Full
Install the Microsoft.SourceLink.AzureDevOpsServer.Git Nuget Package
Edit the .csproj file and include the following code in the first PropertyGroup element:
<PublishRepositoryUrl>true</PublishRepositoryUrl>
<EmbedUntrackedSources>true</EmbedUntrackedSources>
Azure DevOps build pipeline
Create a pipeline variable called BuildConfiguration (if it doesn't exist already) and set the value to Debug
Use this variable as argument in your .NET Core Build task: --configuration $(BuildConfiguration)
In your .NET Core Pack task, use this variable in the Configuration to Package field: $(BuildConfiguration)
At the end of your pipeline you must have a task Index Sources & Publish Symbols
In the Artifact name field, the BuildConfiguration variable must be used too: Symbols_$(BuildConfiguration)
Of course you must also have a .NET Core Push task to push you Nuget package to your Azure DevOps Nuget Feed
Visual Studio
Tools -> Options -> Debugging -> Symbols click on the New Azure DevOps Symbol Server Location... button and authenticate to the server
Set the cache folder to a convenient location like C:\Symbols\. This is where all your .pdb files will be stored
Tools -> Options -> Debugging -> Symbols click on Load only specified modules. You can here specify the Symbol files of DLLs you want to load.
If you don't do this and leave the default to Load all modules, unless excluded, Visual Studio will take a very long time to load everything when you run your program in debug mode.
Tips : To see all the DLLs loaded by your project, when you're debugging, click on Debug -> Windows -> Modules. From here you can view the full list, select multiple and then right click Copy Value -> Copy Name
Tools -> Options -> Debugging -> General
Uncheck Enable Just My Code
Check Enable source server support
Check Enable Source Link Support
Consuming project
When you want to debug inside the Nuget Package's code, naturally press F11 to step into it and Visual Studio will ask if you agree to download the source code from your Azure DevOps repository
I have a Visual Studio solution which has various class libraries and several ASP.NET website projects. The website projects reference the class library projects, so for ease of working they need to be in the same solution.
The whole solution is version controlled through Visual Studio Team Services (now Azure DevOps).
When the solution is committed to VSTS, the solution is automatically built by VSTS.
I also want to use continuous integration and deploy the website projects in the solution to various web servers via FTP (FTP is the only option for this, MSDeploy etc is not available). The releases will be triggered by the build on commit.
The problem is that I need to publish the actual website files via FTP during a release triggered by the build, but the build artifact only contains .zip files.
For example, if the solution has a website project called 'MyWebsite' the build artifact has a zip called Mywebsite.zip, but no files are accessible. As such, I can deploy a zip file to the web server, but not the actual website files.
How can I deploy these files?
Furthermore, I don't want to deploy all of the files in the website project. I want to deploy a release version (similar to what is published using Visual Studio 2017's Publish tool), which the zip file seems to contain.
VSTS/Azure Dev Ops has Tasks built in to Extract Files and FTP Upload. The release pipeline also has a variables which you can access via release tasks and powershell. $(System.DefaultWorkingDirectory) is where artifacts(built code) are downloaded to. An Agent Job with two tasks should be able to accomplish what you are looking for.
Tasks
Details
Azure Dev Ops Release Variables
I have a created an ARM template in Visual Studio, and I need to package the JSON files so that I can use the option in Octopus Deploy to deploy the JSON files within the ARM template as a package - as described in the following link, under section 'Template Contained in a Package
https://octopus.com/docs/deploying-applications/azure-deployments/resource-groups
The problem is that I don't know what application in Visual Studio to package the application? I did some research and I read that the best package to use in nuspec as described here:
https://dinventive.com/blog/2016/10/20/5-steps-and-under-30-minutes-to-deploy-arm-templates-via-octopus-deploy/
However, there are a whole bunch of nuspec applications. The closet I got to what I need is the NuGetToolsPackager, as shown in the image.
nuget
However, if there are any other suggestions, they will be most welcome.
The link you provided shows how to create the package from a build server (in this case VSTS), which is the recommended way to go. Packaging + building should be orchestrated from a build server, and not from and IDE if possible :)
That said, one good way to do this from Visual Studio would be to add a dependency to the OctopusTools package which will download Octo.exe during your build. Then you can add a post-build script that calls Octo.exe pack to create your package, and then Octo.exe push to push it to a repository.
Documentation for Octo.exe pack: https://octopus.com/docs/packaging-applications/creating-packages/nuget-packages/using-octo.exe
Documentation for Octo.exe push: https://octopus.com/docs/api-and-integration/octo.exe-command-line/pushing-packages
Short version of the problem:
I'm having difficulties including the assemblies my .NET Core Console App depends on.
Initially, the assemblies from NuGet packages were not included in the bin folder even though I could run the app in Debug mode without any problems.
Found an article that suggested that I should add <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> in the myapp.csproj file which I did.
Doing so included the dll files for the NuGet packages in the bin folder BUT after I copied my console app to Azure to run as a WebJob, I got an error telling me that System.Data.SqlClient was missing.
After inspecting the folder where the WebJob runs, I could see that the dll for System.Data.SqlClient is actually in the folder. I concluded that it may have been an issue with version numbers. The error indicated the following:
'System.Data.SqlClient', version: '4.4.2' was not found
When I right click the dll file for this assembly and check its version, it shows version 4.6.
Any idea how to resolve this issue?
Longer Version:
I built this .NET Core 2.0 console app to run as a WebJob following this article: http://matt-roberts.me/azure-webjobs-in-net-core-2-with-di-and-configuration/
I had to create this WebJobs app manually because currently Visual Studio does not provide a way to build Azure WebJobs in .NET Core.
Because of this current limitation, I also could not Publish my WebJobs app directly from Visual Studio.
So, I tried to zip it up and upload it through Azure Portal. This is when I realized that NuGet assemblies were not included in the bin folder. The rest of the story is already up in the "Short Version" section.
I'd appreciate some suggestion in solving this issue.
UPDATE:
When I ran dotnet publish --self-contained -r win32-x64 -c Release inside the project's root folder, I got the following error:
Not quite sure of the WebJobs specification, but you should be able to use dotnet publish --self-contained -r win-x64 -c Release to generate executable and its dependencies. Zip them up and you should be able to deploy to Azure.
There is really no need to modify your csproj like you did.
Besides, you can use .NET IL Linker to shrink the size of the generated folder.
Reference
https://learn.microsoft.com/en-us/dotnet/core/deploying/deploy-with-cli#self-contained-deployment-with-third-party-dependencies
I'm attempting to deploy a boilerplate Visual Studio 2017 RC Asp.Net Core web app (no authentication) to an Azure App Service using the GitHub deployment option. The app has not been modified from the boilerplate code; literally: create a new app from the VS template, publish it to GitHub, and deploy to App Service.
Question
Are any particular settings necessary for VS 2017 RC apps to deploy to an App Service, or has the App Service SCM (Kudu) tooling simply not yet caught up with the VS 2017 RC project structure?
Details
I'm running into two problems that I think are probably related.
Problem 1: the MSbuild tools v15.0 don't appear to be installed on the app service. When building, Kudo defaults to v14.0:
Command: "D:\home\site\deployments\tools\deploy.cmd"
Handling .NET Console Application deployment.
MSBuild auto-detection: using msbuild version '14.0' from 'D:\Program Files (x86)\MSBuild\14.0\bin'.
I added a custom app setting, SCM_BUILD_ARGS=-tv:15.0, to try to force Kudo to use v15.0, but this had no effect. It continued to use v14.0 as before.
Problem 2: (and possibly as a result of using MSBuild 14.0): MSBuild issues the following error when attempting to restore NuGet packages:
Nothing to do. None of the projects in this solution specify any packages for NuGet to restore.
This error message is a little vague, but until recently the message would assert that no project containing a packages.config or project.json file was found in the solution. Both of these files are deprecated as of VS 2017 RC. I added an empty project.json file to see if that would fix the issue. The packages appear to be restored but it continues to fail due to missing project.json sections.
Resolution
#david-ebbo kindly provided guidance. In his test repo you'll find deploy.cmd and .deployment files. Copy both to the root of your repo. Then update Line 74 of deploy.cmd to point to your .csproj file. Deploying from GitHub should now succeed.
Similar to https://github.com/projectkudu/kudu/issues/2236.
The Kudu script generator doesn't yet know how to handle Preview3, but you should be able to use a custom deployment script. The key is to use 'dotnet restore' instead of 'nuget restore' and 'dotnet publish' instead of 'msbuild'. See sample here.
We will fix Kudu to handle this soon.