service-fabric
service-fabric copied to clipboard
Temp file blocks the deployment
Deploy service fabric service to On Premise... Service fabric publish profile path: .\PublishProfiles\Cloud.xml Exiting due to error. The file 'C:\Users\Admin\AppData\Local\Temp\TestApplicationPackage_2774593837505\fzgjryjo.bez\Release\ConnectLabs.Bookin g.Engine.WebApiPkg\Config\Settings.xml' already exists. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
I am getting this error how do I get rid of this ?
Similar Question here https://stackoverflow.com/questions/54207286/test-servicefabricapplicationpackage-settings-xml-already-exists
@rifaterdemsahin Can you try with deleting the folder ; C:\Users\Admin\AppData\Local\Temp\TestApplicationPackage_2774593837505
?
@rifaterdemsahin Can you try with deleting the folder ;
C:\Users\Admin\AppData\Local\Temp\TestApplicationPackage_2774593837505
?
Thanks for the suggestion, but I believe this folder is generated on the fly during the Test-ServiceFabricApplicationPackage phase. So I need to modify the scripts that come with SF SDK, which I am not sure if it is desired in the long run.
You cannot overwrite the script in a way so that it does not use that folder. The suggestion is mainly to unblock you and enable further deployments. We have had issues with Windows file ownership in other scenarios, can you please check if that's enabled on your temp folder? https://blogs.technet.microsoft.com/cbernier/2017/05/19/windows-information-protection-explained-windows-10-creators-update/
I have realized that i am creating the files at the deployment and reusing the same folders is the issue.As the deployment puts a zip folder there. The reason i cant see them in temp is they are located in my packages in the form of zip files.
@rifaterdemsahin Can you please share how you resolved the issue? I have the same problem, trying to deploy a zipped package, where I am running Test-SF and then Publish-NewSF.
@rifaterdemsahin Could you provide more details about your workaround?
Do we know if any progress has been made on this?
I am not able to deploy to Service Fabric (on Azure) using a Self-Hosted VM build agent; this is totally blocking me.
@andyofengland: what task are you running? What's the error? What's installed on the self-hosted agent?
The agent has only build tools on it, Windows, docker, ms build tools, service fabric sdk and the likes.
They are not domain joined either and don't have the abore mentioned management tools on them.
As for task - it’s the yaml task to deploy a sfab application. Same error as quoted above.
The YAML is:
- task: ServiceFabricDeploy@1
displayName: 'Deploy Service Fabric Application'
inputs:
applicationPackagePath: '$(AGENT.BUILDDIRECTORY)/drop/application/applicationpackage'
serviceConnectionName: '${{parameters.serviceFabricConnectionName}}'
publishProfilePath: '$(AGENT.BUILDDIRECTORY)/drop/application/projectartifacts/xxxx/PublishProfiles/Cloud.xml'
applicationParameterPath: '$(AGENT.BUILDDIRECTORY)/drop/application/projectartifacts/xxxx/ApplicationParameters/Cloud.xml'
overrideApplicationParameter: true
The error message itself is:
##[error]The file 'C:\windows\ServiceProfiles\NetworkService\AppData\Local\Temp\TestApplicationPackage_793198001433\n5xy2dv0.4ya\applicationpackage\xxxx.Internal.ApiPkg\Config\Settings.xml' already exists.
##
The pipeline task downloaded for SFab is:
##[debug]Task 'ServiceFabricDeploy' already downloaded at 'C:\agent\_work\_tasks\ServiceFabricDeploy_c6650aa0-185b-11e6-a47d-df93e7a34c64\1.8.0'.
Error stack:
##[debug]Script stack trace:
##[debug]at Publish-NewServiceFabricApplication, C:\agent\_work\_tasks\ServiceFabricDeploy_c6650aa0-185b-11e6-a47d-df93e7a34c64\1.8.0\ServiceFabricSDK\Publish-NewServiceFabricApplication.ps1: line 243
##[debug]at <ScriptBlock>, C:\agent\_work\_tasks\ServiceFabricDeploy_c6650aa0-185b-11e6-a47d-df93e7a34c64\1.8.0\deploy.ps1: line 194
##[debug]at <ScriptBlock>, <No file>: line 1
##[debug]at <ScriptBlock>, <No file>: line 22
##[debug]at <ScriptBlock>, <No file>: line 18
##[debug]at <ScriptBlock>, <No file>: line 1
##[debug]Exception:
##[debug]System.IO.IOException: The file 'C:\windows\ServiceProfiles\NetworkService\AppData\Local\Temp\TestApplicationPackage_34128311289\ldazj0la.piq\applicationpackage\xxx.ApiPkg\Config\Settings.xml' already exists.
##[debug] at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
##[debug] at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
##[debug] at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
##[debug] at System.IO.Compression.ZipFileExtensions.ExtractToFile(ZipArchiveEntry source, String destinationFileName, Boolean overwrite)
##[debug] at System.Fabric.Management.ImageBuilder.ImageBuilderUtility.ExtractFromArchive(String archiveFilePath, String srcFilePath, String destFilePath)
##[debug] at System.Fabric.Management.ImageBuilder.ApplicationProvisionOperation.<ParseConfigPackageAsync>d__20.MoveNext()
##[debug]--- End of stack trace from previous location where exception was thrown ---
##[debug] at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
##[debug] at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
##[debug] at System.Fabric.Management.ImageBuilder.ApplicationProvisionOperation.<CreateServiceManifestAsync>d__16.MoveNext()
##[debug]--- End of stack trace from previous location where exception was thrown ---
##[debug] at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
##[debug] at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
##[debug] at System.Fabric.Management.ImageBuilder.ApplicationProvisionOperation.<ParseServiceManifestAsync>d__15.MoveNext()
##[debug]--- End of stack trace from previous location where exception was thrown ---
##[debug] at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
##[debug] at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
##[debug] at System.Fabric.Management.ImageBuilder.ApplicationProvisionOperation.<ParseApplicationPackageAsync>d__14.MoveNext()
##[debug]--- End of stack trace from previous location where exception was thrown ---
##[debug] at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
##[debug] at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
##[debug] at System.Fabric.Management.ImageBuilder.ApplicationProvisionOperation.<ProvisionApplicationAsync>d__13.MoveNext()
##[error]The file 'C:\windows\ServiceProfiles\NetworkService\AppData\Local\Temp\TestApplicationPackage_34128311289\ldazj0la.piq\applicationpackage\xxx.ApiPkg\Config\Settings.xml' already exists.
##[debug]Processed: ##vso[task.logissue type=error]The file 'C:\windows\ServiceProfiles\NetworkService\AppData\Local\Temp\TestApplicationPackage_34128311289\ldazj0la.piq\applicationpackage\xxx.ApiPkg\Config\Settings.xml' already exists.
##[debug]Processed: ##vso[task.complete result=Failed]
Cheers
As a short term workaround - until Microsoft fix the issue formally, I've managed to mitigate the problem...
What was needed was to ensure that the workspace was cleaned before each and every action involving the application. Build and each release stage.
My specific instance was when using the multi-stage YAML file for build and deployment so adding in a workspace: clean was what was needed.
I still have a support ticket with Microsoft for a more formal fix.
This bug is open and still happening almost 3 years later, folks. Today I'm hitting it EVERY TIME for the same SF service deployment. It's a fresh VM on each run and a different path on each failure.
2021-10-13T20:05:37.1277583Z ##[section]Starting: XbvtWebApi: Deploy Service Fabric Application 2021-10-13T20:05:37.1378569Z ============================================================================== 2021-10-13T20:05:37.1378909Z Task : Service Fabric application deployment 2021-10-13T20:05:37.1379209Z Description : Deploy an Azure Service Fabric application to a cluster 2021-10-13T20:05:37.1379454Z Version : 1.9.4 2021-10-13T20:05:37.1379666Z Author : Microsoft Corporation 2021-10-13T20:05:37.1379983Z Help : https://docs.microsoft.com/azure/devops/pipelines/tasks/deploy/service-fabric-deploy 2021-10-13T20:05:37.1380349Z ============================================================================== 2021-10-13T20:05:39.0211392Z Searching for path: D:\a_work\1\XbvtWebApi\deployment\PublishProfiles\Cloud_Dev2.xml 2021-10-13T20:05:39.0463690Z Found path: D:\a_work\1\XbvtWebApi\deployment\PublishProfiles\Cloud_Dev2.xml 2021-10-13T20:05:39.0777320Z Searching for path: D:\a_work\1\XbvtWebApi\applicationPackage 2021-10-13T20:05:39.2733854Z Found path: D:\a_work\1\XbvtWebApi\applicationPackage 2021-10-13T20:05:39.4097885Z Imported cluster client certificate with thumbprint 'XXX'. 2021-10-13T20:05:39.8667307Z Successfully connected to cluster. 2021-10-13T20:05:39.8976739Z Searching for path: D:\a_work\1\XbvtWebApi\deployment\ApplicationParameters\Cloud_Dev2.xml 2021-10-13T20:05:39.9057298Z Found path: D:\a_work\1\XbvtWebApi\deployment\ApplicationParameters\Cloud_Dev2.xml 2021-10-13T20:05:39.9064482Z Overriding application parameter file specified in publish profile with 'D:\a_work\1\XbvtWebApi\deployment\ApplicationParameters\Cloud_Dev2.xml' specified in the Azure Pipelines task. 2021-10-13T20:05:39.9077725Z Overriding upgrade settings specified in publish profile with the settings specified in the Azure Pipelines task. 2021-10-13T20:05:39.9233813Z Service fabric SDK version: 5.1.335.9590. 2021-10-13T20:05:42.6946233Z ##[error]The file '\?\C:\Users\cloudtest\AppData\Local\Temp\TestApplicationPackage_137979119737\n14bb0xp.bxf\applicationPackage\XbvtWebApiPkg\Config\Settings.xml' already exists. 2021-10-13T20:05:42.7368914Z ##[section]Finishing: XbvtWebApi: Deploy Service Fabric Application
Any updates on this?
Are there specific steps taken when this action is called within a MS Cloud Hosted agent that we could potentially also implement in our self-hosted agents?
This does not occur on cloud-hosted agents, only when we migrated to self-hosted.
Any resolution for this issue please, I am seeing this issue now and it's a big blocker