Skip to main content

Posts

Showing posts from October, 2019

ElasticSearch–Decrease the monitoring data

Quick tip to prevent the monitoring index to get out of control: To decrease the amount of data of the ElasticSearch monitoring you can change the _cluster settings More information: https://www.elastic.co/guide/en/elasticsearch/reference/current/monitoring-settings.html

Azure DevOps–How to change the default iteration?

After upgrading to Azure DevOps 2019, I got a question from a customer asking how to change the default iteration used when creating new work items. By default the current iteration is used. If you are creating user stories, this is probably not what you want as these user stories should first be analyzed, groomed, … before they can be planned inside a specific iteration/sprint. Fortunately this is something that can be changed easily at the team level: Click on the Show Team Profile  icon on the Kanban board: Click on Team settings: Go to Iterations and Areas: Click on Iterations: Now you change the default iteration how you want:

Fork–A fast and friendly GIT client

Tooling is important and great tools can make a difference. Especially when you are using so rich and complex as GIT can be. Last week I discovered a new GIT client; Fork . I was especially impressed by the interactive rebase functionality. Could be a lifesaver if you are now afraid to use rebase … Remarks: My current favorite is GitKraken in case you want to know. But I’m giving Fork a try and so should you…

Orleans–Fire and forget

The basic building block in Orleans is a ‘Grain’. A grain is an atomic unit of isolation, distribution, and persistence. A grain perfectly matches the OO principles as it encapsulates state of an entity and encodes its behavior in the code logic. The ‘normal’ way to communicate between Grains is through message passing. This is greatly simplified thanks to the async/await programming model in C# combined with some code generation voodoo. It almost ‘feels’ like normal method invocations. A consequence of the async programming model is that you always should ‘await’ the results. However there are some situations where you don’t care about the results and want to call another grain in a ‘fire-and-forget’ mode. To achieve this you can use the InvokeOneWay() extension method on a GrainReference:

Testing–Faking a delay in SQL Server

To test the timeout settings of my application, I needed a query that exceeds a certain time. This was not that hard to achieve in SQL Server thanks to the WAITFOR statement. This statement blocks the execution of a batch, stored procedure, or transaction until a specified time or time interval is reached, or a specified statement modifies or returns at least one row. ----Delay for 10 seconds WAITFOR DELAY '000:00:10' SELECT 'Hello finally!' GO More information: https://docs.microsoft.com/en-us/sql/t-sql/language-elements/waitfor-transact-sql?view=sql-server-ver15

MassTransit - A convention for the message type {typename} was not found

While preparing a presentation I created a simple demo app where I wanted to publish a message to a queue. My first (naïve) attempt looked like this: This failed with the following error message: A convention for the message type {typename} was not found What was my mistake? In MassTransit you have to make a difference between sending a message and publishing a message. Whereas publishing a message doesn’t require any extra configuration, sending a message does. Why? Because when sending a message you directly target a queue. MassTransit has to know which queue the message should be send to. We have 2 options to make this work: 1) You specify the target queue using a convention: 2) You use the ISendEndpointprovider to specify a queue:

Reconfigure the ElasticSearch Windows Service

If you are running ElasticSearch on a Windows Cluster you probably are using a Windows Service to run it in the background and make it start automatically at boot time. This Windows Service feature is available out-of-the-box if you use the .zip package . Some settings of ElasticSearch are managed as command-line arguments(e.g. the min and max memory usage). To manipulate these settings when using the Windows Service, you have to go through the ElasticSearch Windows Service Manager. To open the manager, go the ElasticSearch installation folder. (e.g. c:\elasticsearch-7.4.0\) Browse to the bin folder (where you should find a elasticsearch-service.bat file) Run the following command: elasticsearch-service.bat manager This will open a GUI where you can manage multiple ElasticSearch settings: Remark: Most changes will require a restart of the service.

ASP.NET Core gRPC–Unary RPC vs Streams

When creating your gRPC implementation you have to be aware about the difference between Unary RPC and Streams. Unary RPC This is the simplest type of RPC, where the client sends a single request and gets back a single response. This is the simplest approach and similar to what we know when using WCF. Streams With streaming we have to make a difference between server streaming, client streaming and bidirectional streaming. A server-streaming RPC is most similar to the Unary RPC, the only difference is that the server sends back a stream of responses instead of a single response after getting the client’s request message. After sending back all its responses, the server’s status details (status code and optional status message) and optional trailing metadata are sent back to complete on the server side. The client completes once it has all the server’s responses. A client-streaming RPC turns things around, the client sends a stream of requests to the server instead of a

Why you should not fear rebase…

Last week our junior developers shared their experiences and lessons learned during a ‘dev case’. One thing they al mentioned is that doing a ‘rebase’ in GIT is, according to their opinion, a bad idea. Although rebasing is a powerful tool, and you have to apply it carefully, there is no reason to avoid it all cost. Some things to keep in mind before you rebase: Never rebase commits that have been pushed to a remote origin and shared with others. Use rebase to catch up with the commits on another branch as you work with a local feature branch. You can't update a published branch with a push after you've rebased the local branch. You'll need to force push the branch to rewrite the history of the remote branch to match the local history. Never force push branches in use by others. As a general rule it would only use rebase on local changes that haven't been shared with others. Once you’ve shared your changes, switch to merge instead. To use rebase,

