C#: Use .NET Core Nuget package stub i test #7257
Conversation
michaelnebel
force-pushed
the
csharp-nuget-packages
branch
from
d5cb866 to
e819b9a
Compare
michaelnebel
force-pushed
the
csharp-nuget-packages
branch
from
e819b9a to
59b71df
Compare
Didn't we end up basing it on the .NET 5 SDK? |
| @@ -0,0 +1,12 @@ | |||
| <Project Sdk="Microsoft.NET.Sdk"> | |||
There was a problem hiding this comment.
Why are we getting just .csproj files, and no .cs files? Perhaps @tamasvajk knows?
There was a problem hiding this comment.
We can remove the folders that contain only a .csproj file, but we need to also remove the reference to these .csproj files.
We probably end up with these projects, because the original assemblies didn't contain any public types. As far as I remember, we're creating the folder structure based on the project.assets.json file (and not the extracted types), which includes these assemblies too.
There was a problem hiding this comment.
Do you prefer that I manually go through the generated stubs and remove what is strictly not needed?
There was a problem hiding this comment.
In that case let's just leave them in.
The same stubs are generated for Microsoft.NETCore.App (module some comments mentioning NewtonSoft.JSon), when stubs are generated for NewtonSoft.JSon using net5.0 as the target framework compared to generating the stubs directly for Microsoft.NETCore.App version 2.2.8. |
In this PR we use a combination of auto generated and (existing) hand written stubs as a replacement for dll's in the flow summaries test.
We suspect that the rows that have been removed from the flow summaries are due to the fact that the summaries are now created based on Microsoft.NETCore.App version 2.2.8, which is from 2019, where as some of the dll's that it is replacing might be newer.
On the other hand more summaries have been introduced than removed.
It would be great, if we could have a project for using NETCore 6.0 as the basis for our stubs.
As a side effect, some cleanup was needed in the hand written stub System.Web.cs as we otherwise would have an overlapping implementation of the class HttpResponse (as it exists in Microsoft.NETCore.App). This has a rippling effect into other test cases, which relies on System.Web.cs. These have also been cleaned up and refers now only to auto generated and manually created stubs (this required autogenerating more stubs).