I am trying to serve a clickonce app from an azure appservice. One of the files it must download is a .config file. These are treated as special files by azure as far as i can tell, and it will not let them be accessed via html (it just 404s). I tried setting a web.config and allowing the mimetype on the off chance this made a difference, but no joy.
Any suggestions?
Related
I have some app services and I update the web sites content by uploading the data via FTPS.
Occasionally, after I upload new content, the sites don't display it at all or partially until the app service is restarted.
Is this normal behavior?
What can be done to avoid restarting or monitoring the site and automatically restarting the app service if the site does not appear properly after updating the content?
Thanks
Just to highlight, based on your application framework - Unlike Git-based deployments and Zip deployment, FTP deployment doesn't support build automation, such as: dependency restores (such as NuGet, NPM, PIP, and Composer automations), compilation of .NET binaries, generation of web.config (here is a Node.js example).
You may generate these necessary files manually on your local machine, and then deploy them together with your app.
Additionally, App Service deploys files to the wwwroot folder. It never directly restarts your app.
You may verify if the deployment files are in root folder. A deployment issue is an issue that causes the wrong set of files to get deployed to your site folder (typically d:\home\site\wwwroot). Deployment-vs-runtime-issues
Using the Deployment Center link on the App Service page navigation in the azure portal, I was able to find my FTP credentials and easily log in with them. However, there are no files in the wwwroot folder except for hostingstart.html.
However, when I use the Azure Console, all my files appear in the wwwroot folder and the hostingstart.html file is not there.
I'm not sure if it's relevant but we do have continuous integration setup. I just want to be able to see those files and interact with them.
If I browse into the /LogFiles folder I can confirm that the FTP and Azure Command Line show the same files. So I know I am on the right server.
After much searching I learned what is going on. If you have the WEBSITE_RUN_FROM_PACKAGE setting enabled, your site is served out of a zip file.
The FTP server shows the real folder, whereas the kudu console maps that folder to the contents of the zip file.
This announcement explains it in a lot of detail.
Go to kudu and click "Current Docker logs (Download as zip)"
I deployed a newly created Asp.Net Core web application to an Azure app service using ftp, while enabling delete existing files, directly from VS 2019.
Now whenever I view the content of the wwroot folder using Winscp, the result is as expected and I see the latest output from my local build. But whenever I view the contents of the folder in Kudu, the list of files is outdated/reflects previous local builds outputs (screenshots below from winscp and from kudu in the browser).
What is going on here ?
This is also breaking my app, since my app's initialization code cannot read an xml file that I see in winscp, but is not visible when I navigate to the folder in kudu.
I already tried restarting the app service multiple times, to no avail.
What am I missing ??
wwroot contents from kudu
wwroot contents from winscp (files order alphabetically, the vue middleware should be displayed before web.config)
I created an app service at http://testsam.controltrackonline.com, it loads properly. I have also created a folder within it called webapi but it does not load up and does not allow publishing content to it via appVeyor. The non loading folder location can be loaded here http://testsam.controltrackonline.com/webapi
I do not see any permissions issues surrounding this as other app services with same settings load well with folder within. But for this appservice there seems to an issue.
Any ideas?
It seems that you'd like to publish content to an Azure web app virtual directory, so please make sure you configure virtual directory or application under Application settings blade in the Azure Portal.
Note: you can also refer to "Deploying multiple virtual directories to a single Azure Website" to set up the virtual directory or application.
I have also created a folder within it called webapi but it does not load up and does not allow publishing content to it via appVeyor.
I do not see any permissions issues surrounding this as other app services with same settings load well with folder within. But for this appservice there seems to an issue.
Please try to use FTP or Kudu to access your Azure web site folder, and then you can try to upload your content package to webapi folder and check if it works as expected.
Besides, If issue only appear on that specific app service, you can create an Azure support request, Azure support can help you investigate the issue.
I have a Web site running on Azure App Services. It has a WebJob that deploys with it, and thus gets put in it's App_data folder once deployed.
If I FTP to the wwwroot/app_data folder of my site once deployed, the app.config file has none of the configured settings that I set up in the "Application Settings Blade" in the Azure portal. The settings are changed in my web.config for the Website though.
The most curious thing is that when I run the WebJob, the log output indicates that the correct settings are being used!!
So as per my title, does the WebJob use the App.Settings file once deployed or does it use some kind of in-memory copy of the app-settings from the azure portal, or does it use what is in the web.config of the website?
Just to pre-emt a possible question, I know that the app.settings gets renamed to myappname.exe.config
Here is how it works:
Azure doesn't run your WebJob in-place, but instead copies it to a temp folder (to avoid locking it in-place when it runs).
As part of this copying process, the App Settings are transformed in the temp files. That's why you don't see the changes in the config file.
Azure listens to file changes in your WebJob files, so if you modify your config file, Azure copies/transforms the files again and restarts the WebJob.
Mark Seeman elaborates on this:
As far as I can tell, it attempts to read configuration settings in this prioritized order:
1.Try to find the configuration value in the Web Site's >online configuration (see below).
2.Try to find the configuration value in the .cscfg file.
3.Try to find the configuration value in the app.config file or web.config file.
(Read the whole investigation here: http://blog.ploeh.dk/2014/05/16/configuring-azure-web-jobs/)
David Ebbo answer is perfectly right.
Just wanted to state that you can also run web jobs in place by a using a parameter in settings.job:
{
"is_in_place": true
}
Details can be found in Kudu docs:
https://github.com/projectkudu/kudu/wiki/WebJobs#webjob-working-directory