Feature #2873
closedIncomplete Filtered Assembly References in NuGet package for Saxon-HE 9.7.0.7
0%
Description
Hi,
We've found that the new .NET Core CLI (even when targeting a .NET full framework like 4.5.1) does not copy all necessary assemblies when creating a build. This results in a 'System.IO.FileNotFoundException' (Could not load file or assembly saxon9he).
The package has a configured filtered assembly reference to 'saxon9he-api.dll' (see attachment, bottom-left corner).
We've created a local package based on the Saxon-HE 9.7.0.7 package and testes the following two cases:
-
Add the 'saxon9he.dll' to the Filtered Assembly Reference
-
Remove both files from the Filtered Assembly Reference, so there is no filter applied at all
We came to the conclusion, that when having no filtered assembly references or having both of them explicitly set, both the 'saxon9he.dll' and 'saxon9he-api.dll' gets copied to the bin folder. When specifying only a single assembly reference, only that single assembly gets copied (that is the case for Saxon-HE 9.7.0.7 package when using the new .NET CLI).
The same sort of discussion was going on GitHub at: https://github.com/dotnet/cli/issues/3929
Our guess would be to also add the 'saxon9he.dll' to the Filtered Assembly Reference for the NuGet package.
Is it possible for Saxonica to fix this in the next package release?
Files
Updated by Michael Kay over 8 years ago
The Nuget package which you refer to is not produced by Saxonica; it appears to have been produced by Max Toro. In Saxonica we have no experience of this area but it is clearly something we need to look into. At present I'm not sure (a) whether Nuget is something that's only relevant in the context of .Net Core, and (b) whether Saxon (or other IKVM-generated dlls) can be supported on .NET Core. We will investigate; meanwhile if you can help us up our learning curve in this area, that will be appreciated.
Updated by Michael Kay over 8 years ago
- Status changed from New to Won't fix
I'm afraid the bad news is that Jeroen Frijters, the lead developer of IKVMC, tells us that .NET Core is not currently supported as a target platform by IKVMC, and that supporting it is a lot of work and won't happen any time soon. Saxon on .NET is totally dependent on IKVMC, and is therefore not supported on this platform.
Updated by Erik van Leeuwen over 8 years ago
Hi Michael,
thanks for taking the time to answer my question.
I understand .NET Core support is not on the roadmap for now, but my question is not really about supporting .NET Core (since we still target .NET 4.5.1). It's just that the .NET CORE CLI tool is respecting the 'assembly references filter'.
What i am actually reporting, is that assembly references are explicitly filtered (https://docs.nuget.org/create/nuspec-reference#specifying-explicit-assembly-references) inside the NuGet package (https://www.nuget.org/packages/Saxon-HE/9.7.0.7), while a reference filter shouldn't have been applied at all.
Apparently Max Toro created this package using the Saxonica name as the author ( https://www.nuget.org/packages/Saxon-HE/ ).
The assembly filter bug is inside the package he created.
To answer your question, a NuGet package is not specifically for .NET Core, it is a very common used package manager for .NET since 2010 and is integrated in Visual Studio since VS2012.
So would it be possible to investigate to release an official NuGet package by Saxonica that fixes the assembly reference filter? Meanwhile, I will consider not using the current nuget package since it is not an official release from Saxonica.
Updated by Michael Kay over 8 years ago
- Tracker changed from Bug to Feature
- Status changed from Won't fix to New
- Assignee set to O'Neil Delpratt
Yes, I think we should release an official NuGet package for Saxon on .NET, so I have reopened this bug and reclassified it as a feature request.
Updated by Tom Groeneboer about 8 years ago
Any updates on this? Did you instruct maxtoroq to investigate this issue?
Updated by Michael Kay about 8 years ago
No updates, sorry. It's on the list of possible new developments, queued up behind other things that we are busy with.
Updated by O'Neil Delpratt over 5 years ago
- Description updated (diff)
- Status changed from New to Closed
This issue has been overtaken by events.
Please register to edit this issue