3

カスタムフレームワークの名前空間で発音区別符号付きの文字（例：ō）を使用することを検討しています。このアイデアは製品を区別する方法として思いついたものですが、これが悪いアイデアではないことを確認したいと思います。それについて何かあれば、後で私に噛み付くでしょう。検索で特殊文字を使用する名前空間の他の例も、このトピックに関する同様の議論も見たことがないため、このパスを続行するのを一時停止します。

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

私が気付いた落とし穴の1つは、VisualStudioで名前空間を入力するのが難しくなることです。これは大きな問題ではありませんが、使用している単語の終わり近くに文字が来るので、単語はかなりユニークになります。IntelliSenseを使用すれば、これはそれほど大きな問題にはなりません。

アセンブリMacron.dllに含まれている次の例について考えてみます。

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

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

アセンブリと名前空間で発音区別符号を使用するときに欠落しているその他の考慮事項や事項はありますか？議会に署名する私の問題を回避することについて何か考えはありますか？このアプローチは失敗するに違いありませんか？混乱するか、使用するのが難しい/わかりにくい可能性があるため、実際に実装する価値はありませんか？

これは後で元に戻すのに大変な作業になるので、これに深く入り込む前に、自分が足を撃っているのかどうかを知りたいと思います。

ありがとう。

4

2 に答える 2

7

これが悪い考えではないことを確認したいと思います。それについて何かあれば、後で私を噛むために戻ってきます。

有効です。多くの難読化ツールは、名前空間/タイプをユニコード文字に変更します。その中には、印刷できないものもあり、リバースエンジニアリングをより困難にします。

そうは言っても、これが他の人が消費するパブリックフレームワークである場合、私はそれを思いとどまらせます。これにより、名前空間を使用するすべてのユーザーがソースファイルをUnicode / UTF8として保存するように強制され、保存されない場合は、ō文字が。に置き換えられる可能性があり?ます。その後、コンパイルされなくなります。

アレクセイも非常に良いコメントをしました。コピーして貼り付ける以外に、ōの文字を入力する方法がわかりません。それは確かに私を遅くするでしょう。

于 2012-05-10T17:54:53.710 に答える
2

vcsjonesの回答に追加したいのですが、誰もがVisual Studioを使用しているわけではないので、誰にとってもこれを簡単にするためにインテリセンスに依存するべきではありません。

私が気付いた落とし穴の1つは、VisualStudioで名前空間を入力するのが難しくなることです。これは大きな問題ではありませんが、使用している単語の終わりに文字が来るので、単語はかなりユニークになります。IntelliSenseを使用すれば、これはそれほど大きな問題にはなりません。

これを回避しなければならない場合、他の誰かのライブラリを使用するのは非常にイライラします。

于 2012-05-10T17:58:52.287 に答える