.NET
.NET is a free, cross-platform, open source developer platform for building many different types of applications.
Here are 17,327 public repositories matching this topic...
-
Updated
Jan 20, 2021
-
Updated
Jan 21, 2021 - C++
-
Updated
Jan 19, 2021
-
Updated
Jan 20, 2021 - C#
-
Updated
Jan 20, 2021 - C#
-
Updated
Jan 20, 2021 - Java
-
Updated
Dec 30, 2020 - PHP
-
Updated
Jan 20, 2021 - C#
Describe the bug
The current implementation of the authorization header parsing has (at least) the following issues:
- A value can't contain any commas
- A value can't start or end with a doublequote
- A value can't contain special characters
- HTTP Headers only allow ASCII characters
- There is no option to encode/decode the values (using base64 or urlencoding)
- When a value c
We can build much smaller Mono runtime for .NET Core purposes by simply removing code we don't need in this configuration. We did a few easy initial steps but we can go much further.
This list is not comprehensive but parts like
- Culture Data
- Any PAL related code
- Unused icalls
-
Updated
Jan 20, 2021 - C#
-
Updated
Jan 8, 2021 - C#
-
Updated
Jan 19, 2021 - C#
-
Updated
Jan 21, 2021 - Go
Let's make the error message more actionable.
I would recommend adding similar named column(s):
- $"Provided {columnPurpose} column '{columnName}' not found in training data."
+ $"Provided {columnPurpose} column '{columnName}' not found in training -
Updated
Apr 26, 2020 - C#
Whenever I submit a GET request to the api/public/groups endpoint, the "collections" field for each group returns "None" on every group, even if they have access to collections. I can verify that the
-
Updated
Jan 20, 2021 - C#
The Job and Toolchain columns are redundant, Runtime is all we need:
I see this very often when our users are presenting BDN results at conferences|meetups etc
The Job column should remain visible when the user has set the Job id in explicit way.
/cc @stephentoub
-
Updated
Jan 21, 2021 - C#
-
Updated
Jan 18, 2021 - C#
-
Updated
Jan 20, 2021 - C#
Expected Behavior / New Feature
Support sticky sessions for ServiceDiscoveryProviders
Actual Behavior / Motivation for New Feature
When using websockets with ocelot in a distributed system, problem can arise since ocelot, as far as i know, doesn't support sticky sessions when working with service discovery providers.
The functionality could be great if it could work with both consul
-
Updated
Jan 20, 2021 - C#
-
Updated
Jan 15, 2021 - C#
Created by Microsoft
Released February 13, 2002
- Organization
- dotnet
- Website
- dotnet.microsoft.com
- Wikipedia
- Wikipedia


We currently only implement Dispose and call
Wait()on the hostStopAsync()withinDispose.Ideally we want to avoid this and simply implement IAsyncDisposable with IDisposable just being a fallback for it.
The only issue here is that currently the factory can be use as an xUnit fixture out of the box, but unfortunately I believe xUnit doesn't support IAsyncDisposable in addition to ID