1
votes

I went to deploy over an existing Cloud Service (in staging) and received the following message:

"Error: No deployments were found. Http Status Code: NotFound"

Does anyone know what this means?

I am looking at the Cloud Service, and it surely exists.

UPDATE:
Been using the same deploy method as prior (successful) efforts. However, I simply right click the cloud service in Visual Studio 2013. In the Windows Azure Publish Summary, I set to: the correct cloud service name, to staging, to realease ... and press publish. Nothing special really...which is why I am perplexed

5
Can you share a deployment ID or operation ID?kwill
I honestly have no idea if sharing that is a good idea or not. The "OperationId" changes for each fail anyhow...so I'm not sure how useful it is.Prisoner ZERO
Did you find any solution for this? Had this problem for a week now.Fredrik

5 Answers

2
votes

Since I had this problem and none of the answers above were the cause... I had to dig a little bit more. The RoleName specified in the Role tag must of course match the one in the EndpointAcl tag.

<Role name="TheRoleName">
    <Instances count="1" />
</Role>
<NetworkConfiguration>
    <AccessControls>
      <AccessControl name="ac-name-1">
        <Rule action="deny" description="TheWorld" order="100" remoteSubnet="0.0.0.0/32" />
      </AccessControl>
    </AccessControls>
    <EndpointAcls>
      <EndpointAcl role="TheRoleName" endPoint="HTTP" accessControl="ac-name-1" />
      <EndpointAcl role="TheRoleName" endPoint="HTTPS" accessControl="ac-name-1" />
    </EndpointAcls>
</NetworkConfiguration>

UPDATE

It seems that the previous situation is not the only one causing this error. I ran into it again now due to a related but still different mismatch.

In the file ServiceDefinition.csdef the <WebRole name="TheRoleName" vmsize="Standard_D1"> tag must have a vmsize that exists (of course!) but according to Microsoft here (https://azure.microsoft.com/en-us/documentation/articles/cloud-services-sizes-specs/) the value Standard_D1_v2 should also be accepted.

At the moment it was causing this same error... once I removed the _v2 it worked fine.

Conclusion: everytime something is wrong in the Azure cfgs this error message might come along... it is then necessary to find out where it came from.

3
votes

You may have exceeded the maximum number of cores allowed on your Azure subscription. Either remove unneeded deployments or ask Microsoft to increase the maximum allowed cores on your Azure subscription.

1
votes

Just to add some info. The same occured to me, my WM Size was setted to a size that was "Wrong". I have multiple subscriptions, I was pointing one of them, and using a machine "D2", I don't know what happened, the information was refreshed and this machine disappeared as an option. I then selected "Large" (old), and worked well. Lost 6 hours trying to upload this #$%#$% package.

I think the problem can be related to any VM Size problem

1
votes

I hit this problem after resizing my role from small to extra-small. I still had the Local Storage set to the default of 20GB, which an extra-small instance can't hold. I ended up reducing it to 100MB and the deployment worked (the role I'm deploying is in maintenance mode only for a couple of months, so I don't care much about getting diagnostics from it).

A quick tip: I was getting nowhere debugging this with Visual Studio's error message. On a whim, I switched to the azure website and manually uploaded the package. That finally gave me a useful error: that VM size was too small for the resources I had requested.

1
votes

I encountered this error during the initial deployment of a Cloud Service that required a specific SSL Certificate... that was missing from Azure.

Corrected the certificate - deploy succeeded.

(After the first deployment Visual Studio provides a meaningful error in this case.)