JamesNK

You're searching for ways to make things more difficult than they need to be.

Make the simple easy. Make the complex possible.

Because ASP.NET Core is a framework that is installed with .NET. It isn’t a set of Nuget packages.

Why? .NET Core 1.x tried making everything a Nuget package and it was a disaster. ASP.NET is big which meant a huge number of dependencies, easy to create conflicts, long restore and build times.

It was much better to just include ASP.NET Core in the box with .NET and simplify it down to a single reference. And most people use the web SDK which does it for you so they don't even need that.

Here you go:

  <Project Sdk="Microsoft.NET.Sdk">
  
    <PropertyGroup>
      <TargetFramework>net6.0</TargetFramework>
      <Nullable>enable</Nullable>
      <ImplicitUsings>enable</ImplicitUsings>
      <OutputType>exe</OutputType>
    </PropertyGroup>
  
    <ItemGroup>
      <FrameworkReference Include="Microsoft.AspNetCore.App" />
    </ItemGroup>
  
  </Project>

Just create an empty ASP.NET Core project, change the SDK, add a FrameworkReference and a OutputType.

Read the console args and configure the web app with a port as desired.

The error message is sent as a HTTP trailing header. Their server or client has a header size limit of 8kb.

It is strange that you couldn't find the empty web template. Every version of ASP.NET Core has come with one. Empty is the first option in the "Create a new ASP.NET Core web application" dialog in VS2019, and "dotnet new web" creates an empty website via the command line.

What did you need to do to create an empty website?

Disclaimer: I work on ASP.NET Core

The future of Silverlight and Flash died when mobile phones rejected browser plugins. No amount of good choices from MS/Adobe would change that.

> gRPC encoded data is actually not tightly coupled to HTTP/2 frames.

The headers frame, and the capability to have headers before AND after content is a requirement. gRPC requires trailing headers for the status code of the call. Trailing headers frame is a new concept in HTTP/2.

gRPC-Web supports HTTP/1.1 and browsers. It is able to do that by encoding the status into the end of the response body. However gRPC-Web is a different spec.

If HTTP/3+QUIC supports the same features of HTTP/2 then gRPC should work on it. There might be a HTTP/3 specific spec for details around the management of a HTTP/3 connection, but gRPC headers, message content, and proto contracts shouldn't need to change. Take what I say with a grain of salt because I haven't looked closely at HTTP/3+QUIC yet.

Developer on gRPC for .NET here.

gRPC client requires HTTP/2, and HttpClient (the .NET library for making HTTP requests) didn't previously support HTTP/2. The gRPC client actually supports netstandard2.1. Any .NET implementation that supports HTTP/2 should support running the gRPC client.

Kestrel (the .NET web server) already supported HTTP/2 but it required some new features in .NET 3.0 to fully support hosting gRPC services.

A stock price doesn't reflect how profitable you are today, it reflects how profitable you'll be tomorrow.

He isn't criticizing the title, it's just a hot take on how the nature of starting a business has changed.

Premium feature: reserve a set of lucky dice for your roles. $5/month

A succinct way of putting it is there is a finite profit margin on consulting.

.NET always preserves generic type information for reflection but there is code reuse when a generic type is used multiple times with different reference types, e.g. there is little overhead having List<object> and List<string>

Duplication exists with generics and value types, e.g. List<long> and List<DateTime> are entirely separate code. It's just a thing to keep in mind when mixing them with value types.