I am new to DevOps. I will explain my structure first.
Project 1>
Repo 1
Repo 2
I am trying to make two build pipelines one that will build Repo 1 and a second that will build repo 2.
Repo 2 has a dependency on Repo1.dll.
I understand that I can publish the Repo1.dll and then download the artifact in repo2's pipeline.
My trouble is, our developers normal workflow is to have both repo's running in debug on their machines using a project reference. I am having trouble understanding how to reference Repo 1 from Repo 2 in a way that the artifact can be used in DevOps and project reference can be used on the developers machines.
How should c# references be handled when working with DevOps artifacts?
The best way to do this is using the NuGet.
When you build Repo 1 and create the nuget package Package1. Then publish this package Package1 to the Azure devops feed.
Now, add this package Package1 to the solution2 in the Visual Studio from the feed.
When we update the repo1, we need to build the NuGet package, publish it to the feed, then update the refernces package version to refer to the package you just publish.
Related
Help needed with azure pipelines. Just testing it and consider migrating from TeamCity to Azure Dev and was wondering:
I have:
1. Asp.Net Core Web Api (Web1)
2. Asp.Net Core Web Api (Web2)
3. WPF App
4. Several infrastructure class libraries that are shared libs between the above 3 solutions (Web1, Web2, WPF).
Do I create 4 azure projects?
1 project that includes the repository of Web1 project with 1 pipeline that nuget restores, builds and publish artifacts
1 project that includes the repository of Web1 project with 1 pipeline that nuget restores, builds and publish artifacts
1 project that includes the repository of WPF App with 1 pipeline that nuget restores, builds and publish artifacts
1 project that includes all repositories of all class libs and for each library I create a pipeline
or I create one project for all and add one pipeline for each (web1, web2, wpf apps and class libs)
Writing the comments as an answer so that we can close the question.
Are those .NET projects located on different git repositories? Is your git tool Github or Azure Devops repos?
Personally I use projects to seperate different logical projects (development teams) and different pipelines inside the same project for different projects of the team.
For example team A could have 4 projects, I would go for one DevOps project and 4 pipelines inside it. Team B would have a separate project etc.
Shared libraries can be handled the same way as different projects. You can build them and upload them through a task on nuget. If they should be included on the projects, there should be already on your web1,web2 and wpf projects, as a result the pipeline that will execute msbuild and nuget restore will handle the libraries also.
If you do not want to eliminate some projects to specific people, then I would go for one DevOps project and different pipelines for each library project.
In general you combine the pipeline with a github repository. As a result if all your libraries are placed inside one github repository you will go with one pipeline, else you have to create multiple pipelines inside the same Azure Devops Project.
In general the approach that I mainly use:
Different Azure DevOps projects -> Different dev teams.
Projects inside one dev team -> Different pipelines inside the project.
Different github repositories -> Different pipelines for each one (exceptions apply here but in most cases it is a practice)
I'm looking for options that would allow us to trigger/queue builds (XAML Build Definitions within Azure DevOps) when a new package is available in either Azure DevOps Artifacts or Artifactory.
We've developed a common framework library, which we build, package and post to a NuGet Repository (either Artifactory or Azure DevOps Artifacts). Naturally, each time we post, we increment the version number: x.y.z.n, x.y.z.n+1, x.y.z.n+2...
We also have other components which reference this common framework using NuGet Floating versions: x.y.z.* Some of these components have interfaces that other components also reference and so on.
We want to trigger the rebuilds of components when a new version of a referenced package is posted to the repository.
For example: If a change to our Common Framework is made and a new version (x.y.z.15 for example) is posted to the NuGet Repository, we want to trigger/queue all the other builds which reference the Common Framework Package Version x.y.z.*.
We've been looking for existing tools to do this but so far no luck. Here are some ideas/strategies we have:
1) Does something exist or could something be built to subscribe to a Library in a Repository, that build could be triggered when a new version appears
2) Should we build a list of all the package references and builds which need to be triggered somewhere and write a program to do this.
3) Can we chain builds within Azure DevOps or can they subscribe to successful builds - forget about the Repository - just trigger from successful builds of the components you depend on... everything is in the same Azure DevOps code repository.
While we're using Azure DevOps, we're not using the GIT repository, we're using the older VS Repo and we've got the older XAML builds, not the Pipelines yet.
I am looking for practical options to develop and test private nuget packages.
We have a set of "core" code that is delivered securely through an Azure Artifact Feed. We have various "consuming" applications that use the core nuget packages.
As a small-medium team, one person may be developing the core nuget as well as consuming it.
Today we check-in / merge the code for the nuget package. Make sure the Pull request is approved / passes. Then the build updates the Azure Artifact feed.
Then we come back to the "consuming" app and can update the package. Works great if you fix / add the feature the first time. However, slows down productivity when treating this as an iterative development approach.
Looking for simple options for a small team. Random thoughts on options:
Push nuget "alpha" package straight from developer's machine to Azure Artifact feed. Symbol server too?
Do something with an Azure build to allow "feature" branches to publish to Azure Artifact feed somehow?
Push to local nuget feed. Include pdbs so it can be debugged?
Temporarily break the nuget reference directly for local copy of dll(s)?
Re-think using nuget packages as a whole?
Push nuget "alpha" package straight from developer's machine to Azure Artifact feed. Symbol server too?
It depends on whether you need to debug it. If you need do debug this "alpha" package, you have to push the symbol package to the symbol server.
Note: You do not need to push the "alpha" package to the symbol server, just the symbol package.
Do something with an Azure build to allow "feature" branches to
publish to Azure Artifact feed somehow?
There is a task Push NuGet packages, we could use it to publish to Azure Artifact feed during build, no matter which branch it is on. It depends on whether you have enough permissions for the Azure Artifact feed, you can check it from Artifacts->Settings->Feed settings->Permissions:
Push to local nuget feed. Include pdbs so it can be debugged?
No, you also have to include the source code. Check this thread for some more details.
And there is a lightweight solution how to debugged nuget package on local feed on a network share.
Temporarily break the nuget reference directly for local copy of
dll(s)?
Re-think using nuget packages as a whole?
The answer is yes, when we develop the project on the local, use project reference is better than nuget, check my another post for some more details:
Ticket: Project reference VS NuGet.
Hope this helps.
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:
My I know what should I put in WhatShouldIPutInHere? I want to push my nuget to my team city server. it is on localhost:90. Thanks
[Exec] C:\TeamCity\buildAgent\work\f091ac5edf11aa03\packages\OctoPack.3.5.2\build\OctoPack.targets(109, 5): error MSB3073: The command ""C:\TeamCity\buildAgent\work\f091ac5edf11aa03\packages\OctoPack.3.5.2\build\nuget.exe" push "C:\TeamCity\buildAgent\work\f091ac5edf11aa03\TodoWebApp\obj\octopacked\TodoWebApp.1.0.26.nupkg" MyAPiKey -Source WhatShouldIPutInHere? "
A regular nuget push (what OctoPack is trying to do) is not going to work.
The TeamCity documentation states
You can publish packages to the feed either as build artifacts of the NuGet Pack build step (using the Publish created packages to build artifacts checkbox, packages will be indexed asynchronously) or via the NuGet Publish build step (since TeamCity 2017.1, packages will be indexed synchronously)
Make sure that OctoPack only creates a package (and not trying to push it) and make it an artifact to add it to the TeamCity NuGet Server.