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>

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.

Stardock has acted like scum through the whole ordeal. On top of the lawsuit against P/R...

1. They attempted to trick the UQM project leadership into signing a document that said Stardock owned the rights to everything in Star Control II. Stardock would then "generously" license rights back to the UQM project as "protection". In reality it would put the free game under Stardock's thumb[1]

2. There are leaked conversations of the owner of Stardock labeling the UQM forum and star-control.com as hostile to his company and how he is going to shut them down

3. There are two subreddits for Star Control. The fan owned /r/starcontrol and the Stardock owned /r/StarControlOfficial. An unknown reddit account took over /r/starcontrol under strange circumstances and sowed havoc for a couple of days before reddit intervened and removed the new mod. There are theories that Stardock was behind it.

[1] http://forum.uqm.stack.nl/index.php?topic=7396.0

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.

C#'s equivalent quixotic fever dream is probably LINQ.

What? LINQ is terrific.

You can .NET Native on your own machine for testing but the package uploaded to the store contains MSIL. The final .NET Native version is then compiled in the cloud.

https://blogs.windows.com/buildingapps/2015/08/20/net-native...

One great feature of .NET Native is that the compiler is capable of being hosted in the cloud. When you build your Store package in Visual Studio, two packages are created – one .appxupload and one “test” .appx for sideloading. The .appxupload contains the MSIL binaries as well as an explicit reference to the version of the .NET Native toolchain your app consumes (referenced in the AppxManifest.xml). This package then goes to the Store and is compiled using the exact same version of the .NET Native toolchain. Since the compiler is cloud hosted, it can be iterated to fix bugs without you having to recompile your app locally.

UWP apps from the Windows Store already ban JIT compilation - at least for .NET apps.

When .NET UWP applications are uploaded the store pre-compiles them on the server with .NET Native. The user only downloads and executes native code.

I'm expecting it won't. With C# 7 tuples there will be less methods with out parameters in the future.

It came from the video but I have personally found async methods to be significantly slower most of the time (although I've never sat down and figured out the exact amount).

The reason for the performance hit is that a lot the time your async methods are actually completed synchronously, e.g. you read data from a FileStream with ReadDataAsync and instead of going to disk, the data was already cached in an in-memory buffer. When you hit that situation the overhead of the async - the state machine, not being able to inline the method, nesting everything in a try/catch, etc - makes it orders of magnitude slower than a normal method just fetching some data from a buffer.

If your method is always async and is already taking 2ms then it doesn't matter, but you want to avoid the async in methods called in tight loops in performance critical code. The overhead can be significant.

In fact, they're generally slightly slower

An async method is much slower (40x) compared to a normal sync method. If you're writing a high performance library you need to be careful to not repeatedly call a method decorated with async in a tight loop. Of course 40x times slower of extremely fast is still really fast but I found the overhead can add up really quickly.

Good video on async/await and performance: https://channel9.msdn.com/Events/Build/BUILD2011/TOOL-829T

And the torpedo they dropped barely worked.

Later in tests the US Navy found there was a 2/3 chance the torpedo would break up, not start or simply sink when it hit the water.

You probably won't. This is .NET Core only. .NET Core is a cross platform slimmed down version of .NET and doesn't run Winforms or desktop WPF. Windows Store WPF is supported.

No.

Currently .NET Native (AOT) is used with WinStore apps - in fact every Win10 .NET application in the store and on your computer HAS to be .NET Native - but the plan is to make compiling a native DLL possible for all .NET Core applications.

No

.NET CLI is a set of cross platform command line tools for making .NET applications.

Sure you can. The Azure website's control panel has a package upload dialog box. As long as it is a valid Azure package it doesn't matter where you upload from.

> DataContractJsonSerializer has the most absurd way of serialising dictionaries into JSON.

DataContractJsonSerializer is a hack that is built on top of an XML parser.

For the people who are unfamiliar with .NET there is a comparison of Json.NET to Microsoft's two JSON serializers here:

http://json.codeplex.com/ <- Json.NET homepage

Also Huk is estimated to get a six figure salary from his team Evil Geniuses. Prize money is a bonus.

It may not be physical but he has a blog, that's a thing. Email address, tumbler account, Flicker account, etc, etc.

Going to the press looks like an effective way to get results.

It has a lot of improvements over the original game though.

If you look at them side by side (UQM against the original PC Starcon 2) it is remarkable how much work has been put in to improving the graphics and sound for modern computers.