I get this error in the TFS logs when I try to upload a task in the new TFS build system using the tfx-cli tool:
Microsoft.TeamFoundation.DistributedTask.WebApi.TaskAgentVersionMismatchException:
The task definition being uploaded requires a minimum agent version of 1.88.0.
The server's agent version is 1.83.2.
Unfortunately that is the agent that TFS provides for download.
It is an On Premise TFS server.
Does anyone know how to get the 1.88 version of the agent?
I did modified the task json file and I was able to upload it however it did not show up in the TFS UI.
And the reason is here:
https://github.com/Microsoft/tfs-cli/issues/30
In summary I was trying to use IISWebAppDeploy task which from the official git repository but that task is still in development and it will not show up in TFS until marked for release.
I suppose 1.88 is the current version of the VSO build agents. At least if I login to my VSO project and switch to the Hosted pool, the hosted agent is of version 1.88. I suspect it is being upgraded by the VSO silently. Thus, if you download an agent from VSO one of these days, it will most likely have version 1.88.
However, I'm not sure it is a good idea. First verify whether you really need a more recent version. The minimalAgentVersion is defined in the custom task definition, the JSON file. Try changing it down to your agent version, 1.83.2. Most likely, you should not require a higher version of the agent in your custom task until you upgrade your TFS instance.
Related
Currently we are using TFS 2017 update 1 on premises but we have to Migrate TFS at VSTS cloud platform. Also we TFS Build Servers on premises having XAML builds using customized build template. Our problem is after migration all XAML build definition would working as usual or not?
Currently we are using TFS 2017 update 1 on premises but we have to Migrate TFS at VSTS cloud platform. Also we TFS Build Servers on premises having XAML builds using customized build template. Our problem is after migration all XAML build definition would working as usual or not?
there is no code. Do we need to Re-configure all build server again?
After migration on VSTS can we configure All build servers on premises as well using old all XAML build definitions or not?
Please suggest on this.
XAML builds are still supported with Azure DevOps Service (with some limitations), see official response from Microsoft:
XAML build is still here until now. Current state :
If you have any XAML build data in your team project collection, you
will get a warning about the deprecation of XAML build features. You
will need to use VS or Team Explorer 2017 to edit XAML build
definitions or to queue new XAML builds. If you need to create new
XAML build agents, you will need to install them using the TFS 2015
build agent installer. Please refer to official document -XAML builds:
https://learn.microsoft.com/en-us/visualstudio/releasenotes/tfs2018-update2#xaml-builds
And we will keep it longer, how long does it can be used depend on
user feedbacks.
Installing TFS2015 Update 4.1 locally allows you to configure Build Server, Service and Agents that are connected to Azure DevOps Service, and run all your XAML builds from either Azure DevOps or Visual Studio.
XAML builds are no longer available in VSTS, so they will not work at all after a migration.
The good news is that TFS 2017 supports build vNext so you can convert your builds before you migrate to make sure you can still build after the migration.
Build vNext (Azure DevOps Pipelines) are much more flexible and easier to set up and customise than the old XAML builds. However if you have a lot of customised builds then it might take a while to convert them all.
One big advantage of the new build system is that the same build can be used across multiple branches, which might mean that you don't need to put as much effort in to converting builds as in the XAML system you needed a build per branch.
My suggestion is that you begin by familiarise yourself with the new build system and start to convert the builds before you migrate, then you can import you TFS database in to VSTS.
Some original info was changed to make the post more focused on the real issue after it was found.
These are some of the details of the current environment. I listed these only because questions were raised in other posts to determine what was and was not working in the current environment:
Upon check-in TFS 2017 successfully builds a web project on the build agent.
A VS 2017 publish profile can manually transform the project properly
The build machine artifact location includes both the transform and profile files
The artifact location is shown below:
I have researched this in depth on Microsoft's VS site, SO and other forums, but there are so many different answers, many of them for older versions, I have been unable to piece this together. As a result I have several sub-questions.
1) Can transforms be engaged in both Builds and Releases?. I read that transforms are applied during the publish process, not the build process, and that made me wonder if it is even possible to do this during a Build. But then when I was exploring releases, I saw all the same tasks usable in a Build, which suggests I can publish with a transform in either Build or Release. Is that correct?
2) Does TFS 2017 require a lot of special handling to engage a transform file? Some of the posts instructed the editing of the .proj file. I wanted to get a confirmation before doing that kind of detailed manipulation, especially given the improvements in TFS 2017.
The following information is the state of the current build definition named "confPanner-CI". The shaded PS script was successfully used to upload to the hosting location to test the whole process, but that is not adequate for the task at hand which requires transforms to be applied:
The full MSBuild Arguments which also created a temp location for the powershell script are:
/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=c:\ConfPlnrWeb
If I were to add a task for publishing I saw the Publish Build Artifacts task:
But none of the settings as shown below seem to relate to transforms:
The bottom line question is: How do I configure the build so the web project upload has the proper web transform applied?
Update: The following added after the answer below led to at least one place where VS transforms can be applied during a build, and presumably also a release.
Inside the MSBuild Build solution task set the Configuration as shown below:
Publish Build Artifacts task is used to publish the related artifacts ( The “a” working directory contains the artifacts (also known as the “drop”) that are uploaded at the end of the build) to Visual Studio Team Services/TFS or a file share.
Usually it should be a package and be used in a deploy task such as Deploy: WinRM - IIS Web App Deployment or Azure App Service Deployment to achieved the deployment.
1) Can transforms be engaged in both Builds and Releases?
Yes, you could also do this in a build pipeline with the useage of build deploy task. You need to add the task after the publish build artifacts task.
2) Does TFS 2017 require a lot of special handling to engage a transform file?
update
The BuildConfiguration variable is different in TFS 2017, it's inside
the MSBuild task! Transforms are now applied according
to the MSBuild task Configuration setting.
Edit the .proj file is a method to do the transform. If you don't need to change the transform, it will auto do it during the build.You could also use some 3-rd party task/extension for extra transform such as: XDT Transform
Usually we separate the build and release for the deployment, cause it's easy to configure multiple environments and easy to debug issue. You definitely could do this only in build but with a bloated process. You could refer this tutorial: Build and Deploy Azure Web Apps using Team Foundation Server/Services vNext Builds.
For a separate build and release solution, you could take a look at this blog: Using web.config transforms and Release Manager – TFS 2017/Team Services edition
Since EPiServer 7 upgrading to a newer version has involved:
Updating all EPiServer.* NuGet packages
Running PM > Update-EPiServer - to upgrade the local database
Running PM > Export-EPiServer - to produce a set of database upgrade script files that can be run on other servers.
However if only the upgraded EPiServer solution is built and deployed by Octopus Deploy, the database will not be upgraded meaning the site will not run.
Currently I run the EPiServerPackage manually on a server in each of our environments after a deployment.
I'm trying to decide on the cleanest way to include the /EPiUpdatePackage folder and contents running the Export-EPiServer command produces so that it will:
Checked into source control
Turned into a NuGet package on the build server
Be deployed by Octopus Deploy so that it can be remotely executed on the server the script is deployed to
As per Eric Herlitz suggestion, I have simply used the <episerver.framework updateDatabaseSchema="true"> in the web.config transforms for the environments I wish to have the database automatically upgraded on.
I'm unsure it this will present a problem if the SQL connection string user does not have the required level of permissions. However in my case, this is working correctly.
I have create a sample ASP.NET 5 application (pretty much the example one from New Solution), and pushed it to GIT hosted on Visual Studio Team Services (former Visual Studio Online). I want to set up continuous integration to Azure Web App (former Azure Web Site). I have tried to set it up from Azure portal itself, it did create a new build definition, but it fails to build ASP.NET 5. I have found a guide how to do this, but it never really worked for me, I get errors like this e.g.
Error parsing solution file at C:\a\1\s\Frontend\src\Frontend\Frontend.xproj: Exception has been thrown by the target of an invocation.
Predefined type 'System.Void' is not defined or imported
Another problem is that it seems it really takes a lot of time to install dnvm, get packages, etc. So all in all it's a pain to make it work.
So are there real alternatives for that or more importantly is Microsoft is planning to implement something like a Build ASP.NET 5, Deploy ASP.NET to Azure and such to make it easy as I suppose it's easy with the current ASP.NET 4 apps. I really hope that it will be an option soon since it's quite impossible to work with current build system.
For "System.Void" issue, please check the runtime version in "global.json" file and make sure it is consistent with the dependencies in "project.json" file.
For dnvm install issue, since AspNet5 runtime environment isn't installed on VSTS Hosted Build Agent for now and the different users may use different runtime versions, it requires the user to add a "PreBuild" PowerShell step to read the runtime version in "global.json" file and then install it. If you can make sure that you will always only use one version (For example: 1.0.0-rc1-update1), you can deploy your own build agent and install "1.0.0-rc1-update1" on it, then you can skip the dnvm installation during the build process.
Take a look on http://riffer.eu/wordpress/?p=112. There I have a solution vor asp.net core RC_1.
Amazingly you need only two powershell scripts - there is no compiling / visual studio necessary.
I am trying to build a continuous integration server on a Windows 7 machine. I can run the msbuild script cleanly on that machine but when I attempt to run it via a build agent the registration of certain COM (.NET and c++) components fail seemingly to do with write permissions to the registry. I have turned off UAC but it makes no difference. Normally if I build the msbuild script locally I have to run the command prompt with elevated permissions, but on a build server I am not sure what to do.
I have seen posts suggesting that the way is to remove the automatic registration from the project setup, and rely on the install to do this. This seems to make it this option rather limited and the solution incompatible with running from an IDE. Has anyone found a way through this?
We are using vs2010 as the client on the build server, and the TFS server is vs2008
Add your build service user into Administrators user group. It seems like your account has more permissions as build agent/service user.