BruceForstall on main
Fix arm64 scalar intrinsic use … (compare)
var ilasmPath = @"C:\Windows\Microsoft.NET\Framework\v4.0.30319\ilasm.exe";
var (result, stdOutputs, stdErrors) = GeneralHelpers.RunProcess(ilasmPath, ilFilename,
"/DEBUG",
"/EXE",
"/NOLOGO",
$"/OUTPUT={assemblyFilename}");
<PackageReference Include="runtime.linux-x64.Microsoft.NETCore.ILAsm" Version="6.0.0" GeneratePathProperty="true" />
dotnet build
:<Project Sdk="Microsoft.NET.Sdk.IL/6.0.0">
<PropertyGroup>
<OutputType>Library</OutputType>
<TargetFramework>net6.0</TargetFramework>
</PropertyGroup>
</Project>
So, anyone online and able to mark this as ready for review (I think I been waiting since the new year vacation for it to be marked for review). I have some Impl that has been waiting for it to be reviewed (and hopefully approved) for .NET 7: dotnet/runtime#62113
prereq (something similar to this): https://github.com/dotnet/runtime/issues/42820#issuecomment-980830626
Funny story on the prereq: The only diff between Deflate, Zlib, and GZip is the Window Bits so I made them into classes as structs cannot inherit from other structs which was the original design of that part.
fixed
statement
GCHandle.FromIntPtr
. But I guess that's racey -- the GC could kick in between you getting the pointer, and pinning it
Memory<T>.Pin
NativeMemory
which contains more than 2^31 elements?
Is the advice in https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=net-6.0 about re-using instances of HttpClient
still correct?
HttpClient is intended to be instantiated once and re-used throughout the life of an application. Instantiating an HttpClient class for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors. Below is an example using HttpClient correctly.
I thought SocketsHttpHandler
fixed all of that back in .NET Core 2.1?
Tough this class implements IDisposable, declaring and instantiating it within a using statement is not preferred because when the HttpClient object gets disposed of, the underlying socket is not immediately released, which can lead to a socket exhaustion problem. For more information about this issue, see the blog post You're using HttpClient wrong and it's destabilizing your software.
That blog post is from 2016, and my understanding was that SocketsHttpHandler
solves that problem. That was the entire point of it.
I've got a program that uses the Boo interpreter under the hood. It breaks on updating to .NET 6, because of a breaking change that causes strong name signing to throw an exception. The following code will always throw, even if the public key value is null
:
var assemblyName = new AssemblyName();
assemblyName.Name = GetAssemblySimpleName(outputFile);
assemblyName.Version = GetAssemblyVersion();
if (Parameters.DelaySign)
assemblyName.SetPublicKey(GetAssemblyKeyPair(outputFile).PublicKey);
else
assemblyName.KeyPair = GetAssemblyKeyPair(outputFile);
return assemblyName;
Is there any way to fix this behavior without 1) modifying the compiler's code or 2) reverting back to .NET 5 and losing some important .NET 6 benefits I'd prefer to keep?