I have a shared resources project that I'd like to reference as part of my Team Services build, is there an existing task that can obtain these assemblies so that they are available to the MSBuild task?
I know I can have a libraries folder within a project to hold these references but I'd rather build from a central source and not have the noise of these additional folders in my projects.
Don't put binary references in source control. Turn your binary references into NuGet packages and allow your build process to restore the appropriate version of your NuGet package as necessary.
There is a VS Team Services extension for Package Management that will likely help you accomplish this. You can publish the outputs of your shared project as a private NuGet feed and then consume the feed in your other projects.
These references may also help:
Conceptual - https://www.visualstudio.com/sl-si/docs/package/what-is-packaging
Overview - https://www.visualstudio.com/sl-si/docs/package/overview
Related
asp.net core 2.2 publish generating lots off DLL in output directory(bin\Release\netcoreapp2.2\publish).
How I can move it to some other folder (bin\Release\netcoreapp2.2\publish\lib) & reference it?
Your question doesn't really make sense, but I imagine you're looking for a way to include a library from one solution in another. This is not the way to do that.
Instead, package your project as a NuGet. Then, you can reference the NuGet package in your other solution's projects. Some people are confused and think creating NuGet packages means having to make them public on the main NuGet repository. While you can of course do that, it's not required. You have a private repo, either through a third-party or deploy your own, or you can simply use a filesystem path or network location as a "repo".
In any case, creating a NuGet package is simple. You simply edit your project properties, go to the "Package" tab, and enable NuGet package creation. Fill in the relevant details about your package on that screen, and you're off to the races. Whenever you build or publish your project, you'll get a NuGet package created in the same directory. Then, just push that to your NuGet repo, or if it's a filesystem path or network location, copy it there.
I have multiple projects in the same folder, each of them creates a microservice. Each has a separate build and release pipeline. Currently each project is configured so to trigger when code is committed in its own sub folder. I am currently in the process of adding some common code which is used in some of the projects. I would like for a microservice to build and deploy if it uses a library that is being changes.
What is the best way to achieve this?
Ideally, I imagine something like this:
Build task which triggers on root directory -> Use MsBuild to determine if a project needs to build, by checking its dependencies -> Build/Abort.
Is this possible?
If you want to share code in source form and you are using .NET Framework projects, the best (but not optimal) approach that I found is to have the projects in the same folder and put the shared code in a subfolder that you include in both projects. To put shared code in a folder outside the root folder of a project is even worse.
The best approach (IMO) is to share code in compiled (Dll) form (rather than in source form): you can create a DLL with the shared code, package it in a NuGet package, and publish the NuGet package in some internal NuGet repository (for example, you can use the Artifacts feature of Azure DevOps as NuGet repository for your organization). The projects that require the shared code do it through NuGet references. The advantages is that the shared code in Dll/NuGet form can be versioned (not all projects must be updated at the same time for incompatible changes), it can use its own CI pipeline with unit tests, it can use its CD pipeline to publish to the Artifacts repository, etc.
I switched from the former approach to the latter. Much cleaner IMO.
I am using Visual Studio Team Services for Continous Integration, Continous Deployment for a ASP .NET Core project. In VSTS when we create a build definition, we are required to provide a repository link from where VSTS will get the code and then build it and we can use the build artifacts in VSTS release definition.
I do not want to link my repository with VSTS build definition. Instead I want the ability to produce a Web Deployment Package or a NuGet package for my project (I wont mind even if I have to do it out of VSTS) and then use that package as build artifact in my release definition.
Is that possible? if yes then how can I acheive this?
Thanks
You can add a package management feed as a release artifact. When choosing an artifact source, change the dropdown from Build to Package Management.
However, you still need to publish your NuGet packages to the feed first.
First, there are many source types of artifact in Release, as Daniel said that you can choose Package Management as release artifact, but you need to push the package to the feed first.
With Build artifact, it needs to be generated through Build and you need to specify the sources (Get sources).
Secondly, you can don’t link any artifacts in release definition, and download/copy the Web Deployment Package or NuGet package from a shared folder, other machine or other ways (e.g. FTP server) through related tasks, such as Copy Files, Windows Machine File Copy, PowerShell (download files programming) etc…
I've been fiddling with the TFS2015 task based build system for a few days now. The problem I keep on running into is the following:
I am trying to use nuget packages for my external references in my projects. These exernal references are actually not 3rd party libraries but simply other (shared) libraries of our company. I'm able to restore the packages in a task, but I can't figure out how i can make the "Visual studio Build" understand where to find the restored packages. It uses the hintpath in the project file to determine the location of the external libraries to include. However, these paths (which are used locally for development) don't match the paths used on the build server. I can add a referencepath to the msbuild parameters, but this path isn't searched recursively, and the nuget package restore restores packages including the entire folder structure of the package.
My question is. Is there a proper way to make the "Visual Studio build" step understand the location of my packages without changing the hintpath in the project file. If not, what is the normal way to go here. Should I move away from nuget altogether because our references are not actually 3rd party libraries, and if so, what is the alternative way of resolving the references (without adding the binaries to source control)
My question seems to be related to Storing nuget packages in alternate location on build server, however he seems to have fixed it using a copy to the location that is specified in the hintpath of the references, which is not an option for me. It seems to me there should be an easy way I'm not seeing to be able to point msbuild to the correct location for the libraries.
After the task restoring packages, you can add task "Copy Files" to copy the packages to the location "..\packages\lib\lib.dll"
So I have a Visual Studio solution which contains 3 database (.dbproj) projects. These projects need to reference other sql projects from other solutions, which I have packaged and uploaded to nuget. How can I manage these external packages / references in Visual Studio within the dbproj's?
Right clicking the database project within visual studio doesn't give me the "Manage NuGet Packages..." option.
I can Manage NuGet Packages for Solution to at least download the required packages to the solution root but at the project level, where the references are required I'd have to manually manage the references within each projects' references and update manually any time the package is updated so the reference points to the correct versioned package directory.
Is there a better way to do this for dbproj references for database projects in Visual Studio??
I ended up following the same path, creating NuGet packages of the referenced databases and then manually (via command line) installing them at the standard \package location. Then correcting the database references manually in the IDE
There is a work item for this functionality, go vote it up. There is a fork of the functionality already developed that sounds like it is fairly feature complete. You might try it out.