BenchmarkDotNet

Benchmarking is really hard (especially microbenchmarking), you can easily make a mistake during performance measurements. BenchmarkDotNet will protect you from the common pitfalls (even for experienced developers) because it does all the dirty work for you: it generates an isolated project per each benchmark method, does several launches of this project, run multiple iterations of the method (include warm-up), and so on. Usually, you even shouldn’t care about a number of iterations because BenchmarkDotNet chooses it automatically to achieve the requested level of precision.

Source: Home – BenchmarkDotNet Documentation

Setting up your project and TeamCity/OctoPack to include certain files in deploy package.

From: Setting up your project and TeamCity/OctoPack for front-end builds

Octopus Deploy has a nice NuGet package, called OctoPack, for generating Octopus Deploy-compatible NuGet packages out of .NET projects.

However, OctoPack will only pack files that are included in the CSPROJ file, and in the case of static files, have Build Action set to Content. This is a problem, because this means that all files generated by your task runners, be it Gulp or Grunt, will have to be included in the project and pushed out to source control.

This introduces an unnecessary problem – conflicts in generated code. So, if developer A was working on a SCSS file which was referenced in the main stylesheet, and developer B was working on a separate SCSS file, also referenced in the same main stylesheet, why should either one have to resolve a conflict caused in the file generated by the task runner?

This makes no sense. It’s like building your .NET project, and pushing the generated DLL files to source control, and then having to resolve conflicts within the DLL files generated by the build. Why would you do that?

So, in order for you to never have to resolve another conflict in generated files again, here’s my guide on how to set up your project so they play nice with TeamCity and OctoPack.

Create a NUSPEC file for your project, and include the folders that are not currently included in the project.

What this does is it informs OctoPack about the files that you want to include in the deployment package. Here’s an example.

<?xml version="1.0"?>
<package >
<metadata>
<id>MyProject.Web</id>
<version>$version$</version>
<authors>Geta AS</authors>
<owners>Geta AS</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>MyProject.Web deployment package</description>
<copyright>Copyright 2016</copyright>
</metadata>
<files>
<file src="public\**\*.*" target="public" />
</files>
</package>

As you can probably already tell, this will cause OctoPack to only include files stored in the specified folder in the generated deployment package. That’s no good.

On to the next step.

Update the project CSPROJ file to include all other files.

<?xml version="1.0" encoding="utf-8"?>
...
<PropertyGroup>
<OctoPackEnforceAddingFiles>True</OctoPackEnforceAddingFiles>
</PropertyGroup>
...

This tells OctoPack to include all the files it would normally include in addition to the files specified in the NUSPEC file.

Once we have all this set up, we can commit the files, and push them to source control.

 

Source: Setting up your project and TeamCity/OctoPack for front-end builds

Cashew: A simple and elegant yet powerful HTTP client cache for .NET

A simple and elegant yet powerful HTTP client cache for .NET

Cashew

Cashew is a .NET library for caching responses easily with an HttpClient through an API that is simple and elegant yet powerful. There’s support out of the box for the awesome CacheManager via the Cashew.Adapters.CacheManager package. Its aim is to focus on the HTTP part of caching and not worrying about how stuff is stored, meaning no half-arsed cache implementations!

Cashew targets .NET 4.5 and .NET Standard 1.1 (.NET Core, Mono, Xamarin.iOS, Xamarin.Android, UWP and more) meaning it can be used on all sorts of devices.

Source: joakimskoog/Cashew: A simple and elegant yet powerful HTTP client cache for .NET

ReportUnit – xml testresult to html dashboard tool

ReportUnit is a report generator for the test-runner family. It uses stock reports from NUnit, MSTest and Gallio and converts them into attractive HTML reports with dashboards.

Works with nUnit 3.x as well.

Nuget: https://www.nuget.org/packages/ReportUnit/

Github: https://github.com/reportunit/reportunit

LiteDB – A .NET NoSQL Document Store in a single data file – CodeProject

A simple, fast and free embedded .NET NoSQL Document Store in a single data file. Inspired on MongoDB, supports collections, POCO classes, Bson Documents, indexes, stream data, ACID transactions and LINQ expressions.

Introduction

This article is an overview about my database project LiteDB – a small, fast and free embedded .NET NoSQL Document Store for .NET in a single datafile – and now it’s on new version 2.0

Source: LiteDB – A .NET NoSQL Document Store in a single data file – CodeProject

Run, monitor, and manage builds for TFS/VSTS from Visual Studio


In Visual Studio 2015:
You can run, monitor, and manage your builds from the Builds page

If you’re not already connected to the team project that you want to work in, then connect to the team project.
Choose Home icon Home, and then choose Builds Icon Builds (Keyboard: Ctrl + 0, B).

Source: Run, monitor, and manage builds

LiteDBViewer: a GUI for LiteDB

LiteDBViewer: LiteDB Viewer is a simple tool that let you open a LiteDB database file and shows its contents; think of it as a GUI for LiteDBShell

LiteDB is a small, fast and lightweight NoSQL embedded (filebased) database, great for prototyping for instance.

Source: falahati/LiteDBViewer: LiteDB Viewer is a simple tool that let you open a LiteDB database file and shows its contents; think of it as a GUI for LiteDBShell