NetFxは、NuGetを通じて利用できる素晴らしいヘルパーセットです。しかし、私は一つのことを得ません：なぜヘルパーのクラスはすべて内部クラスですか？私はいくつかのプロジェクトからいくつかのヘルパーが必要な場合、私はそれをどのように扱うべきですか？ 私が現在行っていることは、NetFxクラスを1つのプロジェクトに配置し、必要なクラスを公開し、他のプロジェクトからこのアセンブリを参照することです。しかしこのアプローチでは、NetFxを更新するのが難しくなります。クラスを何度も公開する必要があります。NetFxヘルパーはなぜ内部的なのですか？
短い答え：明示的にdesigned to be that wayでした。私。ヘルパーは、それらを必要とする部分の内部に存在し、 "Common.dllまたはHelpers.dll"にダンプされてはなりません。おそらくこの決定に関するより多くの背景を持つ長い答えは（元の）作者によってのみ提供され得る。
元の質問については、おそらくそのヘルパーをいくつかのプロジェクトに含めることになります。
実際に別のアセンブリに保存してコードを変更したくない場合（内部をパブリックに変更する場合）、そのアセンブリのInternalsVisibleTo属性を使用して、必要な他のプロジェクト/アセンブリそれらを使用する。これは良い解決策であるとは言えません。NetFxの初期設計に対して明示的に機能しますが、更新する際には手作業から逃れることはできません。
私はいずれか（「共通」DLLまたは厳密にローカル関数）のいずれのフィールドフィールドも決定しません。どちらも明白な賛否両論があります。しかし、あなたは話のその部分について尋ねなかった、つまりあなたがすでに決定を下したと思われる;-)
時々私は別のプロジェクトに同じヘルパーを追加できません。 project1がいくつかのnetfxクラスを返すとどうなりますか？この場合、私はproject1とproject2（project1を使用）のnetfxに対して同じプロジェクトを使用する必要があります – SiberianGuy
内部のものを返すことはできません。したがって、何かを公開する必要がある場合は、その部分クラスを定義して公開することができます。 – kzu
コードを変更することが期待される*です。彼らはスニペットです。アセンブリではなく、ソースコードを取得します。 –
何か問題があれば、コードをデバッグして修正することができます。しかし、私はちょっとした使い方のためにコードを変更する予定ですか？ – SiberianGuy
更新が難しくありません。 NuGetはあなたの変更したVisibility.csを決して上書きしません:) – kzu