I have a CD task setup for each of the 4 services in Azure Service Fabric using VSTS. Following is the configuration for all 4 tasks (except they point to different folders for different services) :
Problems :
1.For the first two applications, even though I have checked "Skip upgrade for same Type and Version", I am noticing that the task still removes the application, unregisters the type and redoes it for the same application type and version. Here are the sample logs :
2018-01-24T02:48:36.6728272Z Overriding application parameter file specified in publish profile with 'd:\a\r1\a\drop\retail\amd64\RIPP\Deploy\PublishEventApplication\ApplicationParameters\DEV.xml' specified in the VSTS task.
2018-01-24T02:48:39.4305864Z An application with name 'fabric:/PublishEvent' already exists in the cluster with application type 'PublishEvent' and version '6.00.9810c873d83e992c104fdcfb125916caa718500a.0'. Removing it.
2018-01-24T02:48:43.9333176Z Remove application instance succeeded
2018-01-24T02:48:44.3244542Z Application type 'PublishEvent' and version '6.00.9810c873d83e992c104fdcfb125916caa718500a.0' was already registered with the cluster, unregistering it...
2018-01-24T02:48:48.8107130Z Unregister application type succeeded.
2018-01-24T02:48:48.8153978Z Copying application to image store...
2018-01-24T02:48:53.7676773Z Upload to Image Store succeeded
2018-01-24T02:48:53.7694089Z Registering application type...
2018-01-24T02:49:05.0363332Z Register application type succeeded
2018-01-24T02:49:05.0397398Z Removing application package from image store...
2018-01-24T02:49:05.3268514Z Remove application package succeeded
2018-01-24T02:49:05.3283533Z Creating application...
2.For the next two applications, the deployment fails with the following error :
2018-01-24T02:49:46.7483127Z Overriding application parameter file specified in publish profile with 'd:\a\r1\a\drop\retail\amd64\RIPP\Deploy\StreamReservoirApplication\ApplicationParameters\DEV.xml' specified in the VSTS task.
2018-01-24T02:49:48.2340310Z ##[error]An application with name 'fabric:/streamreservoir' already exists, its type is 'streamreservoir' and version is '6.00.7af146b1e9f1084401198b96d7eaf0cacec455f8.0'. You must first remove the existing application before a new application can be deployed or provide a new name for the application.
My assumption is that in case of all the four services :
Deployment should be skipped since the application type, name and version are the same.
If the version is different, the application should be upgraded (not removed and added again).
And finally, only if name and type is different then old one should be removed and new one should be added.
Try checking 'Override all publish profile upgrade settings' to configure upgrade settings.
Or, as you said:
The other option is to use the settings directly in the publish profiles. So simply checking "Skip upgrade for same type and version" doesn't do anything unless you have upgrade settings either overridden or in the publish profiles
Related
The concrete question
For those who just want the direct questions:
Is there a way to temporarily disable default services on a ServiceFabric application type so that a new application can be installed (using Powershell) without automatically installing any default services?
A proposed solution here is to remove the default services from the manifest and later restoring them. I am able to write a PowerShell script to adjust the application manifest accordingly, but how do I update the application type using Powershell - assuming I already have altered the manifest?
Any solution that solves the contextual problem without requiring manual config meddling is acceptable - my proposed solution is probably not the only possible solution. We do explicitly want to avoid manual meddling.
When allowing meddling, we are already able to just comment out the default services when we need to. We're specifically looking for a solution that requires no meddling as this reduces bugs and debugging issues.
The context
I'm running into an issue with using the application manifest's default services during local development.
I am aware of the general "don't use default services" advice, and it is being followed. During CI build, the default services are removed and will not be relied upon for any of our clusters in Azure. The only exception here is local developer machines, which use default services to keep the developer F5 experience nicer by enabling all services when starting a debug session.
We have written specialized scripts that provision a new tenant (SF application) with their own set of services (SF service). Not every tenant should get every service, we want to opt-in to the services, which is what the script already does (based on a mapping that we manage elsewhere, which is not part of the current question as the provisioning script exists and works).
However, when default services are enabled, every tenant already gets every service and the actual opt-in provisioning is useless. This is the issue we're trying to fix.
This same script works in our production cluster since there are no default services configured there. The question is solely focus on the local development environment.
Essentially, we're dealing with two scenarios during local development:
When debugging, we want the default services to be on because it allows us to run all of our services by pressing F5 (and not requiring any further action)
When testing our provisioning script, we don't want default services because it gets in the way of our selective provisioning behavior
I'm aware that commenting the default services out of the manifest solves the issue, but this requires developers constantly toggling the content of the manifest and reinstalling the application type, which we'd like to avoid.
Ideally, we want to have the default services in the manifest (as is currently the case) but then have the provisioning script "disable" the default services for its own runtime (and restore the default services before exiting), as this gets us the desired behavior in both cases.
What is the solution that requires the least manual developer meddling to get the desired behavior in both scenarios?
I'm currently trying to implement it so that the provisioning script:
Copies the application manifest to a backup location
Removes the default services from the real manifest
Updates the application type using the new manifest (i.e. without default services)
Runs the provisioning logic
Restores the real manifest using the backup manifest from step 1
Updates the application type using the restored manifest (i.e. with default services)
It is specifically steps 3 and 6 that I do not know how to implement.
Consider having two sfproj projects in the solution. One with default services, one without.
Also look into using a start-service.ps1 script instead of default services. This way the two projects can use the same application manifest.
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-debugging-your-application#running-a-script-as-part-of-debugging
Failed to deploy web package to IIS website
I have created one ASP.NET Core application and Azure DevOps continuous integration (CI) and continuous delivery (CD) pipeline.
I have created and configure the Self-hosted Windows agents in my local machine as a service. It is working as expected.
When I run the CI/CD pipeline for the first time it is working successfully, and the web application published to my local IIS successfully.
The issue is when I commit another update to Azure DevOps git repository it is failed to deploy web package to my local IIS website with the following errors and warnings
2019-08-21T10:56:59.1480862Z ##[error]Failed to deploy web package to IIS website.
2019-08-21T10:56:59.1492670Z ##[warning]Can\'t find loc string for key: Trytodeploywebappagainwithrenamefileoptionselected
2019-08-21T10:56:59.1493093Z ##[warning]Trytodeploywebappagainwithrenamefileoptionselected
2019-08-21T10:56:59.1493421Z ##[error]Error Code: ERROR_FILE_IN_USE
More Information: Web Deploy cannot modify the file 'DemoWebApp.dll' on the destination because it is locked by an external process. In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish attempt. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
Error count: 1.
I have configured the appOffline rule in the publishing profile (.pubxml) and add the EnableMSDeployAppOffline element to the PropertyGroup like this:
<PropertyGroup>
<EnableMSDeployAppOffline>true</EnableMSDeployAppOffline>
</PropertyGroup>
As described in More Information’s learn more URL http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
Still it is failed to deploy web package to my local IIS website with the same errors and warnings.
When I trying to redeploy manually few times then it is working successfully other wise failed with same errors and warnings. Because I think the file is locked for some time in my local machine process.
It is also working successfully when I manually delete all the files from IIS release folder with that locked file.
Needs help, the file is locked by any one local process. I couldn’t find that local process. I couldn’t figure out the issue. I also don’t know if I found that process any how then how to figure out the issue. Is this just local issue?
Can anyone help me out?
Recycle the application pool immediately before your 'Deploy IIS App' task.
Add a 'WinRM - IIS Web App Management' task to you release pipeline. Set the Configuration type to 'IIS Application Pool', set the 'Action' to Recycle, and type in the app pool name in the 'Application pool name' field.
The recycle should unlock the dll and allow it to be deleted and replaced in the deployment step.
I encountered this same error despite having the Take App Offline option set for ages. That can't be the solution. There's some phantom bug going on here, but I did get it resolved without rebooting the server.
In PROCMON, I searched Associated Handles for the file in use. There were none.
I tried deleting the app's DLL file outright; an error message said it was in use by w3wp.exe even though the website was offline and the app pool stopped.
I confirmed this by opening IIS and looking at the worker processes panel. None of the active w3wp.exe PIDs were related to the application I was trying to update.
I opened PROCMON and sorted by Image name to find any W3WP.exe instances still running. There was one Suspended instance that it wouldn't let me terminate (despite running PROCMON as an admin/with elevation). It simply said "Access is denied."
I restarted the Agent on the server via the Services window.
At that point, I was able to delete the application DLL from the target directory and deploy normally from DevOps pipelines.
Hopefully this doesn't happen in production.
I had the same error .
I splved by checking the "enable IIS" to my task , like this :
Now my lob suuccseded
I was deploying my web app on local iis using IIS Web App Deploy task.I was able to reproduce the same error. I found this error occurred if i was visiting my website when i was trying to deploy a new version. And the deploy task failed to update the .dll file, since it was in use.
I fixed this error by checking this option “Take App Offline”, See below pic.
Please let me know If you are using different tasks to deploy your web app.
Similar questions have been asked various times, but most answers are old and may only partially apply. This question is specific to using Web Deploy through Azure DevOps/Azure Pipelines using the "Azure App Service Deploy" task, version 3.*.
Failed to deploy web package to App Service.
Try to deploy app service again with Rename locked files option selected.
Error Code: ERROR_FILE_IN_USE
More Information: Web Deploy cannot modify the file 'VBCSCompiler.exe' on the destination because it is locked by an external process. In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish
attempt. Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
There's two recommendations there:
Select "Rename locked files" option
Restart the application
Use the AppOffline rule
Additionally, the documentation for the task reiterates recommendations 1 and 3 together.
For avoiding deployment failure with error code ERROR_FILE_IN_USE, in case of .NET apps targeting Web App on Windows, ensure that 'Rename locked files' and 'Take App Offline' are enabled. For zero downtime deployment use slot swap.
However, these recommendations are already in place.
All that's left is recommendation 2: restart the service. For many reasons, I rather not have to fall back to this.
Why are 1 and 3 not enough to complete the deployment successfully?
I spoke with a Microsoft support rep and was told that "Rename locked files" only works for DLLs.
But I did find a solution that did work for me. In "Additional arguments", I added "-useChecksum". So the "Deploy Azure App Service" task now looks like this
I haven't had any problems since.
There is an issue tracked here : Azure App Service Deploy fails for .net core 2.0 with ERROR_FILE_IN_USE and based on vincentdass's comment "PR #8457 for consuming new version of MSDeploy as per Web Deploy team recommendation." There will be an upgrade for msdeploy in future version.
However you can just checking Publish Using Web Deploy and Rename Locked Files, then creating a new deployment. Redeploy won't work because it won't pick up your changes to the release definition.
Reference below thread, you can check the discussion about this issue and troubleshoot accordingly.
Azure App Service Deploy fails for .net core 2.0 with
ERROR_FILE_IN_USE
I have an application that was pushed to the Liberty runtime via the packaged server deployment method and I understand that some of the default features provided by Liberty will change in one of the upcoming buildpack updates. Will this change in default features provided adversely affect my packaged server deployment?
If you're deploying/restaging your application in a manner other than a packaged server or a server directory, then the change in the default feature set might affect your application. This is due to the changes in spec levels in the new default feature sets. However, if you used the "packaged server" or the server directory method for deploying your app then you will not be affected. This is because the features you put in your server.xml will still get picked up due to the fact that the buildpack will provide Java 6 & 7 features.
If you need more information about the new default features added to the buildpack, how to make your app resilient to the changes, and even how to "preview" the new buildpack for testing purposes, see the link below:
https://developer.ibm.com/bluemix/2015/09/08/upcoming-liberty-for-java-buildpack-changes/
I have developed a feature using sharepont 2010, feature Scope is "Web", feature Deployment Target is "WebApplication"(Deployement Target has been set throw Package->Advanced->Add->Add Assembly from Project Output->Deployment Target as "WebApplication).
In this feature using "SPWebConfigModification" class updating web.config file.
My concern is below:
1)After deploying it should go to particular "web" since its a "WebApplication" deployemnt but this feature is availabe in all the web apllication in the server, even though if we go to Central Admin->System Setting->Manage Farm solution, we can see this .wsp file has been deployed to particular web application not Globally Deployed. I think this looks strange. My requirement is, the feature should be available in one web application not in all web application. Can somebody point me out pls whats wrong in this or how can we do this?
This has to do with the property ActivateOnDefault in the feature manifest file, this property ONLY applies to features scoped at Farm and Web Application levels. Any feature (Farm or WebApplication) with that setting set to True will automatically activate on all web applications when you deploy the WSP solution. This property is set to true by default.
Read more about it here:
http://www.sharepoint.bg/radi/post/Activate-on-Default-confusion-and-features-scoped-at-Web-Application-level.aspx