Option to prevent the prefix from being added to the output path

[MrMikeJJ]

Hi,
It would be nice if there was an option to prevent the Prefix from being added to the output path
thanks
Mike

[MrMikeJJ]

Hi,

The prefix is only used for autogenerated namespaces, not explicit namespaces.

When i was playing around with this, i seemed to get mixed results.
As in, when ran through the library - yes that is how it works through the GeneratorConfiguration constructor.

However i seem to get different results when ran from the EXE - it always adding it. I believe it is because the command line version goes through CodeUtilities.ParseNamespace which seems to always append the Prefix. (so is this inconsistant behaviour a bug ?)

So, what i was requesting with this feature request, was really how i was expecting it to work:
Added Prefix always added and output into the directory specified.

e.g. for an XSD with namespace "Foobar" - set to separate files
with the output directory - ProgramDirectory\Entities\Xml
and the prefix to be "ProgramName.Entities.Xml"

Expecting files to like
ProgramDirectory\Entities\Xml\Foobar\Foo.cs
ProgramDirectory\Entities\Xml\Foobar\Bar.cs
with namespace "ProgramName.Entities.Xml.Foobar"

Also, while i was testing the behaviour of this running as a library, i wrote about 20 unit test (which test the current behaviour) - with the Prefix being added in a few different ways, 1 file vs Separate files, etc.
Would you like a PR for these Unit Tests ? (they run of a local copy of the sample Xsd from https://docs.microsoft.com/en-us/visualstudio/xml-tools/sample-xsd-file-simple-schema?view=vs-2022

[mganss]

Sure. If you're interested, a PR implementing the behavior you have described (optionally create separate folders for every namespace component) would be welcome as well.

[Eddie-Hartman]

@mganss AFAIK this wasn't implemented right? I'm in a similar boat where I'm specifying the namespace as Foo.Bar and have an output specified as to the folder "Test/Foo/Bar", but then the files actually output to "Test/Foo/Bar/Foo.Bar" which doesn't really seem right (to me it seems like a bug since I told it where to output and it created a folder below that instead and C# namespaces typically follow the folder structure).

For anyone finding this issue later, I grabbed the code and looked at FileOutputWriter.cs and noticed that you can specify SeparateNamespaceHierarchy which would make the folders. So as a workaround (or maybe the intended use), I just specified the output folder as "Test" and it just wrote to "Test/Foo/Bar" as expected.

If anyone wants a pr the actual fix above instead of using this, you'd just have to add a new parameter for like "FlattenOutputDirectory" or whatever you want to call it and in FileOutputWriter.cs check for that in the WriteSeparateFiles and not add the namespace directory.

[mganss]

@Eddie-Hartman This is indeed the intended use of --nh. If you don't include the namespace in the file name or directory hierarchy, how would you treat classes with the same name in different namespaces?

[Eddie-Hartman]

@mganss if the option were added, you could have it throw an error when that occurs saying you can't have a flat output with classes with the same name in different namespaces. In my case, they're all the same namespace so having an extra folder isn't necessary. If it were added as an option instead of changing default it wouldn't be a breaking change, but again wanted to document how I got what I wanted in this issue so if others find it they can use it too.

[mganss]

@Eddie-Hartman Another option would be to have an automatic fallback to one of the other strategies. Or to include the namespace name in the file name if class name clashes would occur otherwise (NamespaceA.Class.cs, NamespaceB.Class.cs). Would you like to create a PR?

[Eddie-Hartman]

Maybe, though not likely. I was happy with the -nh option and did exactly what I needed so I don't necessarily need this anymore.

[mganss]

@Eddie-Hartman OK thanks, it seems like an edge case anyway.

If someone else wants to grab this, go ahead 😄