Microsoft emitted an Azure Pipelines app for Slack today while also reminding devs of the tweaks made to breakpoints in the upcoming combo of Visual Studio 2019 and .NET Core 3.0.
Devs hiding in the hipster world of Slack were given the bad news today that there is no escape from Azure Pipelines as Microsoft made an app available for its continuous integration and delivery service.
The cloudy service provides pipelines for Linux, macOS and Windows and allows users up to ten free parallel jobs for open source projects.
The new Slack app will bombard channels with notifications for build events such as completed builds, releases and so on. It is, of course, up to the user to set up and manage those subscriptions and decide which lucky channels will receive emissions from Azure Pipelines.
From the department of “I’m sure the debugger already did this” comes a reminder from Microsoft of one of the many new toys due to arrive in Visual Studio 2019 and .NET Core 3.0: Data Breakpoints, a tool that breaks when a specific object’s property changes.
Previously the domain of C++ coders (from Visual Studio 2017 15.8), the advent of .NET Core 3.0 (in preview form at least) means that developers in less hairy and scary languages can join in the fun. While absolutely convinced that this functionality has always been there (spoiler: it hadn’t), we took Visual Studio 2019 Preview 2 out for a spin and threw some code at the new C# compiler to see what happened.
Scaling up Azure Service Fabric Linux Clusters using Ubuntu Xenial? Not so fast, friend
From a dev’s perspective, data breakpoints are an excellent idea when one is trying to work out what bit of naughty code is changing the value of a property. Often one ends up having to spray code with breakpoints or shoving a breakpoint into the setter of an object. The latter approach usually ends up with the dev holding down the resume key to deal with what feels like hundreds of unnecessary stops.
Data breakpoints get fired when a specific object’s property gets changed, and are set by selecting the new “Break when value changes” option in the context menu of the property in the Locals window. A big, red spot on the value indicates the code will break when it changes, and it also puts an appearance into the Breakpoints window.
Unfortunately for .NET Framework users, it looks like only .NET Core devs will be able to join the party, which is a shame because this is a truly useful feature that will save coders a good chunk of time in tracking down potentially tricky bugs.
There are some downsides. Anything that can’t be expanded in the tooltip, Locals, Autos or Watch windows need not apply, and Static Variables are right out. Fields inside of structs are also not supported right now, but the gang are apparently working on it. ®