Nuget package is invalid with transient netstandard usage
Closed this issue · 8 comments
If I have a library targeting netstandard2.0 that consumes the Avalara api package, and it is referenced by a net framework 4.6.1 or later project the API can not be used and fails with the following:
System.IO.FileNotFoundException: Could not load file or assembly 'Avalara.AvaTax.netstandard11, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
Repro can be found here: https://github.com/ssa3512/Avalara-Targeting-Issue
git clone https://github.com/ssa3512/Avalara-Targeting-Issue.git
cd Avalara-Targeting-Issue
dotnet test .\NetFrameworkApplication\NetFrameworkApplication.csproj
A possible workaround for this is to add an additional fourth target in the nuspec for net461 that mirrors the netstandard1.6 target. This would ensure that net461 and later reference the netstandard1.6 dll instead of the net40 dll.
@contygm @greg-hester-avalara are community contributions/issues welcome here? This issue is totally blocking us from using the published package - we had to fork and publish an internal package modified with a net462 target that uses the netstandard dll which is less than ideal.
It's easy enough to fix this by adding an additional target to the nuspec but I am not sure if external PRs are considered - there are no contributing guidelines and I have an open PR from March that doesn't appear to have been looked at at all.
@ssa3512 Closing this issue as a lot has changed with supported .net versions in last two years. If it is still an issue, please reopen.
Thanks.
@svc-developer this is absolutely still an issue. We are currently running against a fork to make this scenario work. The issue is that the DLLs for netstandard2.0 and net461 in the nuget package are named differently. A .NET framework version >= 4.6.2 can reference a project targeting netstandard2.0 but resolves the net461 version of the package at compile time. The code for the netstandard2.0 library is expecting the assembly name to be the same.
Please see the minimal repro repository and steps I linked in the initial post. I have just updated these to the latest avatax package and confirmed this is still an issue.
@svc-developer your package structure has changed since I logged the initial issue, but the fundamental root cause (different assembly names for netstandard and net461) is still there. The updated error message from the repro is:
Test method NetFrameworkApplication.Test.CanUseNetStandardLib threw exception:
System.IO.FileNotFoundException: Could not load file or assembly 'Avalara.AvaTax.netstandard20, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
@ssa3512 We did a new release for 22.8.0 where we tried to resolve this issue. Please upgrade and try whenever you have a chance, we would love to hear any feedback
I am seeing a similar issue. I have a .netstandard 2.0 project that can make calls to the Avalara API OK. Once I reference that project in a .Net framework 4.7 project, the calls fail with this error: Could not load file or assembly 'Avalara.AvaTax.RestClient, Version=22.8.0.0, Culture=neutral, PublicKeyToken=be94eb8ba37fd33c' or one of its dependencies. The system cannot find the file specified.
@bbalchberkone Just to make sure I understand the use case. You are saying you have one .netstandard 2.0 project which works fine. Then you have a second project which uses .NET Framework 4.7 and uses the first project as a dependency to make calls to Avatax API?
If that is the case, can you verify that Avatax nuget package is restored in the .NET framework 4.7 project through the visual studio "Manage Nuget packages" option. Thanks
You're understanding of the scenario is correct. I added the Avatax Nuget package to the .Net framework 4.7 app that was referencing the .net standard app and it appears to be working now. It does seem odd that this is needed since all of the logic and connections to the Avalara SDK happen in the .Net standard class app. In any event - thanks for the quick response and help - this is going to be a huge time saver in avoiding the need for an alternate solution.