Build failure: static resource folder edgecase

[PrestonSam]

Build fails with the following project layout:

my-project.csproj

  ...
  <ItemGroup>
    <StaticResourceFolder Include="data/Example"/>
  </ItemGroup>
  ...

Folder structure

project-root/data/Example/

• file.json
• otherfile.json
• Subfolder/

The json files simply have {} inside them

Build fail output

MSBuild version 17.4.0+18d5aef85 for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
/home/sam/.../obj/Debug/net7.0/SylvanStaticResources/data/Example.g.cs(68,25): error CS0756: A partial method may not have multiple defining declarations [/home/sam/.../my-project.csproj]
/home/sam/.../obj/Debug/net7.0/SylvanStaticResources/data/Example.g.cs(60,2): error CS0579: Duplicate 'global::System.Diagnostics.DebuggerNonUserCode' attribute [/home/sam/.../my-project.csproj]
/home/sam/.../obj/Debug/net7.0/SylvanStaticResources/data/Example.g.cs(68,25): error CS0111: Type 'Example.Subfolder' already defines a member called 'PreProcess' with the same parameter types [/home/sam/.../my-project.csproj]
/home/sam/.../obj/Debug/net7.0/SylvanStaticResources/data/Example.g.cs(70,19): error CS0111: Type 'Example.Subfolder' already defines a member called 'Process' with the same parameter types [/home/sam/.../my-project.csproj]

Build FAILED.

/home/sam/.../obj/Debug/net7.0/SylvanStaticResources/data/Example.g.cs(68,25): error CS0756: A partial method may not have multiple defining declarations [/home/sam/.../my-project.csproj]
/home/sam/.../obj/Debug/net7.0/SylvanStaticResources/data/Example.g.cs(60,2): error CS0579: Duplicate 'global::System.Diagnostics.DebuggerNonUserCode' attribute [/home/sam/.../my-project.csproj]
/home/sam/.../obj/Debug/net7.0/SylvanStaticResources/data/Example.g.cs(68,25): error CS0111: Type 'Example.Subfolder' already defines a member called 'PreProcess' with the same parameter types [/home/sam/.../my-project.csproj]
/home/sam/.../obj/Debug/net7.0/SylvanStaticResources/data/Example.g.cs(70,19): error CS0111: Type 'Example.Subfolder' already defines a member called 'Process' with the same parameter types [/home/sam/.../my-project.csproj]
    0 Warning(s)
    4 Error(s)

[MarkPflug]

Thanks for the bug report. Indeed, it looks like I was only expecting a "top level" folder to be named when I implemented this.

What do you expect the behavior to be when you provide a sub-folder like in your example? Should I interpret the data segment as a namespace, or ignore it and generate code as if Example was a top-level folder?

I would lean toward inserting a namespace, with the ability to override. What are your thoughts?

[PrestonSam]

Hi Mark,

Thanks for taking the time to look into this :)

I think that

  ...
  <ItemGroup>
    <StaticResourceFolder Include="data/Example"/>
  </ItemGroup>
  ...

Should yield Data.Example as a namespace.

I would also prefer that nested folders would be interpreted as namespaces in their own right. i.e. the same XML code shown above would also produce the Data.Example.Subfolder namespace, as that would would allow me to automatically create complex nested namespaces by simply including the topmost relevant folder.

I agree that both behaviours should be possible to disable with an attribute to prevent the tool from becoming inconvenient in some circumstances, though.

[MarkPflug]

In your example, "data" would be inserted as a namespace and "Example" would be the class name, then each individual file would be a property of that class. Nested folders are already supported. You can add more folders under Example, and nested classes would be generated for them, so you can reference them as Example.SubFolder.File. If you change your StaticResourceFolder to Include="data", then Data would be a class, and Example should be a nested class. The only change I'm proposing is that when you Include a folder that is not a top-level folder, then everything up to the final folder in the path would be interpreted as a namespace.

Hopefully that makes sense.

[PrestonSam]

Ah! I see! I was unaware that nested folders were already supported. I should make use of that feature.

But I do agree that the parent folders (up until the project root) should be included in the namespace as it'd isolate all generated classes under a dedicated namespace, reducing the chance of a generated class duplicating the name of a class in the source code.