.NET Core Plugins
Introducing an API for loading .dll files (and their dependencies) as 'plugins'
I recently published a new package for .NET Core developers that want to implement a plugin system. Dynamic assembly loading in .NET Core is difficult to get right. The API in this package wrangles the complexity through a feature called ‘load contexts’. In this post, I’ll walk through problems that motivated the creation of this project, and explain what the API can do. My hope is that this plugin API will let you focus more on writing your app, and put an end to the inevitable mess of creating your own assembly loading code.
Configuring ASP.NET Core, webpack, and hot module replacement (hmr) for fast TypeScript development
This project setup supports browser live-reloading changes to TypeScript files while you develop in ASP.NET Core
Recently, I spent a weekend banging my head against the wall as I tried to figure out how to upgrade a personal project to webpack 4, TypeScript 2.9, and React (used to be AngularJS 1.6). I finally got it all working together – and even got hot module replacement (hmr) working. TL;DR? Checkout the code here: https://github.com/natemcmaster/aspnetcore-webpack-hmr-demo
Enabling code signing with NuGet, Azure Key Vault, and AppVeyor
About 4 weeks ago, I decided to code sign the NuGet packages from my personal open-source projects. I finally succeeded this weekend. When I started, I figured it couldn’t be that hard. In the end, it really isn’t, but it took hours of research to figure out how to tie it all together. In this post, I’ll share the technical details of what it took to enable code signing using Azure Key Vault, AppVeyor, and NuGet for one of my .NET Core projects.
dotnet watch 2.1
It's now a built-in command and it works inside Docker.
.NET Core 2.1 RC1
was released this week.
This is the first supported version of the .NET Core CLI which ships
dotnet watch as a built-in command.
In addition to changing how this tool ships, dotnet-watch 2.1 has a few improvements that make it
the best version yet.
.NET Core 2.1 Global Tools
Getting started with creating a .NET Core global tool package. Also, a peek under the hood.
.NET Core 2.1 RC1 was released this week. This is the first supported version of the .NET Core CLI which includes a feature called “.NET Core Global Tools”. This feature provides a simple way to create and share cross-platform console tools. In this post, I’ll go over some of the basics, and then walk though what is going on under the hood. You will need to download .NET Core 2.1 to use this to try this on your own.
Deep-dive into .NET Core primitives: deps.json, runtimeconfig.json, and dll's
Examining the foundations of a .NET Core application
I learned to program with gcc, C++, and vim. When I started working with C# and .NET, clicking the “Start” button in Visual Studio was magical, but also dissatisfying. Dissatisfying – not because I want to write a Makefile – but because I didn’t know what “Start” did. So, I started to dig. In this post, I’ll show the most primitive tools used in .NET Core, and manually create a .NET Core app without the help of Visual Studio. If you’re new to .NET Core and want to peek under the hood, this is a good post for you. If you’re already a .NET Core developer and wonder what *.deps.json or *.runtimeconfig.json files are all about, I’ll cover those, too.
Docker + dotnet-watch
Setup an ASP.NET Core project with Docker and dotnet-watch, without making Visual Studio crash and burn
I made a change to dotnet-watch recently that will make it much easier to setup Docker + dotnet-watch in your ASP.NET Core project, without causing Visual Studio to crash and burn. In current versions of dotnet-watch, there have been issues getting it to work with Docker, and it required some ugly workarounds. Even then, it was hard to keep Docker, dotnet-watch, and Visual Studio happy. Either Docker or Visual Studio would complain about issues with NuGet caches, duplicate attributes, etc. The next version of dotnet-watch removes the need for those ugly workarounds. This version isn’t available yet on NuGet.org, but you can still give it a test run today with ASP.NET Core 2.0.0 projects. The post below shows you how to setup your project to do this today using a nightly build of dotnet-watch.
Bundling .NET build tools in NuGet
How to share your console app via NuGet and MSBuild
If you are looking for a way to share a build tool among several .NET Framework or .NET Core projects,
NuGet is an excellent way to distribute it. Starting with Visual Studio 2017, NuGet comes “batteries included”
with Microsoft.NET.Sdk (typically for .NET Standard and Core) projects, and can be made to work with
“classic” .NET Framework projects, too. Most of the time, NuGet packages are used to share runtime libraries,
but NuGet packages can be used for build tools, too.
By adding a
<PackageReference> to your *.csproj files, you can ensure that the tool is available, and
you can even automatically wire it up into the project’s compilation steps.
MSBuild tasks with dependencies
You could wrestle with MSBuild's task loading mechanism, or just don't.
A few months ago, I wrote demos and a blog post about writing MSBuild tasks and shipping them in a NuGet package. The question I’ve been asked most frequently since then is “how to I make a task with external dependencies work?” i.e. “my task needs to connect to MySql, Postgres, load SQLite”, or something like that. When I started writing a post to answer these questions, I intended to show you the way to make all this work.
Subscribe via RSS