A small issue I’ve run into while setting up a .net core web api microservice that also utilises a number of gRPC services. Symptoms were as follows:
Response Read via Fiddler
– HTTP/1.0 200 This buggy server did not return headers
– Value was binary and unable to be read
03:59:23 DBG] Connection id “0HM01U963EUAR” accepted.
[03:59:23 DBG] Connection id “0HM01U963EUAR” started.
[03:59:23 DBG] Connection id “0HM01U963EUAR”: HTTP/2 connection error.
Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http2.Http2ConnectionErrorException: HTTP/2 connection error (PROTOCOL_ERROR): Invalid HTTP/2 connection preface.
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http2.Http2Connection.ParsePreface(ReadOnlySequence`1& buffer, SequencePosition& consumed, SequencePosition& examined)
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http2.Http2Connection.ProcessRequestsAsync[TContext](IHttpApplication`1 application)
[03:59:23 DBG] Connection id “0HM01U963EUAR” is closed. The last processed stream ID was 0.
[03:59:23 VRB] Connection id “0HM01U963EUAR” sending GOAWAY frame for stream ID 0 with length 8 and flags 0x0
[03:59:23 DBG] Connection id “0HM01U963EUAR” stopped.
[03:59:23 DBG] Connection id “0HM01U963EUAR” sending FIN because: “The Socket transport’s send loop completed gracefully.”
The issue turned out to be that in appSettings.json the default kestrel endpoint had been set to utilise http2. Removing this immediately resolved the issue. It may also be worth double checking your launch settings, startup.cs and program.cs to ensure that nothing’s been overridden.
I expect that any similar routing issues would result in similar symptoms so hopefully this post will be able to save a few people a bit time!
I ran into the following error today after updating visual studio 2019 to version 16.6:
unable to find the target operating system for the project
I tried a fair few things to get this going again and I’m assuming they’re not all necessary, but I’ll list them just in case:
– Clean solution
– Close visual studio
– Delete .vs folder
– Ensure that docker-compose is set as startup project
– Edit each project’s .csproj file and ensure that the DockerDefaultTargetOS value is set: Linux
– Edit docker-compose.dcproj and ensure that DocketTargetOS is set
– Restart computer
If you’re able to narrow it down at all I’d be interested in hearing what the actual cause is!
I ran into the following intellisense error while adding a new proto file:
“protobuf” visual studio a namespace cannot directly contain members such as fields or methods
This was one of many errors that were shown and appeared to be an issue with Intellisense mistaking the file for a normal class definition. The following appears to have fixed it:
1) Right click on the file and select “exclude from project”
2) Clean the solution and rebuild
3) Re-include the file in the project (you may have to toggle ‘Show All Files’ at the top of solution explorer to see the excluded item).
I ran into the following error while using docker compose and visual studio:
Severity Code Description Project File Line Suppression State
Error DT1001 Service has neither an image nor a build context specified. At least one must be provided. docker-compose C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets 204
It took a bit of poking around to find as the error seemed a bit ambiguous, but luckily this turned out to be a simple mistake on my part. I’d renamed my service from “servicename” to “service_name” in docker-compose.yml. Unfortunately, I hadn’t noticed the visual studio had automatically added an entry to docker-compose.override.yml. Because I hadn’t updated this entry it couldn’t find an image for the non-existent service.
A simple error on my part, but hopefully it’s able to save you a bit of time!
I’m currently toying around with GraphQL on with HotChocolate on .NET Core Microservices. After implementing logging I ran into a bit of a problem every time I opened the GraphQL playground.
While observing my logs I noticed that an almost continuous stream of Schema logs were appearing which made it fairly difficult to track down any legitimate errors. The solution to this turned out to be fairly simple – playground offers both a polling enabled and polling frequency setting that can be configured locally:
I simply disabled this for testing, and then increased it to 30s once I’d migrated my logs to seq.
It has all been pretty straight forward, however I hit an error when attempting to run docker build:
RUN dotnet restore
—> Running in 734e82e92c23
/usr/share/dotnet/sdk/2.2.207/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.TargetFrameworkInference.targets(137,5): error NETSDK1045: The current .NET SDK does not support targeting .NET Core 3.0. Either target .NET Core 2.2 or lower, or use a version of the .NET SDK that supports .NET Core 3.0. [/src/myMicroservice.csproj]
The command ‘/bin/sh -c dotnet restore’ returned a non-zero code: 1
Updating the Dockerfile references seems to have resolved the issue. I replaced each occurrence of 2.2 with 3.0 and re-ran the following command: