Where can I download the latest version of Microsoft.TeamFoundation.DistributedTask.Task.Deployment.dll for a release on Azure DevOps?
Microsoft-hosted agents are regularly updated to make sure the latest and applicable images of the softwares are applied to the agents.
If you want to use the latest version of softwares to run the related pipeline tasks on DevOps,you can install the latest softwares on the agents which you used .
If the agent you used is privated agent, you need to manually install or upgrade all the softwares you request on the agent machine.By downloading the latest package from Internet or using the related commands to install/upgrade the softwares.
You can refer to this case for details.
For other SO users could get clearly know more details about this issue when they are checking to this ticket, I add the following ticket which relevant with this ticket:
SO forum: Register-Environment Failing
DC forum: Where to download latest versions of deployment utilities for azure pipeline tasks?
When you using the task(such as AzureFileCopy V1.*) which need/import the Microsoft.TeamFoundation.DistributedTask.Task.Deployment.dll file, no matter whether the agent you used is hosted agent or private agent, its version are always be the latest version to the task, because these dll files are all exists depend with task.
According to the content you shared in the DC forum ticket:
I suspect that there's a newer version of these with a newer version
of Register-Environment, because with my version of this PowerShell
module, the following line fails claiming that I'm missing parameters,
specifically a "taskContext."
the error you are facing caused by the configuration of the Microsoft.TeamFoundation.DistributedTask.Task.Deployment.dll file. We did not defined the parameter taskContext in it.
To check and verify it, you can execute the PowerShellOnTargetMachines v2.* task in your private agent, then find the dll file in the path of ~\_work\_tasks\PowerShellOnTargetMachines_3b5693d4-5777-4fee-862a-bd2b7a374c68\2.0.7\DeploymentUtilities. And also, you can see its version is 16.0.0.0.
Then you can use decompile tool, here what I am using is Reflector, to decompile this dll file.
You can see that in the script block of RegisterEnvironmentCmdlet, there does not have parameter taskContext defined in it.
When you use PowerShellOnTargetMachines v2.* task, the parameter for Register-Environment supported only include EnvironmentName, EnvironmentSpecification, UserName, Password, WinRmProtocol, TestCertificate, ResourceFilter, ProjectName, TagsList.
For the parameter taskContext, it is the one which only used in v1.*(See v1.* source code) and does not supported in v2.*. In v1.*, taskContext used for Get-VssConnection cmdlet which dose not used any more in v2.*. That's why you facing the error message in PowerShellOnTargetMachines v2.* task.
Related
came in last week and our azure devops pipeline (for building a .net desktop app) was breaking on some tasks. First one was ##[error]File not found: 'C:\agent_work_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.199.0\ps_modules\VstsTaskSdk\VstsTaskSdk.psd1', which was using VS Build task Version 1.199.0
noticed the succeeding runs prior to this were using VS Build task version 1.166.2. Looks like the folder \ps_modules\ exists in 1.166.2 but not the 1.199.0 that the pipeline is now insisting it use. Any recommendation here? Something seems out of sync- either need to update something else or that folder and its contents were mistakenly excluded with the new task version?
I specified the task version to use in the pipeline (VSBuild#1.166.2), but then got ##[error]File not found: 'C:\agent_work_tasks\PowerShell_e213ff0f-5d5c-4791-802d-52ea3e7be1f1\2.200.0\ps_modules\VstsTaskSdk\VstsTaskSdk.psd1' for a powershell task. Specified to use the prior version of that task as well, and then it also started to work. Notably that task folder is also missing the ps_modules folder in the new version (2.200.0), while the prior version of 2.180.1 has it
So obviously I'm missing something here. I got my pipeline to work for the time being, but why does it default to calling the newer task versions that seem to be missing resources? Any suggestions?
I'm trying out Powershell DSC as a way of automating deployments. We have an EXE installer created by Installshield for a server application, and need to ensure the latest version is installed.
Installshield guidelines (http://www.flexerasoftware.com/producer/resources/white-papers/is-msipatches.html) suggest that the Package Code should change for every build, the Product Code should stay the same between minor versions, and the Upgrade Code should always stays the same.
Is there a way of telling Powershell DSC to install a particular minor version, i.e. to make sure that the Package Code matches exactly?
I'm using the following to create the MOF, but when I run it, it detects the Product as already installed and doesn't do anything, even though it's a different Package.
Package MyApp
{
Ensure = "Present"
Name = "MyApp"
Path = "\\path\to\specific\version\of\setup.exe"
ProductId = ''
Arguments = "/V`"ADDLOCAL=ALL /qb`""
}
The package resource will declare the resource as correctly configured if the package is already installed. So it will not work for your specific scenario. You will have to write a custom package resource or extend the existing one. If you want to modify feel free to fork this repository and extend the functionality https://github.com/PowerShell/xPSDesiredStateConfiguration You can also open an issue for someone to pick up and fix the same.
Greeting to everyone!
I'm trying to start use of Teamcity Unity3d-runner-plugin.
After Successful install on server and setup build step in project
, it is unable to build project.
Project doesn't start to work with warning message:
Warning: No enabled compatible agents for this build configuration. Please register a build agent or tweak the build configuration requirements.
on the Agent Requirement page there is a message
agent (disconnected)
Incompatible runner: Unity
Unmet requirements: unity.latest exists
Unity was installed in default folder, and works fine with no problem, that's why i can't understand, why does plugin can't see Unity env.parameter on agent.
Anyone know how can it be solved?
The message (unity.any exists) suggests that it's not missing an environment variable (if it were missing a %UNITY% environment variable, it would be complaining about env.UNITY). Instead, it seems to be looking for a build-agent property called unity.any.
To define the unity.any build-agent property on your agent, edit the agent properties file at <agent home>/conf/buildAgent.properties, adding a line like this:
unity.any=1
(Read more here.)
I guess whoever wrote the plugin decided that there was no good way (for the TeamCity server) to tell if Unity is installed on any given agent, so the user (you) has to specify this by defining this agent property. Thus, by creating that line you're marking your agent as having Unity installed.
I think the properties file is reread periodically so you needn't restart the agent after you've added the line.
(If this helps, check the plugin's documentation and let the plugin author know if this information is missing.)
We have a few VMs in Azure and we rely on the PowerShell DSC extension to deploy our code to the machines. I want to make sure that this extension is not updated automatically so that our code that uses functionality from this extension don't break without we knowing about it first.
The problem is that we have some deployment scripts that read the extension's status codes/messages and do custom logic based on them. When the extension was updated from 1.4.0.0 (which is the version that the plugin was on when we first started using it) to the version 1.5.0.0, some of the status messages changed and our script stopped working. This completely broke our deployment process and we had to do an emergency update on our scripts to be compatible with v1.5. Now that version 1.7.0.0 was released the same exact problem happened again. Some new status codes were added and I had to update our scripts or we would not have a working deployment pipeline.
Is it possible to specify a manual update process for these extensions? Their installation and update seem to be completely automated. Ideally, I'd like to be able to update them on a case by case basis after testing our scripts against the newer versions first, so that our deployment process is not halted because of that. Bonus points for anyone who manages to find up to date documentation or some kind of release notes document for this extension in particular, as I could find none... I was just surprised to see that version 1.7 was installed today when I got an error from our script, and was lucky to know exactly where to look for the status changes.
The default behavior for the DSC extension handler is to update to the latest version. If you want to tie yourself down to a specific version, then you can do so with the following cmdlet (currently there is no provision from the UI)
Set-AzureVMDscExtension -Version
Please note that we are also try to ensure updates do not cause issues. We are not there yet but we would certainly like to get there so everyone is automatically updated.
I am deploying web application to azure using TFS CI automated build deployment.
In our config maintain build version like 2014.05.19.1 which is $(Date).$(rev) format.
All I want to update config each time build is deployed.For that I am passing value to 'BuildVersion' parameter in template to powershell script which actually performs publishing to azure.
I tried using $(Date:yyyyMMdd)$(Rev:.r) but it is considered string as it is.
I want to get current build version just like IBuildDetail.BuildNumber
within template.
My question is how to get the build version?
If you are using Invoke Process, instead of passing value for BuildVersion parameter you can directly use 'BuildDetail.BuildNumber' in parameters for process like
String.Format("-BuildNumber ""{0}""",BuildDetail.BuildNumber)
This would give the required build number.
If your PowerShell script is being executed from your TFS build, it should have access to the environment variables specific to the TFS context of the build. If that is the case, you actually don't need to pass the $(BuildVersion) parameter to the script, as it already is accessible to the PS script in the $env:TF_BUILD_BUILDNUMBER environment variable. Try testing something like $env:TF_BUILD_BUILDNUMBER | Out-File "D:\Dev\BuildNumber.txt" in your script. You should hopefully see the file containing your build number after running your build.
(I am assuming you are using a relatively new build process template...one that contains the "Post-Build script path" parameter, such as TfvcTemplate.12.xaml)
Hope this is helpful.
I would recommend that you use the right tool for the right job. The build system, is really only for building (compile & test). We have been using it for other things for years coz we did not have another integrated solution. However Microsoft recently bought InRelease and rebranded as Release Management for Visual Studio 2013. I have successfully integrated this with TFS 2012 as well.