Namespace conflict of ZString and SmartFormat.ZString packages

[israellot]

If I want to use both SmartFormat and original ZString packages I get a conflict because the same types are defined in both assemblies. This is due to the inlining of ZString code into this project. Another solution is to use another namespace for the internal ZString implementation.

[axunonb]

Hi, conflicts of namespaces can easily be resolved as described here. This could happen any time with any package. As SmartFormat won't work without ZString, we opted for adding a specific version as part of SmartFormat that also natively supports net461, which ZStringdoesn't.

[israellot]

I guess that's fair @axunonb , but in that case I believe it should be under a different namespace, other than Cysharp.Text , or even made internal to the assembly so that the tweaked ZString implementation does not leak outside SmartFormat's assembly. To be clear, when adding SmartFormat's reference I expect to interact with a certain public api. A public ZString api is definitely not something I would expect to part of that api.

[axunonb]

Cysharp.Text , ... made internal to the assembly

How would you do that? Doesn't it actually mean to change all public classes to internal visibility?

[israellot]

Precisely @axunonb, that would do the trick. Besides that, I would change prepend SmartFormat to the namespace so that all classes that the library maintains in its source are within the same root namespace. If you want, I would be happy to submit a PR.

[axunonb]

Sorry for the delay. Yes, this sounds simple to accomplish with ReSharper, but would have to be applied again with new releases of ZString and thus was kind of error-prone. Do you see a way to automate in a safe manner?

[israellot]

I believe it could be automated as part of the build process using some tool like :

https://github.com/gluck/il-repack https://github.com/nullean/assembly-rewriter

[axunonb]

The /internalize argument of il-repack looks like what was needed. But same as LibZ and others the projects were last updated few years ago, and I wonder whether they're compatible with latest .NET Framework versions. Quite a hack after all, isn't it - considering ZString is open source? Unfortunately, even a simple search and replace for publicto internal isn't really straight-forward.

[Update] Just came across this blog post: Alias: An approach to .NET Assembly Conflict Resolution, pointing to a quite new GitHub project named Alias. It also was an argument to --internalize.

[MagicAndre1981]

I still got the conflict @axunonb and I think it worked for some time

[MagicAndre1981]

@axunonb downgrade to 3.3.0 fixed it. Comparing the versions show that #368 reverted the fix you've done here.

Why don't you add the nuget reference of ZString to your lib and consume it instead of duplicating ZString code and adding it to your lib?

[MagicAndre1981]

ok, removing ZString Package Reference from my csproj also fixes it which is totally confusing.

[axunonb]

Why don't you add the nuget reference of ZString to your lib and consume it instead of duplicating ZString code and adding it to your lib?

This is still because of framework v4.6.1 not supported by Cysharp.ZString. The automatic internalization didn't run after the last ZString update, and that's the reason for the namespace collisions your referring to. We'll publish an updated package. Thanks for your hint.

[MagicAndre1981]

This is still because of framework v4.6.1 not supported by Cysharp.ZString.

ok, but why do you still support this? ZString has .net standard 2.0 support which makes it work with 4.6.1 (with additional system dll deployment to output folder), but 4.6.1 is out of support for nearly 2 years (April 2022).