It is a common approach applied by .NET developers to give multipart names to the individual projects in a Visual Studio solution. The name parts identify different aspects of the Visual Studio project, a typical name pattern is “<CompanyName>.<Application>.<Component>”. Example of this: “TNV.Purchase.OrderManagement”.
I applied this naming approach also for a GWPAM project to build a Microsoft Outlook AddIn: TNV.TasksClustering.OutlookAddIn. However, after I installed the compiled AddIn, Outlook failed to load it. The error details were:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Resources.MissingManifestResourceException: Could not find any resources appropriate for the specified culture or the neutral culture. Make sure “TNV_TasksClustering_OutlookAddIn.Icons.resources” was correctly embedded or linked into assembly “TNV.TasksClustering.OutlookAddIn” at compile time’
I inspected the GWPAM generated code to analyze the problem cause. It appears that GWPAM replaces in the code that it generates, the dots (‘.’) in the Visual Studio project name into the underline (‘_’) character. Thus ‘TNV.TasksClustering.OutlookAddIn’ becomes ‘TNV_TasksClustering_OutlookAddIn’ in the generated C# code. But a side effect is that this results in a naming-inconsistency with embedded Resources: Visual Studio namely by default embeds .NET resources files in the compiled assembly with the unchanged project name, in this case thus still with the dots.
I have reported this issue to the Duet Enterprise / GWPAM product team. I expect it to be fixed in a forthcoming service pack. Until then, the pragmatic and simple workaround is to correct in the generated C# code the line that tries to load the embedded resource: