問題タブ [ndepend]

私はNDependを試していて、それについてのいくつかのブログ投稿を読んでいて、ポッドキャストも聞いていました。NDepend は非常に便利なツールだと思いますが、どこで使用するかはまだわかりません。

どうやって使うんですか？使っていますか、なぜですか？なぜだめですか？

現実世界の現実的な例について聞きたいです。

できるだけ多くのアプリケーションの依存関係の概要/マップを作成したいと思います。.NETアプリケーションの依存関係の分析は、NDepend（大好きです！）などのツールを使用するとかなり簡単です。しかし、データベースやWebサービスなどの外部依存関係に関しては、より優れたもの、できればさまざまなツールで自動化できるものが必要です。

たとえば、データベースのリストを作成する1つのツール、.NETアプリケーションのリストを作成するための別のツール、Webサービスのリストを取得する3番目のツール、そして最後にコンポーネント間の依存関係についてアプリケーションをマイニングする方法を何らかの方法で知っているツールがあるとします。他のツールで見つかりました。

これのすべてまたはほとんどを自動化できるので、依存関係のリストを自分で維持する必要がなくなります。依存関係のリストはエラーが発生しやすく、終了するまでに古くなっている可能性があります。ですから、自分で構築するのではなく、すべてを実行できるツール、または少なくともコンポーネントと依存関係を保持、分析、視覚化できるツールが欲しいと思っています。私がしなければならないことが少なければ少ないほど良い...

私は、最初に.NET 1.1用に開発されたブラウンフィールドプロジェクトに取り組んでおり、その後、.NET 3.5を少し加えて.NET 2.0にレトロフィットしました。

最適化とモダナイゼーションの変曲点を見つけるために、どのような指標を使用すればよいか興味があります。

「従来の」.NET コードのクリーンアップとリファクタリングに役立つ、優れた CQL クエリはありますか?

標準の「メソッドが大きすぎます」クエリの修正バージョンを使用して、NDependに長いメソッドを識別させようとしています。

開発者がほとんど制御できない長いメソッドを報告したくないので、DebuggerNonUserCode属性とを使用して生成されたコードを除外しますInitializeComponent()。

残念ながら、生成されたタイプのメソッドも報告されるため、まだいくつかの誤検知が発生します。問題は、型自体にはDebuggerNonUserCode属性がありますが、メソッドにはないため、生成されているにもかかわらず、出力に含まれていることです。

タイプとメソッド間の結合のようなものを探しています。属性を持たないすべてのタイプを指定して、DebuggerNonUserCodeそれらに対してクエリを実行しますが、CQLでこれを表現する方法がわかりません。

一部のアセンブリでは、フルネームで簡単にフィルタリングできますが、残念ながら、一部のアセンブリでは、開発者が作成したタイプと生成されたタイプが混在しています。残念ながら、IsGeneratedByCompilerこの場合も使用できません。

私の質問

.NET コードを分析して競合状態を検出するツールはありますか?

プライベート静的フィールドを取得または作成するパブリック静的プロパティを持つコードが少しあります。また、このフィールドを null に設定する public static メソッドもあります (...はい、わかっています!..)。

これらの方法のいずれにもロックがないため、将来、事態がひどく悪化することは間違いありません。これらのメソッドのいずれかを呼び出すものを再帰的に調べて、別のスレッドで何かが生成されたかどうかを確認するツールが必要です。

ツールまたは nDepend SQL スクリプト (可能であれば) を探しています。

Webアプリケーションが直接使用している低レベルのフレームワークタイプを判別するには、関連するすべてのアセンブリを定義する必要があります。

アセンブリのリストをワイルドカード化する構文が見つかりません。これをショートカットする方法はありませんか？フレームワークレベルのアセンブリがたくさんあります。

つまり、Company.System.Framework。*

NDependのCQLクエリを使用してソースコードでマジックナンバーを見つける方法を知っている人はいますか？これはこの質問と同じ問題ですが、可能であれば正規表現を使用したくありません。

だから私は次のようなすべてのステートメントを見つけたい

だがしかし

特定の基本クラスから派生していない型が低レベルのフレームワークアセンブリを使用しているかどうかを確認するには、次のクエリを使用できます。

次に、さらにドリルダウンして、これらのクラスのどのメソッドが実際にそうしているのかを確認したいと思います。ただし、クエリターゲットをTYPESからMETHODSに変更すると、DeriveFromは適用されません。これらの基準をどのように維持できますか？

