1

序文として、このエラーを検索して一致したすべての StackOverflow の質問 (25 程度) を調べましたが、どれも私が抱えている問題に対処していないようです。

System.Windows.Form から継承する PermissionsDialog を構築しています。呼び出すメソッド内でdialogPermissions.ShowDialog()、データベースからいくつかの Role オブジェクトを取得し、それらをいくつかの ListBox にロードしています。これは問題なく機能していましたが、次の疑似コード プロセスを使用して、リストボックスに追加している Role オブジェクトのプロパティの 1 つをオーバーライドする必要があります。

  • ロールのリストを反復処理する
  • を使用して、プロファイルのリストから一致するアイテムを検索しますList<T>.Find()
  • プロフィールで物件を探す
  • 新しいロールを構築し、必要に応じて Name プロパティを設定します
  • PermissionsDialog のロールのリストにロールを追加します

これらはすべてスムーズに進みますがdialogPermissions.ShowDialog()、基礎となるフレームワーク コードを呼び出すと、AccessViolationException がスローされます。

関連するコードであると私が信じているものは次のとおりです。

List<UserProfile> userProfiles = new List<UserProfile>();
List<Role> allRoles = new List<Role>();
dialogData.AllRoles = new List<Role>();

using (var objectContext = this.SiteContext.CreateObjectContext())
{
    userProfiles = rs.UserProfiles.FindAll().ToList();
    allRoles = rs.Roles.FindAll();
}

foreach (Role role in allRoles.Where(role => role.BuiltInId == (int)BuiltInRoleId.UserProfileRole)) {
    var userProfile = userProfiles.Find(up => role.Id == up.Id);

    var roleToAdd = new Role {
        BuiltInId = role.BuiltInId,
        Description = role.Description,
        DirectoryEntry = role.DirectoryEntry,
        Id = role.Id,
        IsBuiltInRole = role.IsBuiltInRole,
        Name = null != profile ? profile.DisplayName:role.Name
    };
    dialogData.AllRoles.Add(roleToAdd);
}

私の疑いでは、これはどういうわけか遅延実行の問題ですが、呼び出すToList()前に dialogData.AllRoles を呼び出して実行をトリガーShowDialog()しても問題は解決しません。profile.DisplayName を定数文字列に置き換えると、エラーは発生しません。

ここで何が起こっているのか、または何が起こっているのかを知る方法、または問題を回避できるように別の方法で問題にアプローチする方法の手がかりはありますか? すべての提案を歓迎します;-)

結論

実際の問題は次のとおりです。

Role の Name プロパティを null に設定することは問題ありませんが、ダイアログが Role から ListBoxItem を作成しようとし、ListBoxItem の Content プロパティ (オブジェクト) に Role.Name プロパティを使用する場合、それはできません。 null として設定され、ダイアログを構築しているフレームワーク コードでスローされます。そこに値があることを確認すると、問題が解決します。

スローする奇妙な例外のように思えますが、それがあります....

4

2 に答える 2

2

profile != null をテストしますが、profile.DisplayName != null はテストしないので、サンプルを見て最初に思い浮かぶのはこれです。

標準の例外ファインダーは、Debug\Exceptions に移動し、例外がスローされたときにすべての状態を確認できるように、スロー時にブレークするためのボックスをチェックすることです。

于 2012-09-20T16:33:31.977 に答える
1

このコードを 1 週間見つめても、AccessViolationException の理由を見つけることはできません。マネージ コードは、このようなプロセッサ エラーで停止することはありません。

実際の例外から得られる情報をできるだけ多く掘り下げる必要があります。そのためには、まずアンマネージ コードのデバッグを有効にして、ネイティブ コードのスタック フレームを確認できるようにする必要があります。プロジェクト + プロパティの [デバッグ] タブで、[アンマネージ コードのデバッグを有効にする] オプションにチェックを入れます。

次に、ネイティブ Windows DLL の .pdb ファイルがあることを確認します。Active Directory 用のものを含めて、この場合はやや疑わしいです。ツール + オプション、デバッグ、シンボルを開き、Microsoft シンボル サーバーを有効にします。古いバージョンの Visual Studio を使用していて、単純なチェックボックスのクリックにならない場合は、F1 キーを押します。

クラッシュを再現します。コール スタックから、どのネイティブ コードが疑われるかが分かります。うまくいかない場合は、質問に投稿してください。

于 2012-09-20T16:53:12.923 に答える