I have an ASP.NET Core 2.0 project in TFS 2017, and I'd like to specify a version number when our project builds (whenever changes are pushed to master). Is there a simple way to accomplish this? I found several tools that seem to be for this, but I can't figure out how to use them. (GitVersion | Semantic Versioning Build and Release Tasks)
You need to create a CI build or CD release against the master, then it will trigger the build/release whenever changes are pushed to master.
For versioning the .Net Core project, you can reference this article : Versioning .NET Core in Visual Studio Team Services
For the GitVersion Usage, please refer to this link: http://gitversion.readthedocs.io/en/latest/usage/usage/
Besides, you can also use the .NET Core CLI tool to update the version information in .NET Core *.csproj files.
Related
How to migrate a TFVC project from TFS to AZDO ?
Goal:
Is to migrate host projects on (TFS 2017) using TFVC, to switch them to Azure DevOps Service (AZDO) using TFVC there too.
My context:
TFS 2017 server version 2 hosting current source projects.
AZDO 2019 service wanting to host projects targeted on TFS.
Context wish:
Keep the history of source projects (TFS) on AZDO services.
I Just want to migrated the projects (TFS) in TFVC to (AZDO) in TFVC, without doing any TFVC -> GIT conversion.
I would like to avoid updating the TFS 2017 server for 2018 then to
the AZDO server to switch to AZDO services afterwards.
You understand
that is a lot of step to just want to switch a project in TFVC on
TFS2017 to a TFVC on AZDO
The easiest way to migrate is to upgrade your TFS2017 server to Azure Devops Server 2019 and then using the full fidelity import feature to upload your whole database backup to Azure Devops Service.
At the moment migration tools support TFS2018u3 as well as Azure Devops Server 2019 and 2019u1 as well as 2020 can be imported into the service. We do these kinds of imports regularly and it's a very straightforward process to restore your TFS server backup to a temporary SQL server, install the correct version of TFS/Ads and have it perform the upgrade in-place during the installation. Then use the migration tools to import the collection into Azure Devops Server. Depending on the size of your collection this may take between a couple of minutes to a couple of hours. I've done the upgrade on my laptop on certain occasions as well, installing Azure Devops Server and SQL Server Developer edition directly on Windows 10. Even a trial versions will do.
For all the details on the. Import process, see:
https://learn.microsoft.com/en-us/azure/devops/migrate/migration-import
If you want to import your tfvc project from one TFS servers to another TFS server/Azure Devops Server, you can detach the project collection on you current TFS server and bacmup/restore the database on another server. It will automatically be upgraded
If your project collection has multiple projects, you can delete the projects you don't need after attaching and upgrading your collection.
There are a few tools to perform a history replay from one server to another, those tools can't import everything, your changes id's will change and you'll lose the exact date a commit was made (and possibly the user who made the commit if that account no longer exists). Tools like:
https://www.opshub.com/products/opshub-visual-studio-migration-utility/
Depending on how old and how big your collection is, it may take many hours to migrate the data. If data has previously been deleted/destroyed or branched across projects or edited during branch operations, then the replay may fail or may be forced to perform alternative actions, some of these operations are no longer supported. I've used opshub on a couple of projects and some it completely failed to migrate, others migrated with incomplete or incorrect data. This was 4 years ago, maybe these were bugs and they were fixed, but since the import tools have been released we've used those almost exclusively.
PS: using tfs-git to convert (part of) your TFVC repo to git would be an alternative which I'd recommend you look into further. TFVC has been declared feature complete and has received very little love in the past few years. It's not supported by the new Multi-stage YAML pipelines, the integration for VS Code has been deprecated, the cross platform commandline tool for tfvc has been deprecated and therefore support for eclipse and rider and intellij as well. Team Explorer in VS 2019 is now pushed to the background with the release of the new git features which have escaped the Team Explorer window. It's clear that TFVC is fighting for a lost cause and that Git is winning, you'll need to switch over at some point.
I have an application that uses .NET Core 3.1 but in .NET Core Build and Publish tasks, the dropdown menu offers only 'til 2.x version.
How am I supposed to use them or what workaround instead?
Simple CLI?
Thanks in advance
#Patrick
.NET Core Task is this right?
But how should be that different compared to Restore/Build/Publish that are aldready set up in .NET Core pipeline?
If that so, I guess I just need to set the command with my custom publish value:
dotnet publish myPath -c release -f netcoreapp3.0 --self-contained true -r win-x64
Am I right?
That's not stand for .NET Core Version. It's our task version in Azure DevOps build Pipeline.
Tasks are versioned, and you must specify the major version of the
task used in your pipeline. This can help to prevent issues when new
versions of a task are released.
Each task in a pipeline has a Version selector to let you choose
the version you want.
Source Link: Task versions
According to your TFS tag, seems you are using private agent. You could choose to pre-install your .NET Core related environment/SDK in the agent manually.
If you want to do this during the pipeline, you should use Use .NET Core task
Use this task in a build or release pipeline to acquire a specific
version of .NET Core from the Internet or the tools cache and add it
to the PATH.
Not sure which TFS version you are using, which may do not contain above task. You could choose to manually pre-install .NET Core related on the agent or download source of task code and package upload to TFS server or use 3-rd party extension instead.
That's the version of the task, not the version of .NET Core.
If the repository is git behind our TFS project there is no way to filter the repository by source folder. The build always pull the whole repository. We have multiple solutions in the TFS project we want to build separetly. We can do it, but it is slow because we cannot filter the source folder to download.
The other problem that we cannot add folder to CI trigger. So all the projects will be build after a push in any projects.
I know that the Team Services already support path filters for git repository. But does anybody know some workarounds for this problem for on premise TFS 2015 Update 3?
There is no workaround for this on TFS 2015 update3. Unless separate your components into different repositories. Multiple projects must be in their own repository. All dependencies is a project by it self and can be handled as NuGet packages. Then your whole solution would not break if you change something in the dependency project and using CI trigger.
This feature will ship in TFS 15 and is already available on VSTS
https://www.visualstudio.com/en-us/docs/build/news/2016#june-14
The Challenge
We have an on-prem application (RM) that cannot communicate with VSO
Our code must stay in VSO
We need to give RM access to Build Definitions that are tied to our VSO source
Attempted Solution
Install TFS locally to host build definitions only
Have those build definitions pull from VSO
Problem
It looks like we can't use a VSO project directory in the Source Control Folder mapping
Is there a workaround?
Your best bet is to start migrating to the new Release Management service in VSTS, since the existing Release Management Server application is rapidly being deprecated. There are tools available to help ease the pain of migration.
You could also use RM Server in non-integrated mode -- nothing would be tied to build definitions, and you'd have to specify the path to the build drop manually when queuing the release. It can still be automated via the ReleaseManagementBuild.exe utility in the Release Management client folder, it would just take a bit more effort to build it out.
You could also build a custom build process template to pull the code from VSTS and build it, but again, that's investing a lot of effort in RM server.
[Full disclosure: I am a contributor to the migration tool linked above]
I am trying to grasp Release Management vNext and dsc configuration 'management' (how to manage DSC configuration files). In the 'Deploy Using PS/DSC' dialog box while editing a vNext Release Template
Why is PSScriptPath relative?
Does it really mean, that I somehow have to get my scripts I want to use relative to my current drop folder? What is the best way to do achieve this? I want to be able to do:
Have a separate git repository for configuration files
Reuse configuration files across different projects
I've read a promising article Packaging DSC configurations for Visual Studio / TFS Release Management vNext but it seems to be out dated and some kind of hack from my point of view.
How does Microsoft want us to use this? How to achieve reusable configurations in a separate repository?
Thank you
Use a submodule to your separate configuration repository, then ensure the submodule is initialized during the build. You can then copy the configuration scripts to the build drop folder as part of your build script.
The reasoning is that your deployment scripts will evolve over time, and that evolution should be something that is captured. If you ever need to redeploy an old version of your software, that old version shouldn't be deployed using new scripts -- it should be deployed using the same version it used initially.