After introducing the dynamic keyword in my .NET core codebase, the project failed to compile with the following error message:
Error CS0656 Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create' SOFACore.Messaging C:\Projects\SOFACore\SOFACore.Messaging\MessagingModule.cs
To fix it I had to add the Microsoft.CSharp nuget package. This package is necessary to use the C# dynamic data type in a .NET Standard library.
Even Microsoft is jumping on the GraphQL bandwagon. On Channel 9 you can find a new series on GraphQL:
In case you didn’t notice it yet, I’m a big fan of GraphQL. It solves so many problems when dealing with an ever growing list of devices and (micro)services.
The people who created Apollo distilled their experiences into a set of best practices for creating, maintaining, and operating a data graph.
A must read for every GraphQL enthousiast!
ElasticSearch is safe out-of-the-box. If you do a new installation, your ElasticSearch instance is only listening to internal traffic. If you want to make the ElasticSearch API’s accessible outside the VM where you installed it, you have to take some extra steps:
network.host: 0.0.0.0
If you know restart your ElasticSearch instance, you’ll notice that we are not there yet. The node fails to start with the following error message:
[2019-07-10T14:34:59,782][INFO ][o.e.d.DiscoveryModule ] [ESSRV1] using discovery type [zen] and seed hosts providers [settings]
[2019-07-10T14:35:00,436][INFO ][o.e.n.Node ] [ESSRV1] initialized
[2019-07-10T14:35:00,436][INFO ][o.e.n.Node ] [ESSRV1] starting ...
[2019-07-10T14:35:00,634][INFO ][o.e.t.TransportService ] [ESSRV1] publish_address {10.1.100.236:9300}, bound_addresses {[::]:9300}
[2019-07-10T14:35:00,643][INFO ][o.e.b.BootstrapChecks ] [ESSRV1] bound or publishing to a non-loopback address, enforcing bootstrap checks
[2019-07-10T14:35:00,647][ERROR][o.e.b.Bootstrap ] [ESSRV1] node validation exception
[1] bootstrap checks failed
[1]: the default discovery settings are unsuitable for production use; at least one of [discovery.seed_hosts, discovery.seed_providers, cluster.initial_master_nodes] must be configured
[2019-07-10T14:35:00,650][INFO ][o.e.n.Node ] [ESSRV1] stopping ...
[2019-07-10T14:35:00,666][INFO ][o.e.n.Node ] [ESSRV1] stopped
[2019-07-10T14:35:00,666][INFO ][o.e.n.Node ] [ESSRV1] closing ...
[2019-07-10T14:35:00,678][INFO ][o.e.n.Node ] [ESSRV1] closed
The moment you provided a custom setting for network.host, Elasticsearch assumes that you are moving from development mode to production mode, and upgrades a number of system startup checks from warnings to exceptions. So we have to configure one extra setting; the initial_master_nodes:
cluster.initial_master_nodes: node-1
As part of our build process we package and push a set of nuget packages to our artifacts repository. Recently we made the switch to Azure Artifacts after which uploading packages started to fail with the following error message:
The nuget command failed with exit code(1) and error(Response status code does not indicate success: 409 (Conflict - The feed already contains ‘ExceptionHandling.Database 6.4.1'. (DevOps Activity ID: CAEC4462-2E20-4C69-9AFE-3BBC3C961E20)).)
Packages failed to publish
Ok, it seems that Azure Artifacts doesn’t like it when you try to upload the same packages multiple times. (We bumped the package version manually and didn’t care about overwriting an existing package so far). Can we fix this?
We are using the NuGet task. This task has an interesting option: ‘Allow duplicates to be skipped’. Let’s try this…
Unfortunately we ended up with the same error message as above. Let’s take a look at the documentation:
If you continually publish a set of packages and only change the version number of the subset of packages that changed, use this option. It allows the task to report success even if some of your packages are rejected with 409 Conflict errors.
This option is currently only available on Azure Pipelines and using Windows agents. If NuGet.exe encounters a conflict, the task will fail.
Aha, the last line explains everything. We are using Azure DevOps Server and it seems that this option only works in the cloud(no idea why?).
As a workaround I switched to a commandline task and invoked nuget.exe directly. If you are using a recent nuget.exe version you can add the –skipduplicate option to skip existing packages.
A quick tip for everyone using ElasticSearch(aren’t you all?);
It can be a good idea to separate the search request that fetches the results from the search request that returns the aggregations or suggestions. Why would you do that?
Caching of course! On each shard the request cache module caches the local search results. But(!) by default the request cache module only caches the results of search requests where size=0. This means that it only works when you don’t want any hits returned.
We tested it on our development cluster and the difference in performance is significant.
More information: https://www.elastic.co/guide/en/elasticsearch/reference/current/shard-request-cache.html
The setup of your test context in XUnit is typically done through the constructor. For context cleanup, you can add the IDisposable interface to your test class, and put the cleanup code in the Dispose() method.
But what if your setup/teardown logic contains some async methods? It would certainly be an anti-pattern to add this code inside your synchronous constructor or Dispose.
The correct way to do this in XUnit is through the IAsyncLifetime interface:
This interface provides you an async alternative to manage the lifetime of your test context. It can be used inside your test classes directly but also works in Class and Collection fixtures.
Posts
.jpg)