タグ付けされた質問 「dll」

作成するすべてのアプリケーションで使用するヘルパープロジェクトがあります。これには、いくつかの拡張メソッドと一連の汎用ヘルパークラス、コントロールなどが含まれています。ヘルパープロジェクトは随時更新/拡張します。これらは通常、小規模で無関係なプロジェクトであり、私はそれらすべてに取り組んでいる唯一の人です。 私はそれを使用するために2つのアプローチを試しました 使用する各プロジェクトに.csファイルを直接追加（リンクとして追加） .dllとしてコンパイルし、参照として追加します これらのアプローチにはいくつかの利点と欠点があります。 最初の1つ： ヘルパークラスはexeファイルにコンパイルされるため、より簡単です。したがって、正常に機能する単一の.exeファイルを非常に簡単に提供できることがよくあります。リンクとして追加するので、ヘルパーを使用するプロジェクトをビルドするたびに、ヘルパーファイルが最新バージョンになることを確信できます。 .NET 4.0で正常に動作する拡張メソッドを.NET 4.5を必要とする拡張メソッドとは別に参照できるように、ファイルを分離できるため、さらにシンプルになります。つまり、アプリ全体が.NET 4.0で実行できることを意味します。 ブレークポイントなどのすべての利点を使用して、コードを介してデバッグすることができます... 「ベストプラクティス」ではないようです 2番目： 正しいアプローチのようですが、次のとおりです。 別の.dllファイルを提供する必要があります。何らかの理由で、ユーザーにとってははるかに困難です（.dllなしでプログラムを共有する傾向があり、その後、起動時にクラッシュします）。 単一の.dllにコンパイルされるため、最高バージョンの.NETが必要になります。多くのユーザーは.NET 4.5を持たず、ヘルパークラスの一部の要素のみがこれを必要とします。理由もなくシステムを更新する また、プログラムを更新するたびに、.dllファイルも配信することを確認する必要があります-最後のバージョン以降に変更されたかどうかはわかりませんが、同じバージョンにすることもできます）。追加の作業であるアセンブリバージョンを追跡せずに、それを判断する簡単な方法はわかりません。今のところ、プログラムを更新するときは、更新されたexeのみを配信します。 では、ここで.dllファイルを使用することの実際の利点は何ですか？すべてのアプリケーションとヘルパーファイルのコードを編集するのは私だけであることに注意してください。 また、明確にするために-通常、アプリはごくわずかですが、ヘルパークラスに含まれるコードはそれらすべてに完全に汎用的です（一部の単純な文字列比較、パス、またはXML操作など） 実際、誰かが私に今、3番目の選択肢があることを認識させました。私はseparteプロジェクトにヘルパーコードを持っているので、このプロジェクトを個々のアプリケーションのソリューションに追加できます-これは、単一のプロジェクトを追加する以外は、単一ファイルの「リンクとして追加」のように機能します... Doc Brownが気づいたように、これは基本的に.dllをプロジェクトに追加する必要があることを意味します... dllファイルを使用しないことを支持するもう1つのことは、ヘルパークラスを積極的にデバッグする機能です...

38 c#  dll 

ISO / ANSIがC ++をバイナリレベルで標準化していないのはなぜですか？C ++には多くの移植性の問題がありますが、これはバイナリレベルでの標準化の欠如によるものです。 Don Boxが書いています（彼の本Essential COMの章COM As A Better C ++から引用） C ++と移植性 C ++クラスをDLLとして配布することを決定すると、C ++ の基本的な弱点の 1つ、つまりバイナリレベルでの標準化の欠如に直面します。ISO / ANSI C ++ドラフトワーキングペーパーは、どのプログラムをコンパイルし、それらを実行することのセマンティック効果をコード化しようとしますが、C ++のバイナリランタイムモデルの標準化は試みません。この問題が初めて明らかになるのは、クライアントがFastString DLLのビルドに使用した環境以外の C ++開発環境からFastString DLLのインポートライブラリにリンクしようとしたときです。 このようなバイナリ標準化の欠如により多くの利点または損失がありますか？

14 c++  dll  ansi  iso 

C ++ライブラリの優れたAPIデザインについて学び、共有オブジェクト/ dllなどを調べるための優れたリソースを探しています。ソースレベルでの優れたAPI、優れたクラス、テンプレートなどの記述に関する多くのリソースがありますが、共有ライブラリと実行可能ファイルに物事をまとめる。John LakosのLarge-Scale C ++ Software Designのような本は興味深いものですが、非常に時代遅れです。 私が探しているのは、テンプレートの取り扱いに関するアドバイスです。APIのテンプレートでは、実行可能ファイル（または他のライブラリ）にライブラリコードが含まれることが多いため、そこでバグを修正すると、新しいライブラリを単純に展開することはできませんが、そのコードのすべてのクライアントを再コンパイルして再配布する必要があります。（そして、はい、少なくともライブラリ内の最も一般的なバージョンをインスタンス化するなどのいくつかのソリューションを知っています。） また、C ++ライブラリでの作業中にバイナリ互換性を維持するために注意すべき他の注意事項や事柄も探しています。 そのようなことに関する良いウェブサイトや本はありますか？

12 c++  libraries  api-design  dll 

特定のケースがありますが、一般的な状況について疑問に思いました。 2つのDLLをVisual C＃プロジェクトへの参照として追加すると、ソリューションが構築されないように互いに衝突する可能性がありますか？これが事実である場合、これを軽減する可能な方法は何ですか。

9 c#  reference  dll  visual-studio-2008  builds