All binaries we release should have corresponding symbols.
We seem to have a manual process for building MKLImports due to the Intel MKL SDK dependency: https://github.com/dotnet/machinelearning/blob/04dda55ab0902982b16309c8e151f13a53e9366d/docs/building/MlNetMklDeps/README.md#windows
It would seem that the packages produced manually are missing the PDBs:
https://dev.azure.com/dnceng/public/_packaging?_a=package&feed=machinelearning-assets&package=MlNetMklDeps&protocolType=NuGet&version=0.0.0.9&view=overview
So that when we redistribute this binary it is missing debug information.
At a minimum we should include the PDBs and redistribute those in the same way we do other native code that we build. This won't impact our final package size, only the MlNetMklDeps transport package.
Ideally we should include the build of this component as an optional part of our regular build process, so that we aren't relying on a manual build process. We still might want to keep MlNetMklDeps around so that contributors don't need to install the Intel MKL sdk if they want to build the entire product.
All binaries we release should have corresponding symbols.
We seem to have a manual process for building MKLImports due to the Intel MKL SDK dependency: https://github.com/dotnet/machinelearning/blob/04dda55ab0902982b16309c8e151f13a53e9366d/docs/building/MlNetMklDeps/README.md#windows
It would seem that the packages produced manually are missing the PDBs:
https://dev.azure.com/dnceng/public/_packaging?_a=package&feed=machinelearning-assets&package=MlNetMklDeps&protocolType=NuGet&version=0.0.0.9&view=overview
So that when we redistribute this binary it is missing debug information.
At a minimum we should include the PDBs and redistribute those in the same way we do other native code that we build. This won't impact our final package size, only the MlNetMklDeps transport package.
Ideally we should include the build of this component as an optional part of our regular build process, so that we aren't relying on a manual build process. We still might want to keep MlNetMklDeps around so that contributors don't need to install the Intel MKL sdk if they want to build the entire product.