Synchronizing Files With Azure Web Apps Over FTP
Easy deployment to Azure using FTP or FTPS
I've recently been experimenting with Azure for static site hosting. While there are lots of great static site hosts (my personal favorite still remains Netlify), Azure Web Apps offer some attractive features to enterprises or organizations already invested in Azure. One would think that easily deploying a static site to Azure would be relatively straightforward. Unfortunately, I found that this wasn't the case at all. While Azure Web Apps have some advanced deployment options like Kudu for git deployments and Web Deploy for deployments from Visual Studio, both require some setup and configuration, are designed with "application" scenarios in mind, and aren't as straightforward as a simple FTP upload. Unfortunately, even FTP uploads to Azure Web Apps have some issues that I'll discuss below. To address this scenario, I ended up writing a little bit of code to automatically synchronize a local static site with an Azure Web App FTP server that ignores unchanged files.
Announcing A New Documentation Experience
Easy to customize API, content/wiki pages, and blog posts in the new Wyam Docs recipe.
When I started working on Wyam about 2 years ago, a primary design goal (probably the primary goal) was to create a general-purpose static generator that could be easily adapted to any sort of content, from the most complicated web site to output that isn't web-based at all. I was frustrated with both the lack of a popular and robust generator in the .NET ecosystem (why should Ruby and Node get all the fun?) and also with the limitations of the generators that do exist on other platforms. Nearly all of them favor strong conventions and patterns and while many are extensible, creating experiences that differ too greatly from what's expected becomes challenging fast (a notable exception to this is Metalsmith, which is similar in spirit to Wyam).
Roslyn-Based DSLs vs. Standard C# Scripts
Examining the advantages of each and when you'd want to use them.
One of the many benefits of the Roslyn compiler-as-a-platform approach is that we can use it within our own applications to enable interesting scenarios like code-based configuration or scriptable behaviors. Roslyn provides several facilities for making this possible including a compilation API, access to syntax and semantic information, and a dedicated scripting API. In addition, Roslyn also powers the execution of C# scripts (typically ending in the
.csx extension) by providing a script runner executable that's basically a thin wrapper around the scripting API I just mentioned. This gives developers many different options for how to introduce the power of code-driven functionality to their codebase. This post takes a look at two such options and why you might want to use one over the other. We'll also consider some of the fundamental reasons why there are tradeoffs at all and what could be done to improve the situation.