GitHub Actions has been released in General Availability in November 2019, and since then the service has seen an incredible growth, making it the second most popular CI tool on GitHub, for both private and public repos.
It has many Starter Template for a lot of different languages, such as .Net Core, Python, Java, Docker, and many more. But unfortunately there is no out of the box Starter Template for the Full .Net Framework.
Nevertheless, today we are going to create a CI workflow for a .NET Framework application, using GitHub Actions.
But before deep diving into the code, let me take a step back and talk a little bit about Actions, because it is much more than a CI system.
About GitHub Actions
In fact, it is a very powerful automation engine where actions, defined in YAML files, allow you to trigger workflow processed on any GitHub event, such as code commits, creation of Pull Requests or new GitHub Releases, and more.
To create the workflow you use the Actions, which basically are individual tasks, that you can combine to create jobs and customize your workflow. You can create your own actions, and use and customize actions shared by the GitHub community.
And actually for creating a CI workflow for a .NET Framework project, we have to use both "official" GitHub Actions and community ones.
If you want to know more about GitHub Actions you can take a look here
Let's do this
Here you have the video with the whole explanation, and of course the end to end creation of the CI with Actions for a .NET Framework Asp.net MVC application.
Closing
If you have used before other CI systems, like for example Azure Pipelines, you need to "clear your mind" and start afresh, because the syntax and the logic here, even tho they seem alike, are quite different.
Let me know in the comments what you think about GitHub Actions, and if you have encountered any problem or issue in creating CI workflows, especially for the Full .Net Framework.
Like, share and follow me 🚀 for more content:
📽 YouTube
☕ Buy me a coffee
💖 Patreon
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast
Top comments (5)
Thanks a lot for this video it was a big help. There is far more code written in .net framework 4.x than core. Ultimately core is where I want to get to eventually, unfortunately delivering business functionality comes first and migration comes second.
Thanks
Steve
(Dark matter developer)
I agree. Also, I’m porting now a CRM+ERP Asp.Net MVC WebApp from FullFX 4.6.2 to .NET 5 and it’s a bloodbath 😅
Why would you use Actions with Framework (use the right tool for the job)? It's going into maintenance/legacy mode and new development should really be focused on .NET Core (especially in an ASP.NET project). The only way CI/CD really "works" with Framework is by using Windows containers (gross), or having a dedicated Windows build server.
Well, there are still a bunch of .NET Framework projects on GitHub and they could benefit from CI with Actions. And while some of those projects could be ported to .NET Core, that wouldn't be wise or even possible for some (think if you have a library to support some projects, like I do... you cannot just convert it)
Also, I don't agree that "The only way CI/CD really "works" with Framework is by using Windows containers". I do have a lot of legacy .NET Framework projects and I do CI/CD without containers for all of them, and don't have any problem.
Regarding the "dedicated Windows build server" that is also not necessary, Azure Pipelines has Windows agents and of course as I show in the video GitHub Actions has it as well, so you can do it no problem.
Last but not least, more and more enterprise users are moving to GitHub for their private repos. And a lot of enterprise companies have applications running on full .NET Framework and cannot or don't want to migrate to Core.
So IMHO this make a lot of sense :)
"Windows agents" is just shorthand for "Windows containers" or "Windows build server". Saying you do not want to migrate to Core without valid reasoning (cost-prohibitive or otherwise) is just being regressive. You cannot build a .NET Framework project without Windows involved somewhere which a lot of CI/CD just doesn't have.