XML Resources Dependent Upon Valid Code Files
If an XML file is dependent upon a valid language code file for the given project, and if a file code-model object can be obtained on the said file, then the manifest-resource name of the XML resource file is computed as follows: full name of the first class in the file that is the parent of the resource file + optional RFC 1766 culture info string (if supported by .NET Framework Resource Manager) + .resources.
If the parent of the XML resource file does not contain any class definitions, then the project system will fall back to the resource-naming scheme described in Non-dependent XML Resource Files.
For example:
Consider the following project hierarchy, where the full name of the first class in file Form1.vb is ACME.WidgetApp.MyClass: Project1->Form1.vb->Form1.resx. Then the manifest resource name for the XML resource file Form1.resx would be ACME.WidgetApp.MyClass.resources.
Consider the same project, except now Form1.resx is named Form1.de.resx. Since de is an RFC 1766 culture string supported by the Resource Manager, it is automatically included in the name of the resource. Consequently, in this case, the manifest resource name would become ACME.WidgetApp.MyClass.de.resources.
Consider the same project, except now Form1.resx is named Form1.de-ff.resx. Although de-ff is a valid culture info string as per RFC 1766, it is not a culture info string that is supported by the .NET Framework Resource Manager. Therefore, de-ff will not be included in the resulting manifest resource name, and the manifest resource name would be the same as in the first example.