ベース フレームワーク アセンブリ内のどの型またはメソッドが、アプリケーション システム内の他のアセンブリによって使用されているかを特定しようとしています。それを行うためのストレートカットクエリが見つからないようです。

私がしなければならないことは、最初にフレームワークアセンブリを直接使用しているアセンブリを特定し、次にそれらを2番目のクエリで手動でリストすることです

これを照会するためのより良い/より高速な方法はありますか?

さらに、クエリ結果は、一致した型のみに注目されます。エクスポートされた依存関係グラフまたはマトリックスには、それらの詳細のみが表示されます。これらの型またはメソッドを表示し、それらを消費している他のアセンブリからの依存型/メソッドを表示するグラフをレンダリングする方法がわかりませんか?

アップデート

次のようなクエリは使用できません

IBM.Data.DB2 アセンブリー内で難読化された型を使用すると、結果が非​​常に奇妙な結果を返すためです。

私たちのコードは、これらの型と列挙型を直接使用しません。

解決済み: 作業構成については、この質問の下部を参照してください

.NET 4.0 C# プロジェクトの FinalBuilder プロジェクトで使用するために NCover をセットアップしようとしていますが、最終的なカバレッジ出力ファイルにカバレッジ データが含まれていません。

私は使っている：

• Nカバー 3.3.2
• NUnit 2.5.4
• FinalBuilder 6.3.0.2004

すべてのツールは、今日の最新の公式です。

最終的に、.NET 4.0 プロジェクトの NCover で単体テストを実行するように FB を誘導することができたのでTests run: 184, ...、正しい .

ただし、Coverage.xmlNCover からの最終的なファイル出力はほとんど空で、次のようになります。

FB ログの出力は次のとおりです。

NCover の FB ステップの構成:

• 何をカバーしますか？: NUnit テスト カバレッジ
• コマンド:C:\Program Files (x86)\NUnit 2.5.4\bin\net-2.0\nunit-console.exe
• コマンド引数:LVK.IoC.Tests.dll /noshadow /framework:4.0.30319 /process=single /nothread
  • /process注: オプションと/nothreadオプションを使用して、または使用せずに試しました
• 作業ディレクトリ:%FBPROJECTDIR%\LVK.IoC.Tests\bin\Debug
• プロファイリングするアセンブリのリスト:%FBPROJECTDIR%\LVK.IoC.Tests\bin\Debug\LVK.IoC.dll
  • 注：拡張子の有無にかかわらず、アセンブリの名前をリストしてみました。

FB ステップのドキュメントは役に立ちません。各プロパティの簡単な説明しか記載されておらず、例やトラブルシューティングのヒントが記載されていないためです。

カバレッジの結果を NDepend にプルしてビルド時の分析を実行したいので、そのファイルに必要な情報を含めたいと思います。

私も TestDriven を使用しています。ソリューション ファイルを右クリックして [NCover でテスト] を選択すると、NCover-explorer がカバレッジ データと共に開きます。上記と同じ構造の.xmlファイルに、そこにあるはずのすべてのデータが含まれているため、私が持っているツールは確かにそれを作成できます。

ここで私が間違って設定したことを誰かが知っていますか?

解決済み: 次の構成が最終的に機能しました。ビルドの開始結果ページにコード カバレッジの基本統計が生成され、すべての詳細レポートへのリンクが含まれます。

単体テスト プロジェクトには、テスト対象のプロジェクトと同じ名前を付け、.Tests サフィックスのみを付けて名前を付けているため、それらをコード カバレッジから除外しました。また、独自のアセンブリ (すべて LVK で始まるもの) のみを明確に含める必要がありました。そうしないと、TeamCity ランナーによっていくつかのアセンブリが読み込まれ、カバレッジ統計にわずかに影響を与えました。

まず、最新のツールをインストールしました（この編集の時点で）：

• Nカバー 3.4.8
• チームシティ 5.1.2
• NUnit 2.5.5

TeamCity のビルド画面の構成は次のとおりです。

• ターゲット: 再構築
• 構成: デバッグ
• プラットフォーム: 任意の CPU
• .NET カバレッジ ツール: NCover (3.x)
• .NET ランタイム: .NET Framework 4.0、バージョン: ネイティブ
• NCover 3 へのパス: %system.ncover.v3.x64.path% (これは Windows 2008 Server R2 64 ビットです)

• 追加の NCover 引数:

  /li>

• 追加の NCover レポート引数:

  /li>

• NUnit ランナー: NUnit 2.5.5

• .NET ランタイム プラットフォーム: 自動 (MSIL)、バージョン: 4.0
• 以下からテストを実行します: **\bin\Debug*Tests.dll