Also I was wondering is it correct to say that BCL is a part of CLR?
@rodion-m I guess? https://docs.microsoft.com/en-us/dotnet/standard/glossary#bcl says that "BCL" and "runtime libraries" can refer to the same things, https://docs.microsoft.com/en-us/dotnet/standard/glossary#clr says that "CLR" can refer to the .NET Core Runtime, and https://docs.microsoft.com/en-us/dotnet/standard/glossary#runtime says runtime can refer to the runtime libraries.... A lot of these terms are bit context-dependent, which makes precise yes/no answers about what is/isn't correct hard to give
It's true to say that the runtime repo contains both the BCL and things like the JIT
Does anyone happen to know the deadline for getting things into the .NET 6 runtime, or if there will be any features released in patches for .NET 6? I have a feature (LDAP SSL support on Linux) that I'd like to get into .NET 6, but I don't know how much time I have
They do not like to disclose exact dates
the public API surface for .NET 6 needs to be final by July 17
I presume that non-API related work can go on for a little longer
Scenario is we have very little object creation (game server). And almost everything that lasts longer then a cycle is pooled for the lifetime of the app. So I'm concerned about the overhead of the GC just having to touch stuff in gen2, as only a tiny percentage would ever get out of gen2.
We have our own set of unmanaged collections, so I have the option of using those more. Not ideal but it's on the table
I mean, pooling is quite common in the .NET world nowadays, so there is not an inherent issue
What kind of objects are these exactly?
Mostly smallish objects, actual memory 90% are probably under 200 bytes. The values are predominantly value types mostly integers. Which I'm also curious if that makes it easier on the GC to track references? Even though they are on the heap as they live in managed collections, the values themselves don't have references to managed types.
Maybe if you had 100 megabytes of stuff I'd be worried
Gen 2 collections are super infrequent and often run concurrently with your app code, so the latency impact is minimal
Value types aren't tracked by the GC, whatever object that contains them is tracked by the GC. So if you have an array or list of
ints, it's going to track only the array or list.
structs are also value types, but I'm not 100% certain what happens if they contain a reference type - a struct holding a reference to an array, for instance. Presumably the structs themselves aren't tracked, but I'm not sure how the references they contain are tracked.
i mean 3.1
The one thing that is not supported is
delegate* unmanaged<...> without specifying a specific unmanaged calling convention
There are also some bugs with marshaling structs that have function pointer fields
I'm hacking on a .NET 6 library, and I'd like to use that library in a separate project. I think I'm missing something in the contributing docs, but does anyone have tips on how to use the library compiled from source in a different project?
thanks!
most assemblies should have that, if it doesn't then I'd check whether it references
netstandard.dll -> NS, mscorlib.dll -> .NET Framework, else -> Core
Hello! At first, thanks for all the great work done on .NET :thumbsup:
I have a question regarding the git workflow between the main dotnet/runtime and feature branches like dotnet/feature/NativeAOT or dotnet/feature/NativeAOT-LLVM: I can see in the PR history that there are main merges, but on what basis does that happen? Is it regular, like every so days or more random, e.g. when the maintainer decides the changes are worth merging? Also, does it happen that changes from feature (lab) branches are merged (cherry-picked) back to main?
and yeah if there's an important fix that doesn't just apply to the feature branch I'd expect that to land in main separately
but there are no hard rules