And I think we have the issue with the Font and Texture provider as well.

Yes, the same UriConverter code is used for all the resources: xamls, fonts, images...

Hi Sergio,

Do you have update on this issue ?
The number of Noesis vcxprojs are growing, and it's becoming more difficult for us to work around this.
We need to make sure to not using XAMLs with identical filenames (although they are belong to different projects), because our XAML provider is searching for the filename on all possible subdirectories.

Hi,

We are thinking on extending providers api with a new function that will receive both path and assembly as an Uri object. For example for the XamlProvider:

virtual Ptr<Stream> LoadXaml(const Uri& uri) = 0;

Do you think this would work in your case?

Hi Sergio, thanks for the consideration.

Yes, I think it's sufficient for us if we can tell the assembly name from the Packed URI.
We are also OK with the scheme you proposed for version 3.0 and 3.1.

Hi Sergio. Could we have an update for this issue? Do you have plan to implement the fix in 3.0, or should we wait for 3.1?

We tried to incorporate this but found some complications and had to delay it until next major version.
Sorry for the inconveniencies.

I see. Thank you for the update. By next major version you mean 4.0? Not 3.1?

3.1, the next major release. Soon we are going to have a meeting to discuss about this and see if we find an easy solution.

Are there any updates on this issue? Is it still on schedule for the 3.1 release?

Hi Susanna,

We still plan to solve this for the 3.1 release. The idea is to incorporate the assembly information in the Uri object that will be received by the providers to load resources, for example:

virtual Ptr<Stream> LoadXaml(const Uri& uri) = 0;