Hi guys,
Recently I faced a strange issue and figured out a solution as well so thought to share it because I didn't find much over the web about it.
We have created the TFS Build System built for on premise TFS server. We are using it for continuous deployment on Windows Azure Cloud Services and everything is working fine. There is an excellent documentation available here on MSDN so you can take a look at it.
What was the error?
The issue came in when build stopped working , prior builds were successful but we started facing issue with each new build.
Error Message was - Set-AzureDeployment : Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host.
Actually in the background - build process has a workflow and it tries to execute an PowerShell command on build server for deployment of your cloud services in Windows Azure.
What is the solution?
The way build process workflow works is - it needs the .publishsetting file for doing deployments on your Azure Cloud Services.
All you need to do is , download the .publishsetting file for your Azure subscription (you can click here) and save it locally. Now go to the build server and replace your old .publishsetting file with this new one.
Now try queuing your builds - everything should work fine (If It would have worked before :) ).
If you are not using the build system but only using the PowerShell command i.e. Set-AzureDeployment to do the deployment then also you can opt the same solution , i.e. just download and replace your old .publishsetting file with new one.
Another solution
Now , even though the solution mentioned above worked for me fine - but I faced similar issue on another environment few days after I written this post and above solution didn't work so had to search for solution again and found a workaround.
So thought to edit the blog post and document this workaround so that it helps someone.
The changes needs to be done in the script - what this changes is - try to upload the cspkg file to blob storage and the create / updnate the deployment using blob url.
You can define the new variable $containerName at top of your file and initialize with some string value which will act as container name.
# If the target container does not already exist, create it.
$containerState = Get-AzureStorageContainer -Name $containerName -ea 0
if ($containerState -eq $null)
{
New-AzureStorageContainer -Name $containerName | out-null
}
Set-AzureStorageBlobContent -File $packageLocation -Container $containerName -Blob $blob -Force| Out-Null
$script:packageLocation = (Get-AzureStorageBlob -blob $blobName -Container $containerName).ICloudBlob.uri.AbsoluteUri
Hope this helps someone.
Recently I faced a strange issue and figured out a solution as well so thought to share it because I didn't find much over the web about it.
We have created the TFS Build System built for on premise TFS server. We are using it for continuous deployment on Windows Azure Cloud Services and everything is working fine. There is an excellent documentation available here on MSDN so you can take a look at it.
What was the error?
The issue came in when build stopped working , prior builds were successful but we started facing issue with each new build.
Error Message was - Set-AzureDeployment : Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host.
Actually in the background - build process has a workflow and it tries to execute an PowerShell command on build server for deployment of your cloud services in Windows Azure.
What is the solution?
The way build process workflow works is - it needs the .publishsetting file for doing deployments on your Azure Cloud Services.
All you need to do is , download the .publishsetting file for your Azure subscription (you can click here) and save it locally. Now go to the build server and replace your old .publishsetting file with this new one.
Now try queuing your builds - everything should work fine (If It would have worked before :) ).
If you are not using the build system but only using the PowerShell command i.e. Set-AzureDeployment to do the deployment then also you can opt the same solution , i.e. just download and replace your old .publishsetting file with new one.
Another solution
Now , even though the solution mentioned above worked for me fine - but I faced similar issue on another environment few days after I written this post and above solution didn't work so had to search for solution again and found a workaround.
So thought to edit the blog post and document this workaround so that it helps someone.
The changes needs to be done in the script - what this changes is - try to upload the cspkg file to blob storage and the create / updnate the deployment using blob url.
You can define the new variable $containerName at top of your file and initialize with some string value which will act as container name.
# If the target container does not already exist, create it.
$containerState = Get-AzureStorageContainer -Name $containerName -ea 0
if ($containerState -eq $null)
{
New-AzureStorageContainer -Name $containerName | out-null
}
Set-AzureStorageBlobContent -File $packageLocation -Container $containerName -Blob $blob -Force| Out-Null
$script:packageLocation = (Get-AzureStorageBlob -blob $blobName -Container $containerName).ICloudBlob.uri.AbsoluteUri
Hope this helps someone.
