Forums | NoesisGUI

I have a project that builds and runs fine on 3.1.2. However, after updating the NuGet packages to 3.1.5, I am given this error:

[NOESIS/W] Can't register embedded resources for 'NoesisDotNetFrameworkTest', no common namespace in types and resources found
[NOESIS/E] Xaml not found 'App.xaml'
Exception thrown: 'System.InvalidOperationException' in Noesis.App.dll
An unhandled exception of type 'System.InvalidOperationException' occurred in Noesis.App.dll
Startup window not defined

Downgrading back to 3.1.2 solves this issue.

Has anyone else run into this issue?
Thanks.

Hi,

In an attempt to simplify resources management in the C# SDK we made a few changes to the Application resource providers. We now try to automatically register all the embedded resources in any loaded assembly. To achieve that we try to find a common namespace in the assembly that we then use as the prefix to search for the embedded resource names, because Visual Studio stores them in the assembly as 'DefaultNamespace.Path.To.The.Resource.ext'.

In your NoesisDotNetFrameworkTest project, what is the Default namespace defined in the project settings? Is that used as the base namespace for all your type definitions in the assembly? For example, if the Deafult namespace is A, are your types in the form A.Type1, A.B.Type2, A.B.C.Type3...?

We have a large body of code that we want to port from WFP to Noesis. Does this mean that we will have to go through it all and change the namespaces, using statements and fully qualified class names to use new namespaces?

colin14321 showed me his project, and the offending class was unrelated to App.xaml, and did not itself reference any embedded resources. Does this imply that the algorithm that finds the common namespace chose the wrong one? This is going to play havoc with porting existing code, and even more when trying to share source files among projects using links, where fixing the namespace for Noesis will break it for other projects sharing that source.

Is there something we can do to disable this behaviour, or at least guide it?

We have a large body of code that we want to port from WFP to Noesis. Does this mean that we will have to go through it all and change the namespaces, using statements and fully qualified class names to use new namespaces?

Of course not, the approach we followed was incorrect and should be considered a bug that we are going to fix for the next release.

Is there something we can do to disable this behaviour, or at least guide it?

Unfortunately no, you'll have to downgrade to a previous version until the next version is released.
Sorry for the inconvenience, we are are working on solving this as quickly as possible.

Thank you. We are still in a preparatory phase of the project, working out how to approach a port, so we can work with 3.1.2 for now.

In an attempt to simplify resources management in the C# SDK we made a few changes to the Application resource providers. We now try to automatically register all the embedded resources in any loaded assembly. To achieve that we try to find a common namespace in the assembly that we then use as the prefix to search for the embedded resource names, because Visual Studio stores them in the assembly as 'DefaultNamespace.Path.To.The.Resource.ext'.

In your NoesisDotNetFrameworkTest project, what is the Default namespace defined in the project settings? Is that used as the base namespace for all your type definitions in the assembly? For example, if the Deafult namespace is A, are your types in the form A.Type1, A.B.Type2, A.B.C.Type3...?

Hi @sfernandez,

I'm in the same situation. I'm a little new to C# though, could you elaborate on the changes needed?

Thanks,
cpasjuste

Hello, as I mentioned before the change we made for 3.1.5 was incorrect and should be considered a bug. We are working on solving this for the next release coming very soon. In the meantime I recommend staying at 3.1.4 version to avoid changing anything from your project.

Hello, as I mentioned before the change we made for 3.1.5 was incorrect and should be considered a bug. We are working on solving this for the next release coming very soon. In the meantime I recommend staying at 3.1.4 version to avoid changing anything from your project.

Yes your right, I can "work" with 3.1.4 ...
On a side note, I do only have this problem on Linux (Ubuntu), on windows no problem.

Thanks for your time :)

This has been fixed in 3.1.6, ticket #2463