ASP.NET Core 3.0 - ConfigureContainer magic

Last week I blogged about the changes I had to make to let Autofac work with ASP.NET Core 3.0. Inside my Startup.cs file I had to use the .ConfigureContainer() method: But where is this method coming from? Let’s dig into the ASP.NET Core source code to find out… The source of all magic is the StartupLoader class: https://github.com/aspnet/Hosting/blob/rel/1.1.0/src/Microsoft.AspNetCore.Hosting/Internal/StartupLoader.cs . This class uses reflection to find the following 3 methods in the Startup.cs file: a Configure() method a ConfigureServices() method a ConfigureContainer() method If you want environment-specific setup you can put the environment name after the Configure part, like ConfigureDevelopment , ConfigureDevelopmentServices , and ConfigureDevelopmentContainer . If a method isn’t present with a name matching the environment it’ll fall back to the default. If a ConfigureContainer() method is found, the IServiceProviderFactory<TContainerBuilder&

Visual Studio 2019–Code Cleanup

Did you notice the small broom icon at the bottom of your code editor window in Visual Studio? This is the  Code Cleanup button. It allows you to apply code styles from an EditorConfig file or from the Code Style options page. (The .editorconfig takes precedence). To configure the exact Code Cleanup actions, you can click the expander arrow next to the code cleanup broom icon and then choose Configure Code Cleanup . After you've configured code cleanup, you can either click on the broom icon or press Ctrl + K , Ctrl + E to run code cleanup.

Visual Studio–Generate an EditorConfig file

I talked about the .editorconfig file a long time ago as a way to standardize code style conventions in your team. These conventions allow Visual Studio to offer automatic style and format fixes to clean up your document. But did you know that in Visual Studio 2019, you can generate an .editorconfig file dynamically based on the style and formatting found in your existing codebase? Go to Tools –> Options –> IntelliCode . Change the EditorConfig inference setting to Enabled . Right click on you solution in the Solution Explorer and choose Add –> New EditorConfig (IntelliCode) After you add the file in this way, IntelliCode automatically populates it with code style conventions it infers from your codebase.

Azure DevOps - Publish code as wiki–Advanced features

One of the features I really like in Azure DevOps is to publish your code as a wiki . This allows you to choose a Git repository, branch and folder that contain Markdown files. The markdown files are then published as pages inside the wiki. Unfortunately when we take a look at the table of contents(TOC) we see all the markdown files listed in alphabetical order. Every subfolder is also shown as a wiki page even when it doesn’t contain any markdown files. This is probably not what we want. Let’s improve the TOC… Change the page order To change the order of the files in the TOC, you can add a .order file to the repository. Each .order file defines the sequence of pages contained within a folder. The root .order file specifies the sequence of pages defined at the root level. And for each folder, a .order file defines the sequence of sub-pages added to a parent page. Inside the .order file you can specify each file name without the .md extension. An example: README

.NET Core 3.0 - HTTP/2 support

You maybe think this is a bad title for this blog post? HTTP/2 support was already available for .NET Core 3.0. So why a blog post with the release of .NET Core 3.0? The reason is that although it was possible to host an ASP.NET Core 2.0 application behind an HTTP/2 endpoint, the HttpClient class didn’t had support for it! There are 2 ways that can be used to enable HTTP/2: Enable HTTP/2 at the instance level To enable HTTP/2 support at the instance level, you can set the DefaultRequestVersion when creating the HttpClient instance: For example, the following code creates an HttpClient instance using HTTP/2 as its default protocol: Of course even better is to use the HttpClientFactory to create and configure the HttpClient: Enable HTTP/2 at the request level It is also possible to create a single request using the HTTP/2 protocol: Remark: Remember that HTTP/2 needs to be supported by both the server and the client. If either party doesn't support HTTP/2, both

ASP.NET Core 3.0 - Autofac error

After upgrading my ASP.NET Core application to 3.0 I got an error in Startup.cs  when I switched to the new HostBuilder: System.NotSupportedException: 'ConfigureServices returning an System.IServiceProvider isn't supported.' Let’s take a look at my ConfigureServices() method: Inside my ConfigureServices I’m using the Autofac containerbuilder to build up my container and return an AutofacServiceProvider. Therefore I updated the ConfigureServices() method signature to return an IServiceProvider. This worked perfectly in ASP.NET Core 2.x but is not allowed anymore when using the new HostBuilder in ASP.NET Core 3.0. Time to take a look at the great Autofac documentation for a solution: https://autofac.readthedocs.io/en/latest/integration/aspnetcore.html#asp-net-core-3-0-and-generic-hosting . Ok, so to fix this we have to change our ConfigureServices() method to no longer return an IService Provider: Then we have to update the program.cs to register our AutofacSe