kudu

I've been using Rotativa[1] for URL to PDF generation which is also a wrapper for wkhtmltopdf. They have a dotnet-core[2] version and also a SaaS[3] but it's worth mentioning that Azure PaaS supports wkhtmltopdf[4] so I just self-host. Looking at QuestPDF's API docs, it doesn't look like they support URL / HTML to PDF generation. I think this would be a great addition especially given the age and issues with Rotativa and TuesPechkin on their public repos. [1] https://github.com/webgio/Rotativa [2] https://github.com/webgio/Rotativa.AspNetCore [3] https://rotativa.io/ [4] https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandb...

Haha... I have experience with Azure as well, seen both good and bad things. As I read the title, I was already quite sure to read such a post. When Kubernetes became popular, I tried it with Azure and both scripts and documentation were broken. When I found out, I stopped trying. Regarding Azure in general: Azure Websites is c*. Having used Heroku and App Engine for some time before, this feels like a joke. Deployments sometimes work, sometimes they don't. Have to deal with node gyps? Don't, just don't. If you ever are forced to use Azure Websites (free startup package? ;)), learn Ansible as soon as possible and convince your team to switch to VMs. The VMs are okay, you can't do much wrong with. I don't really know where the complexity of Azure Websites comes from, maybe from the fact that it runs on Windows, but this cannot be the full

The App Service Editor (which uses Monaco) does have file management. It even has a web-based command-line interface. https://github.com/projectkudu/kudu/wiki/App-Service-Editor

It should be pretty easy to look at the approach I took and mimic it for other providers. I write Open Source code for Microsoft, so we made it work with Azure first - but the code should be clean enough for someone else to pick it up and work in other stacks. I should probably also mention that the engine running Azure Websites is open source itself (https://github.com/projectkudu/kudu), so you could just point it to your own engine.

Kudu is insanely powerful. There's a browser-based console (https://github.com/projectkudu/kudu/wiki/Kudu-console) where you can run git operations, copy files, npm, etc. It supports deployment and web hooks. The new feature is Azure Site Extensions (https://github.com/projectkudu/kudu/wiki/Azure-Site-Extensio...). Kudu is automatically set up for any Azure Web Site (https://github.com/projectkudu/kudu/wiki/Accessing-the-kudu-...). If your web site has URL http://mysite.azurewebsites.net/ , then the root URL of the Kudu service is https://mysite.scm.azurewebsites.net/. Here's a 10 minute video with Scott Hanselman and David Ebbo that shows it off pretty well: http://channel9.msdn.com/shows/azure-friday/exploring-the-su...

Nice idea. A few problems spring to mind: * Doing the following will hang if the stdout buffer fills up: var output = process.StandardOutput.ReadToEnd(); process.WaitForExit(); Take a look at Kudu (Azure's Git publishing platform) for the way they do it: https://github.com/projectkudu/kudu/blob/master/Kudu.Core/In... * You need to expose a way to capture `StandardError`.