Only manually load DLLs if onnxruntime.dll is not already loaded.

[chemwolf6922]

Why is this change made

Before this change, when using Windows ML. If the user initialize Windows ML before loading genai, there will be two onnxruntime.dll loaded into the python process, like this:

This is because Windows ML will try to load the onnxruntime.dll packed in the Windows App Runtime when it is initialized. But genai will also try to load the dml and ort DLLs packed in the onnxruntime python package. Result in duplicating DLLs.
Since Windows ML is not loading the DLL by path, it won't load the its DLL if genai is loaded first.

What changed

This PR checks if onnxruntime.dll is already loaded before loading the dml and ort DLLs manually. After this change, when running a dml model with Windows ML initialized first, the process' loaded library looks like this:


When loading WinML after genai, it behaves the same as before. (IMHO, using the DLLs from the Windows App Runtime and dropping the dependency on onnxruntime-winml seems more streamlined.)

[baijumeswani]

For the winml path, which process/code is responsible for loading onnxruntime.dll?
If the user's python script imports onnxruntime-genai first, would that mean that the onnxruntime.dll will be imported from the python packages instead of from winapp?
Does winapp not use the onnxruntime-winml python package?

[chemwolf6922]

For the winml path, which process/code is responsible for loading onnxruntime.dll?

The onnxruntime.dll will be loaded when the user creates the winml ep category. Which is the first call to winml.

If the user's python script imports onnxruntime-genai first, would that mean that the onnxruntime.dll will be imported from the python packages instead of from winapp?

Yes, winml won't import a second onnxruntime.dll if the user imports onnxruntime-genai first and loads the onnxruntime.dll from the ort python package.

Does winapp not use the onnxruntime-winml python package?

I'm not sure if any production app is using python winml currently. The user needs to carefully install the onnxruntime-winml that matches the winml/wasdk's version to get the exact onnxruntime.dll as the packed one. Allowing the user to just use the packed one in winml would make this easier and avoid the unnecessary dependency on onnxruntime-winml.

[baijumeswani]

Is there a plan to improve and streamline the Python WinML user experience? It could be worthwhile to explore a design that is more intuitive and user‑friendly.

[chemwolf6922]

Is there a plan to improve and streamline the Python WinML user experience? It could be worthwhile to explore a design that is more intuitive and user‑friendly.

The major problem with the Python WinML complication is how the onnxruntime python package works. With its inclusion of all the implementation in the .pyd file. I don't think there is much that we can do w/o major changes to that.
I have a toy project that builds an ort python wheel on top of the C interface: https://pypi.org/project/ortpy/ . But I won't expected that to be a formal solution😂