AnthonySteele

rem nukeeper release script

rem  in cmd: 

cd C:\Code\NuKeeper\NuKeeper
del C:\Code\NuKeeper\NuKeeper\bin\Debug\*.nupkg
dotnet build
dotnet pack
cd C:\Code\NuKeeper\NuKeeper\bin\Debug
dir

AnthonySteele

using System.Threading.Tasks;
using SqsMessage = Amazon.SQS.Model.Message;

namespace JustSaying.Messaging.MessageHandling
{
    public interface IHandlerAsync<in T>
    {
        /// <summary>
        /// Handle a message of a given type
        /// </summary>

AnthonySteele

A microbenchmark on the new message context store in JustSaying. The last one, ReadWriteNewMessageContext is probably the most realistic.

So we have an overhead of around 50 nanoseconds (5×10-5 ms). This is good. And I suggest that we don't bother with ways to opt in or out of this, just have it on all the time, regardless of if it is used by handlers or not.

// * Summary *

BenchmarkDotNet=v0.11.3, OS=Windows 10.0.17134.112 (1803/April2018Update/Redstone4)   
Intel Core i7-8750H CPU 2.20GHz (Coffee Lake), 1 CPU, 12 logical and 6 physical cores   
.NET Core SDK=2.2.101 

AnthonySteele

When we started coding on NuKeeper, things were different - there were automated update tools for other ecosystems, but not for .NET, and I was working with a lot of services with a lot of dependencies. Most (but not all) of these at my work were solutions in .NET full framework version 4.6.2 or the like.

I tried to find the .NET support on "Greenkeeper" before realising what the docs didn't even feel the need to spell out: this was for node.js and NPM, only. So there was a gap and a need for .NET package automation.

Well, things changed. Most notably, Dependabot got .NET Core support, and was acquired by GitHub, which was in turn acquired my Microsoft.
Automated package update management is a win for developers, so this is good for people working in .NET.