I have downloaded one .EXE file and it got successfully installed on one machine. However, when I tried doing it on another machine I got error as below:
Exception Text
System.Deployment.Application.InvalidDeploymentException: Deployment
and application do not have matching security zones. at
Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.GetManifests(TimeSpan
timeout) at
Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.InstallAddIn()
Looks like one of the files in the application folder is corrupted. See ClickOnce "Deployment and application do not have matching security zones" for more information.
Related
I have a ASP.NET Core with Blazor website and I want to deploy it to Arvixe host. The website is very simple and contains only UI elements no database required. I published the website to a local file system and uploaded it using FTP to the Plesk.
When I am visiting the website, I receive this error:
500 - Internal server error. There is a problem with the resource you
are looking for, and it cannot be displayed.
I have tried to run it on the IIS and I received more details:
Configuration The configuration file cannot be read due to
insufficient permissions.
I tried to add IIS_IUSRS to the group and users for web.config but I am not able to find it because I am using a windows 10 connected to active directory.
Besides, I still don't know how to solve this problem at Arvixe. Does anyone know tips might help?
500 internal error is generic issue. Please kindly check the error message on the server and paste it here. Make sure that your provider has installed .net core bundled on their server and here are tutorial about publsih .net core using plesk https://windowswebhostingreview.com/how-to-publish-using-web-deploy-with-plesk-control-panel/. It should be working fine.
You need to give Full Trust permission (Read-Write-Execute) to your application folder and also to Application Pool and also check if the Runtime version supported by Arvixe matches with your Asp.net Core version.
Also enable the logs in web.config file by setting stdoutLogEnabled="true" to get detailed error so that you can investigate more about the error.
I have tried with google drive location as a installation path at the time of publishing VSTO application.
But at the time of installation time it throwing an exception to download manifest related stuff.
Exception is like below
Name:
From: https://drive.google.com/drive/folders/1tL4egzEy2uga0asj0bsgzQ10Y8Q-cJ3wj?usp=sharing/MyApp.vsto
************** Exception Text **************
System.Deployment.Application.InvalidDeploymentException: Exception reading manifest from https://drive.google.com/drive/folders/1tL4egzEy2uga0asj0bsgzQ10Y8Q-cJ3wj?usp=sharing/MyApp.vsto: the manifest may not be valid or the file could not be opened. ---> System.Xml.XmlException: DTD is prohibited in this XML document.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.ParseDoctypeDecl()
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Deployment.Application.ManifestValidatingReader.XmlFilteredReader.Read()
at System.Xml.XsdValidatingReader.Read()
at System.Deployment.Application.ManifestReader.FromDocument(String localPath, ManifestType manifestType, Uri sourceUri)
--- End of inner exception stack trace ---
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.GetManifests(TimeSpan timeout)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.InstallAddIn()
Any guys having any guess regarding this exception?
Finally my intention is to be available my publish folder at global level, I will send .exe file only to user so that user can be able to install application with the combination of .exe and web location where publish stuff resides.
You have a few questions in this same vein, and while I do not use this feature, I think I see where you're going wrong.
I believe VSTO is assuming you're deploying to your own web server, with no fancy paths. Google Drive clearly has paths that are not meant to handle appending a file or folder name. An FTP server may require login credentials or special connection settings, and is very uncommon these days.
You probably need to stand up a web server, if you don't already have one, and publish to that. Or use a network folder if that works in your situation.
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'm about to post my answer to this, as well, but I couldn't find this when googling last night so figured it's worth listing here for anyone else pulling their hair out at 9pm.
I created a new Umbraco instance of a site that already exists elsewhere (I needed to make a snapshot for security testing whilst bugfixing continues). To do so, I did the following:
Stopped the destination webserver.
Copied over the entire webroot, including the umbraco folder, an empty App_Data and all the assets, macros, templates and so on. (To do this, I actually made a zipfile of the webroot and reinflated it onto the destination webserver, but a more standard xcopy deployment would have the same effect.)
Backed up the database (two of them, in my case, but only one is Umbraco's) and restored it to a new database on the destination dataserver
Restarted the destination webserver.
Normally, my next step would be to tell Umbraco to republish the site, to clear any caches but, on trying to visit http://mydomain.com/umbraco/, I get a yellow screen of death error reading:
Database persistence could not be found, please ensure you have a valid connection string and a Umbraco.Courier.Persistence.* dll in your /bin
and a stack trace of
Umbraco.Courier.Core.PersistenceManager.GetPersistenceProvider(Guid id) +294
Umbraco.Courier.ItemProviders.DocumentTypeItemProvider.HandlePack(ItemIdentifier id) in c:\Program Files (x86)\teamcity\buildAgent\work\872c402d3442319c\Core\Umbraco.Courier.Providers\ItemProviders\DocumentTypeItemProvider.cs:140
Umbraco.Courier.Core.ItemProvider.Package(ItemIdentifier id) +88
Umbraco.Courier.RepositoryProviders.Local.Package(ItemIdentifier itemId) in c:\Program Files (x86)\teamcity\buildAgent\work\872c402d3442319c\Contrib\Providers\Umbraco.Courier.RepositoryProviders\Local\Local.cs:227
Umbraco.Courier.Cachehandler.V4.CacheHandler._sendToCache(ItemIdentifier itemId) in c:\Program Files (x86)\teamcity\buildAgent\work\872c402d3442319c\Contrib\Providers\Umbraco.Courier.CacheHandler.V4\Cachehandlers\CacheHandler.cs:211
Umbraco.Courier.Cachehandler.V4.CacheHandler.DocumentType_AfterSave(DocumentType sender, SaveEventArgs e) in c:\Program Files (x86)\teamcity\buildAgent\work\872c402d3442319c\Contrib\Providers\Umbraco.Courier.CacheHandler.V4\Cachehandlers\CacheHandler.cs:133
Vega.USiteBuilder.DocumentTypeManager.SynchronizeDocumentType(Type typeDocType, Type baseTypeDocType) +574
Vega.USiteBuilder.DocumentTypeManager.SynchronizeDocumentTypes(Type baseTypeDocType) +146
Vega.USiteBuilder.DocumentTypeManager.Synchronize() +56
Vega.USiteBuilder.UmbracoManager.Synchronize() +120
Vega.USiteBuilder.UmbracoManager.SynchronizeIfNotSynchronized() +85
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +80
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +270
Now I know that the Umbraco.Courier.Persistence.* DLLs are all present — not least because I just copied them from a working environment.
So what gives?
Having wasted a bunch of time on this a couple of times in the last week, it occurred to me to make an actual note of how to fix it when it next happened.
All it takes is recycling relevant the application pool. If you're not sure how to do that, then take a look at one of the following links:
Hosting.com: Recycle Application Pools in IIS6 & IIS7
TechNet at Recycle an Application Pool on Demand (IIS 7) — the IIS6 instructions on TechNet really suck
StackOverflow: PowerShell script to recycle an IIS6 app pool
StackOverflow: How to use adsutil to recycle an IIS6 app pool
I hope this saves someone else from the frustration I was feeling well after office hours the other night.
I have to concur that that solution doesn't always work; we're having the same "database persistence" error trying to deploy Courier (build 26) with the latest Umbraco 4.11.1 build, and clicking "Deploy" from the umbraco Courier dashboard brings the same error. Recycling the application pool for this site didn't help.
Posted as a help ticket to umbraco.org also, if I get resolution will post here.
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!