In VS project files, code and resources files can have a <DependentUpon> child element that refers to another file. When set, the dependent files will be nested under the other file in the IDE's project tree.
While this is usually purely cosmetic, the nesting is actually significant in some scenarios: I have published a (sample code) package that includes a Windows Forms form (a .cs file, a .Designer.cs file and a .resx file). When adding that package to a project, the application crashes with a System.Resources.MissingManifestResourceException. If the .resx file is marked as dependent upon the .cs file, this exception does not occur and the form can be displayed as expected.
As far as I could find out, there is no way to tell the .nuspec file in the <file> element to make a certain file dependent upon another file in the project file it is inserted to. It would be helpful if the <file> element in .nuspec files could have an optional dependentUpon attribute that, when set, would cause the creation of a respective <DependentUpon> element in the target project file upon inclusion of the package.
Comments: @fhaag yes .settings with .resx I've got it working now as suggested by dotnetjunky https://github.com/MrAntix/antix/blob/48d488c75359ac4aa5ee3f4ea3c0f3616a8a400b/nuget/install.ps1 on line 16, you'll be looking for .resx and you'll need to set the custom tool to "ResXFileCodeGenerator" elseif( $projectItem.Name.EndsWith(".settings") ) { $property = $projectItem.Properties.Item("CustomTool"); if($property.Value -eq "") { Write-Host "Running custom tool on " + $projectItem.Name $property.Value = "PublicSettingsSingleFileGenerator" $property = $projectItem.Properties.Item("CustomToolNamespace"); $property.Value = $namespace.TrimStart(".") $projectItem.Object.RunCustomTool() } something to note, I am having to set the namespace too, this is because the generated file would be created in the namespace of the assembly and directory path - I don't want this to happen as I have code which references settings in a specific namespace .. you may not have this situation, just so you know
While this is usually purely cosmetic, the nesting is actually significant in some scenarios: I have published a (sample code) package that includes a Windows Forms form (a .cs file, a .Designer.cs file and a .resx file). When adding that package to a project, the application crashes with a System.Resources.MissingManifestResourceException. If the .resx file is marked as dependent upon the .cs file, this exception does not occur and the form can be displayed as expected.
As far as I could find out, there is no way to tell the .nuspec file in the <file> element to make a certain file dependent upon another file in the project file it is inserted to. It would be helpful if the <file> element in .nuspec files could have an optional dependentUpon attribute that, when set, would cause the creation of a respective <DependentUpon> element in the target project file upon inclusion of the package.
Comments: @fhaag yes .settings with .resx I've got it working now as suggested by dotnetjunky https://github.com/MrAntix/antix/blob/48d488c75359ac4aa5ee3f4ea3c0f3616a8a400b/nuget/install.ps1 on line 16, you'll be looking for .resx and you'll need to set the custom tool to "ResXFileCodeGenerator" elseif( $projectItem.Name.EndsWith(".settings") ) { $property = $projectItem.Properties.Item("CustomTool"); if($property.Value -eq "") { Write-Host "Running custom tool on " + $projectItem.Name $property.Value = "PublicSettingsSingleFileGenerator" $property = $projectItem.Properties.Item("CustomToolNamespace"); $property.Value = $namespace.TrimStart(".") $projectItem.Object.RunCustomTool() } something to note, I am having to set the namespace too, this is because the generated file would be created in the namespace of the assembly and directory path - I don't want this to happen as I have code which references settings in a specific namespace .. you may not have this situation, just so you know