For now, i'm running a Unity Web Player App in a Windows Azure WebRole as suggested here.
Deploy Unity3D in Windows Azure
I'm a bit stuck with my unity app. I just deployed my application on windows azure. For the details, I have my web player file at siteroot/0/.unity3d
I use Uniweb to communicate with my web role (same as the one where the .unity3d file is located, so, it's the same domain)
But when I send HttpPost to my http://asp.net page I got this exception : SocketPolicyClient1: Incoming GetPolicyStreamForIP
SocketPolicyClient1: About to BeginConnect to x.x.x.x:843
SocketPolicyClient1: About to WaitOne
SocketPolicyClient1: WaitOne timed out. Duration: 3002.1718
SocketPolicyClient1: Caught exception: BeginConnect timed out
Exception: Unable to connect, as no valid crossdomain policy was found
But I have a crossdomain.xml located at siteroot/0/
xml version="1.0"
cross-domain-policy
allow-access-from domain="*" to-ports="1-65536"
cross-domain-policy
I don't know why my unity app don't communicate with my (same) http://asp.net webrole. It worked well when I built windows app but with web player it fails.
Thanks a lot !
Based on above log I am suspecting that you did not bind the port correctly when the role starts. To get is done you need the following:
Add the following endpoint to your Azure Application:
<Endpoints>
<InputEndpoint name="Unity3DPort843" protocol="tcp" port="843" />
</Endpoints>
After that in your Role OnStart() method you will need to do the following to start the listening on that port:
TcpListener Unity3DPortListener = new TcpListener(RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["Unity3DPort843"].IPEndpoint);
Unity3DPortListener.Start();
I am only suggesting above based on the problem description so please try and let me know if it worked or not.
It's strange. It don't use Uniweb anymore but the build in www class and it still gives me the SecurityException: No valid crossdomain policy available to allow access.
I have my .unity3d in the blob storage (not same domain)
Related
I am getting below error while deploying app service via Azure DevOps. I tried to search for this issue but could not found root cause of this.
Error :
2021-03-15T06:01:27.7479723Z ##[error]Error: Error Code: ERROR_COULD_NOT_CONNECT_TO_REMOTESVC
More Information: Could not connect to the remote computer ("web-app.scm.azurewebsites.net") using the specified process ("Web Management Service") because the server did not respond. Make sure that the process ("Web Management Service") is started on the remote computer. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_COULD_NOT_CONNECT_TO_REMOTESVC.
Error: The remote server returned an error: (403) Forbidden.
Error count: 1.
'''
I tried everything until I spotted (after reading this) that my (dev) shared App Service service plan was out of storage space! When I upgraded it to a bigger one I could deploy again!
According to this document, the error is caused by that Web Deploy cannot connect to the remote service. Please refer to the follow points to troubleshoot your problem:
Please make sure Azure app service works fine. You can ping the remote machine.
That the msdepsvc(“Microsoft Web Deployment Agent Service”) or wmsvc(“Web Management Service”) service is started on the remote server.
Your firewall is not blocking incoming connections of your ports on the destination. If you used the default installation, then it would be 80 for msdepsvc and 8172 for wmsvc.
In addition, you could try to add -retryInterval:6000 -retryAttempts:10 to Additional Arguments in Azure App Service Deploy task as this thread stated.
BTW, if this issue still exists in Azure pipeline, please check if this issue exists locally. You could refer to this thread: Got 403 Error when doing Web Deployment and Web Deploy results in ERROR_COULD_NOT_CONNECT_TO_REMOTESVC for more guidance.
Thank you Edward for insightful explanation for possible root cause. Issue is resolved now.
Root cause was the agent pool selected did not have rights for deployment(IP are not whitelisted for production App service) since
We are not using agent provided by DevOps directly for production environment.
An instance that'd worked great for years starting giving me this error yesterday during Web Deploy. No changes from our side. No amount of poking around non-invasively solved it, but simply hitting the Restart button on the Azure app service Overview page put it to bed quite easily.
In short: Double-check your publish profile (each element).
Bit longer: In my case, my publish profile contained a ResourceGroup element which pointed to the wrong resource group. (I'm using WebPublishMethod: MSDeploy) I went over all elements and made sure they point to the correct resource, credentials and whatnot.
That seemed to solve the issue.
In my case, I had modified machine.config to captur traffic in Fiddler
<system.net>
<defaultProxy
enabled = "true"
useDefaultCredentials = "true">
<proxy autoDetect="false" bypassonlocal="false" proxyaddress="http://127.0.0.1:8888" usesystemdefault="false" />
</defaultProxy>
</system.net>
and this was interfering with the VS deployment to Azure
When authorizing one drive with my web app service getting below error 'unauthorized_client: The client does not exist. If you are the application developer, configure a new application through the application management site at https://apps.dev.microsoft.com/.'
I am trying to deploy an web app created 'index.html' file stored in onedrive and wanted to connect deployment center with one drive, checked the web app URL provided in azure it is up and running.
This issue should be fixed now. Could you please try again and update here. If it doesn't work, I would need a network trace while reproducing the issue.
I am trying to connect to my Azure Service Bus from my Worker Role using AMQP. However, I get a time-out exception. When I use a network sniffer I see that it is trying to communicate to the Azure Service Bus using port 5671. But it's not sending an ACK message, it just times-out. I try this from Visual Studio 2015 with the Azure Emulator.
When I try exactly the same, from the same computer and network interface, but then from a normal command prompt application (so no Azure Worker Role and/or Emulator), it works. My application is able to send an ACK package to Azure and receives a Server Hello from Azure.
Is the Azure Emulator or the Worker Role blocking some ports by default? Why is it working from my command prompt application but not from my Azure Worker Role? I use the same connectionstring and the following code:
TopicClient client = TopicClient.CreateFromConnectionString(_connectionstring, _queueName);
client.Send(new BrokeredMessage(msg));
I finally found the issue. In the solution which uses the Azure Emulator, I included the following package:
<package id="WindowsAzure.ServiceBus" version="2.5.1.0" targetFramework="net451" />
In my console application I used the following package:
<package id="WindowsAzure.ServiceBus" version="3.0.9" targetFramework="net46" />
So changing my Azure solution to version 3.0.9 solved the problem. Seems like Microsoft introduced a breaking change in version 3.x.
In order of likelihood, I'd guess the issue is that:
_connectionstring has different values in VS vs. your Console application; perhaps due to the configuration files used at runtime and/or however you are loading the connection string. I'd recommend re-trying your test with hard-coded values in CreateFromConnectionString() to rule that out.
There is a firewall blocking the port (Windows Firewall, corporate network, etc.)
There is an antivirus interfering with the traffic
I am trying to upload a file to blob in asp.net azure. I am getting success if the page is without ssl. but if i upload with https page then i am getting connection was reset error.
And also I mentioned the maxrequestlength in web.config.
This is not Azure specific error instead it is an ASP.NET specific problem. I did some test if I could hit the problem but no luck..
I am getting sure that the problem is introduced by adding maxrequestlength and potentially having request filtering. You must setup the timeout setting with length and support script runtime in webserver specific settings.
You also have one option to RDP to your instance and enable IIS debugging to understand what could be the problem:
http://www.microsoft.com/en-us/download/details.aspx?id=26798
After running Debug Diagnostic Tool v1.2, please share your log, and i will look for root cause.
To RDP Access to Windows Azure Application, visit my blog here
I am running the platform ready test tool to try and qualify for the Powered By Windows Azure Logo Program.
My application is in production and has been running in azure for 5 months now. The application consists of a windows forms and WPF Client application which connects to a set of WCF Services running in azure which in turn connects to SQL Azure. The application also uses blob storage in Azure and I have getting on for 1TB of documents up there.
The application uses basic http binding and is configured Like this
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName" />
</security>
I successfully passed the test for SQL Azure but failed the test for windows azure with the following message
======================================================================
Test case/Verification: TC 1 -
Application must be a valid Azure
application designed to connect with
or work in the Windows Azure Environment
======================================================================
Status is ProtocolError
Fail
The only thing I can think of this is causing this is that the application connects over https and the test tool does not allow me to specify a https endpoint. However I don’t think I can easily expose a plain http endpoint just to pass the test as WCF wont allow me to do that when TransportWithMessageCredential is used.
Does anyone have any ideas?
Our service AzureWatch is in the same boat. I've been in touch with MS engineers at the Ready program and they don't appear to support our precise scenario. However, they do have a version of the tool that can use https channel. I suggest contacting them via support channel. They may supply you with a later version to try, and if that fails with forms to request "bypass" of the actual testing
HTH