Is there a list of all .NET Core gotchas? Can you list some...
I accidentally referenced a .NET Framework (4.5) dll in the csproj of a .NET 6 application.
No warning. Nothing. It just works.
Found the following issue:
https://github.com/dotnet/msbuild/issues/7637
You have a nuget warning for when you reference a .net framework package in .net (core) but nothing from dotnet build/msbuild.
Does anybody know of a blog post or can share experience in all the gotchas for .NET(Core) they have encountered similar to this one?
Another example is the automatic consumption of lower version .NET Core libraries with "no issue" apparently although .NET releases aren't supposed to be fully backward compatible.
GitHub
Build doesn't fail if you reference a .NET Framework library inside...
Issue Description The build succeeds if you add a .NET Framework project as a dependency of a .NET 6 library. I would have expected that should be forbidden. Steps to Reproduce See the attached sol...
23 Replies
Unknown User•4mo ago
Message Not Public
Sign In & Join Server To View
yeah, but how does it really work? don't you need .net standard for exactly this purpose, that this shoulnd't work
Stack Overflow
Why .NET framework project can be added as reference in .NET Standa...
While doing some conversion of .NET Framework 4.6.2 project into .NET Standard project, I noticed that I could add .NET Framework project reference in the .NET Standard project, which doesn't sound
I guess this answer:
"But what about .NET Core -> .NET Standard -> .NET Framework references? At runtime you have only System.Runtime.dll. There is no problem with .NET Standard project because netstandard.dll will type-forward to System.Runtime.dll. But the trick is that .NET Core has also mscorlib.dll! And yes, it's also only type-forwarding to System.Runtime.dll types."
Unknown User•4mo ago
Message Not Public
Sign In & Join Server To View
I know
Unknown User•4mo ago
Message Not Public
Sign In & Join Server To View
but there is also this mscorlib.dll shim
Unknown User•4mo ago
Message Not Public
Sign In & Join Server To View
okay, so it if there is no WARN it should always work
Unknown User•4mo ago
Message Not Public
Sign In & Join Server To View
I know, I know
Unknown User•4mo ago
Message Not Public
Sign In & Join Server To View
that's why I asked in the first place, cause it works out of the box without the neststandard 2.0 shim
Unknown User•4mo ago
Message Not Public
Sign In & Join Server To View
it's just a test project that references a .net framework 4.5 dll
was interested in how it works without going through .net standard type forwarding
Unknown User•4mo ago
Message Not Public
Sign In & Join Server To View
here's a screenshot. apparently the magic is done by mscorlib.dll which the net fx assembly is referencing (not system.runtime). And mscorlib.dll seems like a subset of netstandard.dll with type forwards to the .Net Core types. Effectively you have an implicit netstandard.
both shims are in in the shared folder...but I guess also as ref assemblies
for more discussion:
https://github.com/dotnet/runtime/discussions/48705#discussioncomment-404171
GitHub
.NET Core console app references .NET Framework assembly · dotnet r...
Sorry for the question, I must be missing something, or doing something completely wrong. I just created a .NET Core 3.1 console app that references a .NET Framework 4.8 assembly. The console app c...
.NET (Core) apps can consume .NET Framework based assemblies since .NET Core 2.0, https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-2-0#support-for-net-framework-libraries
What's new in .NET Core 2.0 - .NET
Learn about the new features found in .NET Core.
From time to time the compatible surface expanded (like WinForms). But it is not possible to find a complete list.
If what you looked for is the actual code that realizes this feature, then CoreCLR source code is likely the only place (since I didn't see a section related to this part in "the Book of the Runtime").
well, the feature is the shim dll.s in .NET shared folder with type-forwards ( quite a lot of them tbh). Kind of nice to have this implicit .netstandard behavior