.NET Core Global Tools and Gotchas
Getting started with using or creating a .NET Core global tool package, and how to deal with the gotchas
As announced recently in the .NET Core 2.1 Roadmap, the .NET Core 2.1.300 SDK will add a feature called “.NET Core Global Tools”. This announcement contains a brief snippet of how the tools will work. As this feature is new, there are some rough edges. In this post, I’ll go over the basic design of how global CLI tool should work, some of the gotchas, and how to make it all owrk.
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.
Shipping a cross-platform MSBuild task in a NuGet package
MSBuild allows users to write and register their own tasks. Tasks, unlike targets, can be written in C# and can perform build operations that would be impossible to write in MSBuild’s XML dialect. In this post, I’m going walk through the key pieces of how to write an MSBuild task that works on both the .NET Core command line and in Visual Studio, and then how to bundle that task into a NuGet package so the task can be shared and installed automatically into projects.
Old csproj to new csproj: Visual Studio 2017 upgrade guide
The leaner csproj in VS 2017 can save you hundreds of lines of code. What to cut, keep, and change to upgrade to VS 2017
You may have heard the buzz: .NET Core went from the project.json to csproj file format, and the new csproj format is leaner, easier to read, and adds new features. But what about your .NET Framework VS 2015 (or 2013) project? How can you participate in the VS 2017 goodness? Keep reading: I’ll show you some of the major changes, and how to upgrade to VS 2017.
Part 2 - Caveats of project.json to MSBuild conversion
To convert is to change form, function, or beliefs. There will lots of this.
This upgrade is not only a matter changing JSON vs XML: it’s about learning and using a fundamentally different technology, MSBuild. Regardless of how big or small your .NET Core project is, you are likely to run into some subtle, big, and bewildering changes to how your build system as you convert. Here is a collection of obvious and not-so-obvious caveats to the MSBuild conversion process.
Project.json to MSBuild conversion guide
If you been given the unenviable task of migrating your .NET Core project from ‘project.json’ to MSBuild (csproj), you are likely to find your muscle memory disrupted and the documentation lacking. Automated upgrades in Visual Studio and .NET Core CLI may auto-generate a csproj file for you, but they won’t tell you how to do things you already know how to do in project.json. Here is the most exhaustive list I can create of all the project.json knobs as they exist in Microsoft.NET.Sdk.
.NET Core command-line file watcher (dotnet watch) for MSBuild
Basic usage and pro-tips for using dotnet-watch with MSBuild
The most recent preview (1.0.0-msbuild2-final)
dotnet-watch supports MSBuild projects, and is the most configurable, extensible version of the tool, yet.
dotnet-watch is a file watcher for
dotnet that restarts the specified application when changes in the source code are detected.
This tool has been available since the days of DNX with support for project.json.
dotnet-watch for MSBuild adds new features that were not available in the project.json versions.
Subscribe via RSS