Error loading Vortice.Dxc libs (wrong .dll install path)

[Sergio0694]

Hi, me and @Aminator are currently moving from DotNetDxc to Vortice.Dxc, and we noticed that the latter copies the two dxcompiler.dll and dxil.dll files to the wrong directory. Currently, those .dlls are placed under the runtimes\win-x[64|86]\native path, but that causes a runtime exception, as the caller of those .dlls is only looking for them next to the entry point of the app.

Right now I'm getting this error:

As a test, manually copying the two .dlls to the output folder solves the issue.
Would it be possible to setup the NuGet package so that instead of placing those .dlls into the runtime tree, it would just copy the correct ones (depending on the CPU architecture) right to the output folder, next to all the other .dll files?

Thanks! 😄

[amerkoleci]

I'll take a look, the executable assembly is netcoreapp or ne framework executable?

[Sergio0694]

Hey, thank you for the quick reply!
My executables are .NET Core 3.0, as my library is targeting .NET Standard 2.1.
In case having a repro would help, you can clone the feature_vortice-windows branch from ComputeSharp, and try to run any of the sample projects (I tried running the bokeh blur sample).
They all work fine in the master branch, as it's using DotNetDxc with local .dll files (as the ones in that package are outdated).

I believe @aAminator is using his code from both a .NET Core 3.0 sample project and a UWP app, with the same issue once he tried moving to Vortice.Dxc.

Thanks again for your help! 😄

[amerkoleci]

Should be fixed now, try the "1.0.0-gea9e6e7273" version and report if it works.

Thanks

[Aminator]

Compiling works now, but it fails when trying to create a pipeline state. Manually putting dxil.dll next to the executable fixes this issue. This only appears in .NET Core 3.0, UWP works fine.

[amerkoleci]

Not sure how can I workaround that issue @Aminator

[Sergio0694]

@Aminator wait, why is UWP working though?

@amerkoleci Isn't there a way to make the NuGet package copy that .dll directly to the output folder and not to a subdirectory of it?

[Aminator]

@Sergio0694 Because UWP doesn't copy them to the runtimes folder, but instead places them next to the executable.

[Sergio0694]

Can't that be done always, regardless of target framework?
I mean, from the .nuspec/.targets file or something.

[amerkoleci]

I think yes, not sure why it doesn't work tho, probably need build/netstandard2.0/Vortice.Dxc.targets

[Sergio0694]

Yeah that sounds like a good idea!
Hopefully that'll solve the issue, we're actually so close now 😄

[Sergio0694]

Hey @amerkoleci - I tried upgrading to the latest CI build and it works! 🎉
You did a great job, thank you so much for your help!

Just one last small detail: after updating the Vortice.Dxc package I now see the \binaries folder in my project, from the VS solution explorer (this happens in my test project as well, not just from the ComputeSharp project itself). I'm wondering if maybe changing this line and setting Visible to false would solve the issue? Again, just a small detail, the new build does work though! 😊

Bonus question: I'd like to publish my ComputeSharp lib to NuGet but I'm not sure how to handle the MyGet package source in the package, that is, if there's some option I need to set in my .nuspec file to achieve that for users installing my NuGet package. Do you know how to do that?
Or, if you plan to release a (preview maybe) package of Vortice on NuGet soon enough anyway, I might as well just wait for that one instead. Any ETA on that?

Again, props for the great work, this lib is already looking great so far! 🍻

[amerkoleci]

HI @Sergio0694,
Glad it worked, The visible is false now.

I will release 1.0.0 official nuget packages today, stay updated :)

[amerkoleci]

Nuget packages has been published and on nuget now, please take look at: https://www.nuget.org/packages?q=Tags%3A%22vortice%22