- colin14321
- Posts: 12
- Joined:
Updating from 3.1.2 to 3.1.5 causes build failure.
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.
[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.
-
sfernandez
Site Admin
- Posts: 2991
- Joined:
Re: Updating from 3.1.2 to 3.1.5 causes build failure.
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...?
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...?
Re: Updating from 3.1.2 to 3.1.5 causes build failure.
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?
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?
-
sfernandez
Site Admin
- Posts: 2991
- Joined:
Re: Updating from 3.1.2 to 3.1.5 causes build failure.
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.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?
Unfortunately no, you'll have to downgrade to a previous version until the next version is released.Is there something we can do to disable this behaviour, or at least guide it?
Sorry for the inconvenience, we are are working on solving this as quickly as possible.
Re: Updating from 3.1.2 to 3.1.5 causes build failure.
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.
Re: Updating from 3.1.2 to 3.1.5 causes build failure.
Hi @sfernandez,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...?
I'm in the same situation. I'm a little new to C# though, could you elaborate on the changes needed?
Thanks,
cpasjuste
-
sfernandez
Site Admin
- Posts: 2991
- Joined:
Re: Updating from 3.1.2 to 3.1.5 causes build failure.
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.
Re: Updating from 3.1.2 to 3.1.5 causes build failure.
Yes your right, I can "work" with 3.1.4 ...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.
On a side note, I do only have this problem on Linux (Ubuntu), on windows no problem.
Thanks for your time :)
Re: Updating from 3.1.2 to 3.1.5 causes build failure.
This has been fixed in 3.1.6, ticket #2463
Who is online
Users browsing this forum: Ahrefs [Bot], Semrush [Bot] and 69 guests