在命名空间中的特殊字符 [英] Special characters in a Namespace

问题描述

我正在考虑使用字符与一个自定义的框架命名空间发音符号（如O）。这个想法已经想出一个方法来区分产品，但我想，以确保这不是一个坏主意，如果有任何关于它会回来后咬我。我还没有看到使用特殊字符在我的搜索命名空间的其他例子，也没有对这个话题的任何类似的讨论，这使我停留在继续沿着这条道路。

我最初考虑命名大会用变音标记为好，但第一个搅局者我遇到了在试图进行数字签名的程序集。我无法得到的特殊字符出现在命令提示符下，所以我得到了一个不合法的输入错误。也许还有另一种解决方法吗？

有一个问题我知道的是，它使打字了Visual Studio中的命名空间更具挑战性。我没有看到这是一个大问题，但是，由于该角色将走近我使用这个词的结尾，这个词将是相当独特的，与智能感知这不应该是太大的问题。

考虑下面的例子，包含在装配Macron.dll：

 命名空间Macrōn.Library
{
    公共类MyLibrary的
    {
        公共字符串{myProperty的获取;组; }
    }
}
 

似乎有没有问题产生和使用本Macron.dll，并且没有问题区分此示例Macrōn.Library命名空间。该文件，文件夹，项目和放大器;解决方案的名称似乎长音符号不会引起任何问题，一切似乎嘲弄没有任何问题的源代码控制。

任何其他因素或事情，我在一个装配和命名空间中的变音记号时失踪？在避过我的问题签署了装配有什么想法？这是做法注定会失败？难道真的不值得实施，因为它可能会产生混淆，或以其他方式难以/晦涩的使用？

这会变成大量的工作后来取消了，所以我想知道如果我拍摄自己的脚前，我太深入到这一点。

感谢。

解决方案

  

我想可以肯定这不是一个坏主意，如果有任何关于它会回来后咬我。

这是有效的。许多混淆器更改命名空间/类型有单code字，有的甚至不可打印，使逆向工程更加困难。

话虽这么说，如果这是一个公共框架，别人会消费，我会劝阻。这将使用命名空间来保存他们的源文件的Uni code / UTF8强迫任何人，如果他们不这样做，将O字符可能会被替换为？。然后，它会不再进行编译。

阿列克谢提出了很好的意见为好。我不知道如何键入不是拷贝和粘贴等的O字。这将肯定我慢下来。

I am considering using a character with a diacritical mark (e.g., ō) in a namespace for a custom framework. This idea has come up as a way to distinguish a product, but I want to to be sure this isn't a bad idea, and if there is anything about it that will come back to bite me later. I have not seen other examples of namespaces that use special characters in my searching, nor any similar discussion on this topic, which gives me pause in continuing down this path.

I was initially considering naming the assembly with a diacritical mark as well, but the first showstopper I ran into was in trying to digitally sign the assembly. I could not get the special character to appear in the command prompt, so I got a No valid input error. Perhaps there is another workaround for this?

One gotcha I realize is that it makes typing out the namespace in Visual Studio more challenging. I'm not seeing this as a major issue, however, since the character will come near the end of the word I am using, the word will be rather unique, and with IntelliSense this shouldn't be too big of a problem.

Consider the following example, contained in assembly Macron.dll:

namespace Macrōn.Library
{
    public class MyLibrary
    {
        public string MyProperty { get; set; }
    }
}

There appears to be no issues with generating and using this Macron.dll, and there are no issues distinguishing this example Macrōn.Library namespace. The file, folder, project & solution names Macrōn do not seem to cause any issues, and everything seems to jibe with source control without any issues.

Any other considerations or things I am missing when using a diacritical mark in an assembly and namespace? Any thoughts on getting around my issue signing the assembly? Is this approach bound to fail? Is it really just not worth implementing, as it may be confusing or otherwise difficult/obscure to use?

This will turn into a lot of work to undo later, so I want to know if I'm shooting myself in the foot before I get too deep into this.

Thanks.

解决方案

I want to to be sure this isn't a bad idea, and if there is anything about it that will come back to bite me later.

It is valid. Many obfuscators change namespaces / types to have unicode characters, some of them even non-printable, to make reverse engineering more difficult.

That being said, if this is a public framework that others will consume, I'd discourage it. That would force anyone using the namespace to save their source file as Unicode / UTF8, and if they don't, the ō character will likely be replaced with a ?. Then it'd no longer compile.

Alexei made a very good comment as well. I have no idea how to type the ō character other than copy and paste it. That would certainly slow me down.

这篇关于在命名空间中的特殊字符的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！