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.
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.
Subscribe via RSS