|
|
Rank: Newbie
Groups: Member
Joined: 8/30/2024
Posts: 2
|
According to the topic below you don't create .NET specific packages since it is safe to override the warnings. However, without .NET specific packages you run into issues when you use Central Package Management (CPM) in Visual Studio with Transitive Pinning enabled in CPM. When you use CPM without transitive pinning you can override the NU1701 on individual packages in the props-file, but when you enable transitive pinning to force vulnerable indirect dependencies to newer secure versions it becomes messy since the override solution doesn't work anymore. Having Essential Object binaries with target framework set to .NET and not .NET Framework would be really helpful to avoid awkward and potentially insecure workarounds like disabling NU1701 completely. Or do you have another solution to this problem? Your original statement about not needing a .NET specific package. https://www.essentialobjects.com/forum/postst12416_EOPdf-Nuget-Package-on-NET-Core-6-shows-exclamation-warning-icon.aspx
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,273
|
Thank you very much for your valuable feedback. We indeed plan to switch the package target to .NET from .NET Framework soon since this is the overall direction that Microsoft is pushing for.
|
|
Rank: Newbie
Groups: Member
Joined: 8/30/2024
Posts: 2
|
Looking at the latest EO.pdf.dll in JetBrains dotPeek tells me that it's still a .NET Framework v3.5 dll instead of .NETCoreApp v8.0. I can't see anything about a switch from .NET Framework to .NET in the change log either.
Nothing has happened in 5 months. Do you have an update on the timeline for switching target to .NET 8 or .NET Standard.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,273
|
Hi,
This is not implemented yet because our DLLs are too big. The "right" way to do this is to have a different set of DLLs for a different target. However due to the size of our DLLs this is not practical. The extreme large size of our DLL is due to the fact that native browser engine is embedded inside our DLL. So we can isolate the native browser engine code into a separate file we might be able to achieve this. This is a significant architecture change and this is why it's taking time.
Thanks
|
|