My last publish was probably about three weeks ago, today, I changed the code a bit and publish. Then I ran into the error below
Publish has encountered an error. The Publish URL
https://functionName.scm.azurewebsites.net/ is unreachable. The
application may be stopped, restarting or unavailable. Try again once
the publish target is available.
The only similar post I found is suggesting to correct the pubxml field
<PublishUrl>https://waws-prod-<something>.publish.azurewebsites.windows.net/</PublishUrl>
To
<PublishUrl>https://<function-name>.scm.azurewebsites.net/</PublishUrl>
In my case, it is correct already.
If I call the function by HTTP get, it behaves as usual.
I'm relevant new to azure, not sure if I missed something obvious.
Additional remarks
It's compiled successfully.
I never change the PublishUrl and the field value is pretty much what I posted.
The app is running.
The account login to VS is the same one to Azure.
First of all, make sure your function app can be compiled.
Second, the format of your publish url is no problem.
So maybe this problem is not from the Visual Studio side. please make sure the function app is not stop or restarting, the scm site is not under the protection of NETWorking and you have login the right Microsoft account in VS.
If all of above still don't work, you can try to use other deploy method. Such as command or ftp and so on.
And for your situation, if you just do a little change, the incremental deployment may be a better choice.
I saw this error happen when somebody else on my team deleted the storage account the function app was using. Because I was unaware of this deletion, it was hard to connect the details from the error to a missing storage account.
Once I recreated it, with the same specifications of a storage account that can be auto-created during a function’s first deployment, I was able to re-configure my function to use it, and I was able to deploy again from Visual Studio.
In my case opening azure functions app in my browser helped. Until that it was giving error when I try to publish it in Visual Studio.
In my case, I didn't realize I had set up IP restrictions as this was a function app I had published a long time ago so obviously my IP had by this point changed. For me, the solution involved:
Select your Azure Function app in the portal
Under the "Settings" section click "Networking"
Under "Inbound Traffic" I had "Access Restriction" set to "On". If this is your case, click on "Access Restriction". If this is not your case, then this solution won't solve your problem.
My "Unmatched rule action" was set to deny. At the bottom, I had only my old IP and my API Management IPs listed as "Allow.
Click "+Add", enter whatever name that's descriptive (like "My home ip"), make sure action is set to "Allow", set a priority (in my case the priority didn't matter), I skipped description, and for type I chose IPv4 and for IP Address Block I entered my current IP address. Skip the rest of the settings.
At the bottom click "Add rule"
Don't forget to click "Save" at the top left after that
Not sure if you have to restart your function app, I did because it didn't impact me.
I alt-tabbed back to Visual Studio and published again: this time worked perfectly.
Related
I created a function and I am trying to deploy it from VS Code by clicking the Deploy to Function App.... The Deployment runs successfully based on the output log - Deployment successful but then when I go to the portal, the function is not listed under Functions.
What shall I do and what is the problem here?
When I debug in VS Code, I get this: No job functions found. Try making your job classes and methods public. If you're using binding extensions (e.g. Azure Storage, ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. builder.AddAzureStorage(), builder.AddServiceBus(), builder.AddTimers(), etc.).
Unfortunatly I would not know if those steps don't work for uploading. The deployment finishes, and every single time it becomes visible in my portal. Uh, maybe there is a slight difference. The app service itself is pre-created via terraform. Just the uploading of the code I do via VSC.
As far as deletion goes:
Open the resource group, in the list lookup the App Service. Select the checkbox in front of it. Delete in the top nav bar of that pane.
Trying to delete it any other way will indeed give you the "Not found" error.
I've had the same 'issue', in my case it turns out that the issue was a bad entry in the requirements.txt
I had an incorrect line with 'io' and when it was present despite the deployment appearing to complete successfully in VS code, the function was not updated if it was previously deployed or not deployed if it wasn't resulting in the same 'no results' in the functions list.
Having other requirements such as 'numpy' or 'scipy' worked just fine.
It's an old thread but maybe it'll be helpful to whoever gets here in the future.
Even as of now, some changes I make in VS Code seem to take time to be immediately visible on the portal. I had a similar issue with resources, i.e. creating a resource from VS Code wouldn't make it immediately visible on Azure Portal. You can always go to Functions on the portal and click Refresh. Also try going to Advanced Tools, then Kudu and checking if your function can be found there.
One word of advice: if you publish your functions from VS Code, then work on that resource only from VS Code. You will find it reiterated all over Azure Functions docs that:
Publishing to an existing function app overwrites the content of that
app in Azure.
Am I doing something wrong or is this a bug in the portal/VS 2017 publish process?
For a long time my azure functions were running fine and then I made a trivial change to a function and republished. The whole application went 'Read Only' in the portal.
The only solution I currently have is to go into the 'App Service Editor' in the portal and remove the 'generated by' entry...
"generatedBy": "Microsoft.NET.Sdk.Functions-1.0.0.0"
After doing this the function app appears to be stable.
Is there something I'm doing wrong with my publish or is this just a bug in the Azure function environment? It appears to be a new issue.
Answered : No real problem.
Thanks David Ebbo, I think the issue I had was with something else in the function. I thought it was because it was 'Read Only' but looking at it now it appears to be running Ok as a 'Read Only'.
This is by design. When you publish using Visual Studio, your app becomes read-only to make sure that you don't attempt to modify it via Portal editing. Instead, if you need to update your app, simply publish again via VS.
While you can override this in the settings and make it Read/Write, it is almost certainly the wrong thing to do. 99% of users should never do this!
What's not clear from your question is why you are viewing this as a problem in the first place. The fact that the portal prevents you from editing your function does not break anything. All your functions can still run and will be triggered as expected.
Looking at the docs, it would appear that this would be super simple...perhaps it's something with my Azure Configuration. I'm simply setting up a demo project in Azure (which will be a Node app). I set up a Web App (have tried standard, basic, and free levels) and try to follow the instructions here which seem very straightforward.
https://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/
But when I go to "All Settings" on my web app, there is no "Continuous deployment" option under the Publishing settings.
So I thought that perhaps I needed to set my deployment credentials. When I go to Deployment Credentials, it states that I need to create a deployment username and password. But even when I enter credentials that satisfy the requirements, the Save button is never enabled!
Any ideas on what is going on here would be greatly appreciated. I though perhaps it was some kind of regional limitation, but that seems unlikely as I've tried both West and SouthCentral regions. I'm convinced I'm doing something obviously dumb and just missing it.
Thanks!
I just encounter the same issue, no Continuous Deployment option and cannot save deployment credentials. I just switch back to classic portal and set it from there(click the app > go to dashboard > quick glance > Set up deployment from source control). After setting up and then I switch back to the new portal and the option appears. Really weird issue.
Not much to say...I basically deleted and totally cleaned up everything from Azure and started over and miraculously the 3rd or 4th time, the option just appeared.... Not very reassuring...no idea what altered the situation.
Same issue here, but just copy paste deployment hook (Settings/Deployment Source) and add it to the github repository webhooks and it worked.
I have a standard Azure build -- one web role, one worker role. After the latest merge, it has decided that the roles are invalid. When I double click on the web role or worker role, or when I right click and choose "Properties", I get a grey screen saying "Invalid service definition or service configuration. Please see the Error List for more details". However, there is nothing at all in the Error List.
I have cross-compared the Settings elements and tried commenting out sections of the csdef and cscfg files, but nothing seems to bring the roles back to life. I have wasted half a day on this already. My question is not so much "What is wrong" -- more like, how on Earth are you supposed to find out what the error is when no information is given and successive blanking out of code draws a comprehensive blank?
I've run across this a couple of times (VS 2015 Enterprise). Simply closing and re-opening the solution resolved the issue.
In this case, nothing was wrong with the csdef and cscfg files. It was the way the wadcfgx files were linked to the roles.
I'm on a branch that is using Azure 2.5; the other branch is on a previous version of Azure, that uses the older version of diagnostics. By deleting the existing wadcfgx files and re-generating them, I was able to make the roles visible and editable again. Having different versions on different branches does, of course, open a very large can of worms, but we're stuck with that difficult situation for the time being.
Check if the VM Size specified in the configuration is Small or Extra Small as it doesn't support more than that on local emulator. In my case it was defaulted to Standard Size VM. I changed the size to Extra Small and it started working fine!
I just ran into this after adding a new Worker Role project to an existing cloud service with a few existing Worker Roles.
In my ServiceConfiguration.Cloud.cscfg, I had a <NetworkConfiguration> tag in between the old roles and the new role. This was the problem. I simply moved the <NetworkConfiguration> tag to the bottom as it was before (this tag is not in my ServiceConfiguration.Local.cscfg file, which might've been the problem).
Probably not the most common cause of this problem, but figured I'd post on the off chance someone has similar settings.
I created a cloud service and tested it successfully locally. I added service configurations for stage and production. Here is a snippet of my staging-configuration:
and here my configuration-settings:
Then when I publish I set up the deployment as follows:
All this worked like 2 weeks ago. But now he deploys in VS and when I look into Azure Service Configure area it looks like this:
I played a little bit with the "Update development ..."-checkbox on the second screen but the result is the same.
So it ignores all the settings I made and just won't tranistion my configuration to the ine I named "CloudStage". My current Web PI tells me that I use Windows Azure SDK for .NET (VS 2013) 2.3. I don't get the point.
Edit
Some more things I observed:
No WADLogsTable and WADWindowsEventLogsTable is generated automatically in the staging storage.
I deactivated Remote Desktop because it was one of the changes I made to monitor the event log (which wasn't useful here)
I manually changed the connection strings in Azure Portal but it seems as if the worker is totally unaware of the storage (rebooted it with no success).
Edit
I recognized another thing. Here you can see a running deployment of my service:
See the warning-mark on the left? If I go to my Error list this is shown:
This warning is senseless since it tells me that I did everything the right way. My *.Local.csfg-files are pointing to the local storage. So?!?
This seems weird. Please check the in your ServiceConfiguration.CloudStage.cscfg to verify the expected values.
Have you tried updating any other property like Enabling Remote desktop? Does that get updated on your deployment? You should select the "Deployment Update" check box in the publish dialog. Now, when deploying to an existing Cloud Service, it should ask you if you want to replace it.
If you get the Object reference error every time you right click on project, there might be some issue with the Azure SDK set up.
I'm a little bit further now. What I did was:
Deleted all Services in Azure.
Deleted all Storage Accounts in Azure
Removed my Service-Project completely from solution (not the library containing the worker-logic).
Re-added storage-accounts in Azure.
Re-added services in Azure.
Re-added a project in the solution and added the worker-logic inside it.
Builded up all the publishing-stuff again.
Published it.
The first publish ended like the one described in my question. After I checked the "Update development..."-option in properties of my worker it finally took my transitions into the stage!
Now I recognized, that WADLogsTable was still empty. I hit the instance right in server-explorer and choosse "Update diagnostic settings...". There was an option "Transfer period" suddenly set to "None". This explained to me, why my table was empty and after I set it back to "1" my table is filling again!
Another funny thing beside: When I right-click my Cloud-project in the solution I get "Object reference not set to an instance...". When I just click it left and choose Build->Publish it works.
I just hope that I can help somebody with this. Lets see if it's stable now.
Edit: Yesterday it worked - today is still the same issue :-(.
When you get "Object reference not set to an instance.." for a CloudService project you usually have some kind of mismatch. It could be that a setting in the ServiceConfiguration is not defined in the ServiceDefinition. It could also be that there is a publish profile defined in the .ccproj file for the CloudService that doesn't exist. This might also be what is causing your problems with the different configurations.
So it turns out that the problem is completely on client-side. My Visual Studio (now with SDK 2.4) is doing something wrong. I set up a fresh installation with all the stuff needed :-( and there it works perfect. I'll try to determine if one of my extensions is causing the strange "Object reference not set..."-bug.
Repair-Installation of VS does not solve the problem btw.