Remove library extractor #18
Conversation
|
Holy moly - I've been down rabbit-hole again around how to support both dotnet core and dotnet framework in a nuget package and its still not good news. NuGet/Home#6645 I don't think we should remove this library extraction stuff at the moment as it still seems the most straightforward way of doing it, but I do think we should look into why it doesn't work for Framework projects. One benefit of doing the library extraction in code is that the user doesn't have to target x86 or x64, they can leave As AnyCPU and the wrapper will take care of extracting the appropriate runtime. |
|
Wow. That's... quite a read. I think I understood about one word in five on that NuGet issue. I really need to solve the same issue with Java and now I am really not looking forward to it at all! |
|
I'm not sure how the java ecosystem works, but the difficulties with Nuget
feel pretty specific to Nuget packages. İt's because it's trying to target
two completely different implementations of dotnet.
…On Sun, 5 Jul 2020, 14:12 Kyle Hayes, ***@***.***> wrote:
Wow. That's... quite a read. I think I understood about one word in five
on that NuGet issue.
I really need to solve the same issue with Java and now I am really not
looking forward to it at all!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#18 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AESB447YQ7ENRR6ZQ77SXETRZ74TJANCNFSM4OQFTOHQ>
.
|
This still doesn't work for dotnet framework out of the box. But it does work for dotnet core projects.