A couple of years ago I blogged Dispelling the magic!, a post explaining the internals of the Cake build orchestration tool, with that post as a proof of concept I created Cake.Bridge assembly which provided an easy way from any .NET language get access to Cake abstractions and addins from a single instance static class.
Cake has some real nice testable abstractions around working with the filesystem, processes, tools, etc. and for a .NET project, we had just that need. But a static instance isn’t very testable, and for most of our .NET projects (console apps, APIs, Azure Functions, WPF…
Since 2016 I’ve been using Medium as my platform of choice, this is not a rage quit from the platform, I’ll keep posting on Medium, the difference is that the main source for my posts will be on my own canonical domain, where I’ve got full access and control over my words.
The decision is just as much that I’ve found a stack and toolchain I really like, feel comfortable, and hopefully productive with.
The stack I’ve settled on has a few key components
It’s a quarter past midnight, you should be going to sleep, but there’s that one unit test that fails only on GitHub Action macOS build agent — it’s mocking you so you stay awake just a bit longer…
You bring out you Mac and execute tests, fortunately we can reproduce — the test fails on your machine too! A quick inspection of test output informs you that error only occurs on .NET Core.
Unfortunately, today neither VS Mac nor VSCode for some reason is your friend, solutions won’t build, tests aren’t found, break points aren’t hit and so on.
This version fixes a breaking change in the Azure App Services Run-From-Zip web app deployment feature.
As the App Setting has change you’ll need to change you setting name to
WEBSITE_RUN_FROM_ZIP (it’s value should still be
Maker filename is handled by the new version so all you need to update scripts to use Cake.Kudu.Client version
nothing else needs to be changed in your Cake script.
You can verify the publish succeeded under App Service Advanced Tools ( Kudu ) — Debug Console by navigating to
Originally published at blog.bitrise.com.
Mattias Karlsson demonstrates how you can build and ship a .NET Core website using a custom docker build image and the open source build system Cake.
Guest blog post by Mattias Karlsson.
Mattias Karlsson is a Microsoft Azure MVP and Open Source maintainer.
Bitrise is mostly known for providing hosted continuous integration and deployment targeting iOS and Android projects, but it’s much more capable than that and can build and ship basically anything you can build on MacOS or Linux.
There’s moments when you’re just amazed on what a community can achieve!
One of these moments is when you see what Magnus, Alan, Maarten, Mike, Mike, Martin, Wesley and hundreds of people around the globe are pulling off for the 6th time this April 21st!
What I’m talking about is the Global Azure Bootcamp, a community driven event all about Microsoft Azure and cloud computing!
So likely if you head over to global.azurebootcamp.net, you’ll find one nearby.
When writing this there’s 213 locations around the globe planning to be part of a global all day event, together during one day!
Update! Since this post was written, there’s been some breaking changes to Azure App Services Run-From-Zip feature, this was fixed in Cake.Kudu.Client version 0.6.0 you can read more about that at the post below
A couple of days ago Azure announced that they in preview added a new way to do app services deployments called Run-From-Zip, which lets you deploy using a zip file.
Deploying using a zip file as been possible before, the difference with this new method is that the file isn’t extracted into the “wwwroot” directory, but instead the zip file mounted read only as “wwwroot”.
While it’s fairly easy to get going, just add a build script and connect it to your source code repository of choice, for some scenarios it makes more sense to ship your application prebuilt.
A few of those scenarios can be
When writing scripts, targeting multiple runtime versions can be really painful, scripts can be forked in different files or contain hairy conditional statements to handle differences/missing between versions of PowerShell runtime/modules, resulting in unreadable and unmaintainable spaghetti code.
What if you instead detect missing commands and supply an implementation for those when needed? This would allow you to have your scripts look the same and basically be agnostic to the which runtime it’s running on, making code more concise and easier to maintain.
The technique for this is called polyfilling and is common practise in web development where things can…
With things like the Azure Functions Cli and Azure Functions tools for Visual Studio you get the full development and debugging story locally on your machine. This is great as you can iterate and test quickly without the need to push the code to the cloud first, the drawback of this is that you can’t do incoming webhooks from. 3:rd party services, i.e. GitHub can’t access your locally running function.
But what if I said there’s a way you have your cake and eat it, wouldn’t that be great?
Introducing ngrok, ngrok is a tool and a service that will…