名前空間内の特殊文字

Question

カスタムフレームワークの名前空間に発音記号（たとえばō）を含む文字を使用することを検討しています。このアイデアは、製品を区別する方法として浮かび上がってきましたが、これは悪い考えではないと確信しています。私は検索で特殊文字を使用する名前空間の他の例やこのトピックに関する同様の議論を見ていないので、この道を続けるのをやめてしまいます。

私は最初に分音記号でもアセンブリの名前を付けることを検討していましたが、私が最初に直面したのは、アセンブリにデジタル署名することでした。コマンドプロンプトに特殊文字が表示されないため、有効でない入力エラーが発生しました。おそらくこれには別の回避策がありますか？

私が気づいたのは、Visual Studioの名前空間をより難しく入力することです。しかし、私が使用している言葉の終わり近くに文字が来るので、これは重要な問題ではありません。単語はかなり独特のものになり、IntelliSenseではこれほど大きな問題ではありません。

アセンブリMacron.dllに含まれる、次の例を考えてみましょう：

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

生成し、このMacron.dllを使用しても問題はないように見えるが、この例にMacrōn.Library名前空間を区別何ら問題はありません。ファイル、フォルダ、プロジェクト&のソリューション名Macrōnは問題を引き起こすようではないようで、すべての問題がなくてもすべてがソース管理で気になるようです。

アセンブリーと名前空間で発音区別記号を使用すると、他の考慮事項や欠点がありますか？アセンブリに署名して私の問題を回避する上の任意の考えですか？このアプローチは失敗に結びついていますか？紛らわしいか、そうでなければ使用が難しい/あいまいなので、実際に実装する価値はありませんか？

これは後で元に戻す作業に変わります。そのため、私は自分自身を足で撃っているかどうかを知りたいのです。

ありがとうございました。

Answer 1

私はこれが悪い考えではないことを確かめたいと思います。それについては後で私をかむために戻ってくるものがあればそれがあります。

有効です。多くの難読化者は、リバースエンジニアリングをより困難にするために、ネームスペース/タイプを変更してユニコード文字（一部は印刷不可能な文字）を持つようにします。

これは、他人が消費する公開フレームワークであれば、私はそれを止めたいと言います。これにより、ネームスペースを使用する人は、ソースファイルをUnicode/UTF8として保存し、そうでなければ、ō文字は?に置き換えられます。それはもはやコンパイルされませんでした。

アレクセイも非常に良いコメントを出しました。私はコピーして貼り付ける以外に文字をどのように入力するのか分かりません。それは確かに私を遅らせるだろう。

Answer 2

私はvcsjonesの回答に追加したい、誰もがVisual Studioを使用しているわけではないので、誰にでも簡単にするためにintellisenseに頼るべきではない。

私が気づいたのは、 Visual Studioでより挑戦的な名前空間をタイプすることです。私は大きな問題としてこれを見ていませんが、 しかし、文字が単語の末尾に来るので、私は を使用しています。単語はかなり独特のものになり、IntelliSenseでこの は大きすぎるはずがありません問題

私はこれを回避しなければならないと、他の人のライブラリを使用すると非常に迷惑になります。