When running a web deploy to a specific IIS site I get the following error:
Error: The synchronization is being stopped because the maximum number of sync passes '5' has been exceeded even though all the changes could not be applied. This could occur if there are external changes being made to the destination.
At C:\Code\.....\deploy.ps1:185 char:10
+ & <<<< ($appDeployCmd) $type /M:$url /U:$user /P:$pass /A:Basic -allowUntrusted -useCheckSum
+ CategoryInfo : NotSpecified: (Error: The sync...he destination.:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
Web Deploy is working fine on this environment against other IIS sites and file syncs are also working. I have previously been able to use web deploy to deploy this specific site without issue. All of the sudden out of nowhere, this issue started happening and I can no longer deploy this site.
I'm doing a basic site deploy with a package built from msbuild. I don't think the specifics are that important because as I said this was all working before and currently works against other sites on the same server farm without issues.
The error message says:
"This could occur if there are external changes being made to the destination."
but I'm not sure how to track this down or if it is even the issue to begin with. I've made sure all explorer windows are closed in all remote sessions. I've tried restarting the site and the app pool. The only thing I have not tried is rebooting the server which is not possible at moment.
Any ideas what might be cause this web deploy to fail?
I had the same error and the problem was my dropbox.
I was working directly in my dropbox folder, and when you publish, it causes dropbox to syncronize at the same time, which caused the error.
Disabling dropbox sync while working solved the problem.
I recon the problem also could happen with onedrive, google drive and so on.
We had this problem when converting from a previously adhoc deploy of a service to MSDeploy, and found that if there were files that were either
marked as read-only via the DOS/Windows read-only file attribute.
inaccessible due to ACLs
then we would get the "maximum number of sync passes" error on deploying.
Once we fixed the attributes/ACLs, we were able to sync.
Quick and easy way to resolve this issue is to delete the files in the destination and re-run the web deploy.
The issue seems to revolve around the ACL step of the web deploy, which attempts to change the permissions of your websites files as a safety measure intended to ensure they are not changed during a deployment.
By default Web Deploy sets the ACL of the sites anonymous user to read only while also overwriting Control Panel access to your website.
Source
You can turn of ACL in future to avoid this if you wish, but it's not really worth it. This will also speed up web deploys - but that is a separate issue.
Not really an answer, but one workaround you can try if you are using the Web Deploy dirPath, filePath, or contentPath providers is the ignoreErrors provider setting. If you know that you are consistently hitting a certain error number, you can specify that that error be ignored when it's hit. See the dirPath provider article for full details (and caveats).
In my case I couldn't fix it but realised the deployment worked regardless.
If you are reading this I wouldn't suggest to just assume it worked, and if it did that it deployed fully, but consider that it may be a false alarm!
Related
I am facing a weird problem today, when running my MuleSoft application locally from my AnypointStudio and firing a request from postman, I am getting 403 error. When debugging I found out that the application is checking for flowVars._clientName, however it is missing. According to this documentation, actually yes flowVars._clientName is expected.
https://help.mulesoft.com/s/article/How-to-get-the-client-application-name-in-a-flow-based-on-the-client-id-and-client-secret.
So my application fails with 403 error. Seems that other environments are working perfectly fine.
And yes it is using Client Id enforcement.
Any clues?
Without more details it looks like the issue is inside the logic of your application. The KB article that you referenced is a how to in case you need to obtain the client name. It doesn't say that you have to use for authentication. You don't describe how the application does authentication/authorization. Is it in a flow? Or in a policy? If it is the standard Client ID enforcement policy, the expressions to evaluate client id and secret can be configured, but I don't think the default is not #[flowVars._clientName] nor #[flowVars._clientId].
Note that Exchange is basically a repository of APIs and other artifacts. It doesn't authenticate anything at execution time. Unless your application is trying to use it somehow, but I can't think of a reason for that.
The issue was resolved only by re-downloading Anypoint Studio and mule runtime. Very weird, it was happening only for one application, not for the others. Creating a new workspace did not help, deleting the application and re-cloning and installing did not help, even recloning in a new directory did not help. Only using a new Anypoint Studio and runtime installation resolved it (even with the old code base) ...
While using Windows Azure Table Storage in WCFService WebRole, tried to create CloudStorageAccount by the following way:
storageAccount =
CloudStorageAccount.Parse(Microsoft.WindowsAzure.CloudConfigurationManager.GetSetting("[Setting name]"))
Get exception:
ConfigurationErrorsException "Could not create Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35."
MSDN help says that 1) Visual Studio must be run as an administrator. 2) A role must be running under full trust (change the .NET trust level option to Full Trust).
All Done, but I still have the same exception.
One thing that can cause this error is running the web role itself, instead of running the containing cloud project. If this is the issue, you could fix it by ensuring that the cloud project is set as the startup project for debugging, and not the web role.
It's possible, and sometimes useful, to run the ASP.NET project that defines the web role on its own. This can be a lot quicker than running things in the Azure Compute Emulator. It may also enable you to develop your project without having to run VS elevated. Also, I've found that the emulator tends to cause Visual Studio to report an invalid memory access error from time to time, at which point you need to restart VS. Running the web role directly avoids all these problems.
However, there are some things that can prevent this from working, and the exception you describe is a symptom of one of these problems. If your web role's Web.config includes configuration for Azure's DiagnosticMonitorTraceListener (and Visual Studio adds that by default when you create a web role) then the first thing that tries to generate trace output will crash with the error you describe if you run outside the emulator. And as it happens, retrieving a setting from the CloudConfigurationManager appears to do this.
This isn't peculiar to the CloudConfigurationManager by the way. All it's doing is producing some trace output. VS configures web roles to send all trace output to the Azure diagnostic listener, and because that listener can only run in either the compute emulator or an actual Azure instance, the first thing that tries to produce trace output will crash. CloudConfigurationManager is a common candidate because it happens to produce trace output, and it typically gets used early on when a role starts up. But in principle, anything that produces trace output could hit this exception.
A simple way to avoid this is to remove the relevant section from the configuration file. When you create a new web role, Visual Studio adds a <system.diagnostics> section that configures the default trace output to go to the Azure diagnostic listener. You could just comment that out. That will enable you to debug the web role directly in Visual Studio without using the compute emulator (assuming you aren't doing anything else that depends on being in a role environment).
Of course, the problem with that is that you'll no longer get any diagnostic traces when running in Azure. One way to solve that is to move the relevant configuration to the Web.config.Release file (adding the necessary xdt: attributes).
This change will also stop the Azure diagnostic trace listener from running when you use the local compute emulator. (That's less of a problem, because the trace messages will still appear in the debugger. It just means you won't get persistent copies of the traces copied to table storage like you would when running for real.) The obvious way to fix this would seem to be to make a similar modification to Web.config.Debug (or to run the release build in the emulator), but there's a snag: apparently cloud projects do not apply configuration file transforms when packaging for the emulator by default. Fortunately, you can fix this: http://blog.hill-it.be/2011/03/07/no-web-config-transformation-in-local-azure/ shows how to enable transforms for local debugging in the compute emulator. (Transforms are never applied when debugging an ASP.NET project directly from within VS, by the way.)
I've found that this error is caused by the wrong version in your web.config
Ie., you may not have
Version=1.0.0.0
Microsoft.WindowsAzure.Diagnostics is up to version 1.8.0.0 as of now
Try updating to the current version
Remove the lines in Web.config < add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener
I want to deploy my WCF web Service on Azure plateform.
I have created a Storage account for my website, and also created a cloud Service and uploaded my package file and config file to the staging site.
But while uploading, The message displays
'Your staging deployment is starting. Hang on, the page will refresh once the deployment begins.'
I am waiting sice 2-3 hours and not getting the desired output.
Am I doing correctly? Or is there anything that I forgot?
Please Help...!
Most likely there is a problem in your code or the packaging that is causing the role to continuously restart. This is a fairly common problem, but there are a lot of possible causes (missing an assembly reference, an uncaught exception, the Run() method is exiting, a Startup Task is failing, or many other things). You need to gather more information to know exactly what the problem is and how to fix it.
There are many threads here on SO about this topic. There's also a Microsoft post discussing how to diagnose this type of issue. Those are good places to start.
I'm trying to get my application running in AppHarbor using a RavenDB instance. I've updated my raven libs to build 888 and I'm still getting the error below. I've also allowed file system write access but im still getting the same error. Any ideas how to resolve this issue?
[EsentFileAccessDeniedException: Cannot access file, the file is locked or in use]
at Microsoft.Isam.Esent.Interop.Api.Check(Int32 err) in C:\Work\ravendb\SharedLibs\Sources\managedesent-61618\EsentInterop\Api.cs:line 2739
at Microsoft.Isam.Esent.Interop.Api.JetInit(JET_INSTANCE& instance) in C:\Work\ravendb\SharedLibs\Sources\managedesent-61618\EsentInterop\Api.cs:line 131
at Raven.Storage.Esent.TransactionalStorage.Initialize(IUuidGenerator uuidGenerator) in c:\Builds\RavenDB-Stable\Raven.Storage.Esent\TransactionalStorage.cs:line 205
It appears that during app startup, my app was creating a data directory in the application root. I discovered that I had an old reference to RavenDB Embedded which was on longer being used in the project which was creating the unneeded data directory. Once I removed that reference and pushed, everything began working correctly.
Are you trying to use the AppHarbor web worker instance file storage for the RavenDB backing store? That's a bad idea, use the hosted RavenHQ add-on instead.
The self-hosted RavenDB not working on AppHarbor is a known problem.
Even if you get it to work, note that the worker filesystems are not persisted when you deploy new versions of your code or in case of worker instance failure.
I have create a WCF Service Web Role project.I can consume the service locally. But I am having issues trying to deploy the service on the azure cloud. After starting the webrole it justs kepps going in a loop where it init then stops. I have not made any changes to the default WebRoleclass that was added automatically. Can anybody point me to some samples or examples of WCF being deployed to azure
The behaviour you're seeing occurs when the instance errors in the OnStart or Run. The usual diagnostics error trapping hasn't had a chance to start yet so this is a difficult problem to debug. You might try adding error trapping inside this functions that writes the error details out to either a blob or a queue so that you can see what is actually happening.
Having said that, with code that works in the dev fabric, but continues to cycle when deployed to live, the first thing to check is that all of the references have the appropriate "Copy Local" property set. Anything that is part of the framework or Microsoft.WindowsAzure.ServiceRuntime will need to have Copy Local to false, everything else should be set to true (third party assemblies an the like). If this is a web role and you're using MVC, you'll need to check that System.Web.Mvc has Copy Local set to true as well as this is not included as part of the standard framework deployed in Azure.
Have you looked at the Known Issues information on the WCF Azure code page? There's a patch that's needed, as well as a tweak to the service behavior. Hopefully this will help you.
I just found out the root of the problem. It was caused by one of my projects having the target platform set to x86. Seems like it does not support x86 build assemblies which can be a problem