لم يتم العثور على مرجع التجميع ، على الرغم من أن التجميع في نفس الدليل

Question

نقوم حاليًا بتطوير وظيفة إضافية لبعض البرامج. قررنا التطوير في .NET ، على الرغم من أن التطبيق مكتوب في بعض اللغة الأم. نظرًا لوجود بعض المشكلات التي تقوم مباشرة بإنشاء الواجهة الخارجية في .NET ، قررنا إنشاء جسر DLL في C ++/CLI ، والذي يقوم ببعض التهيئة الأساسية ثم يقوم بتحميل تجميعنا المدار وإنشاء عنصر تحكم مستخدم من ذلك.

في ملف الوظيفة الإضافية .INI ، يتم الرجوع إلى C ++/CLI DLL بالاسم ، لذلك سيتم تحميل التطبيق من هناك. ومع ذلك ، يتم الرجوع إلى .NET DLL من C ++/CLI DLL (كمرجع مُدار) ، وبالتالي تتوفر الأنواع المصدرة. في هذا الإعداد ، Howerver ، يعطل التطبيق تحميل .NET DLL.

لقد وجدنا بسرعة أنه يمكننا فقط الاشتراك في AppDomain.AssemblyResolve حدث لتحميل مجموعة .NET من نفس الدليل حيث يكون C ++/CLI DLL ، لذلك يتم حل المشكلة نفسها.

السؤال الفعلي هو: لماذا لا يجد المحمل .NET DLL ، على الرغم من أنه في نفس الدليل مثل التجميع الذي يشير إليه؟ كنت أتوقع دائمًا أن تنظر مجموعات التحميل أولاً إلى نفس الدليل ، بدلاً من مجرد دليل العمل الحالي. لماذا تجد تجميع قابلة للتنفيذ إذا غيرت دليل العمل الخاص بها بعد ذلك؟ أم أن الأشياء مختلفة إذا تم استدعاء CLR عن طريق تحميل مجموعة C ++/CLI (بدلاً من تطبيق مُدار خالص)؟

Answer 1

أود أن أوصيك بالاستخدام fuslogvw.exe لتحليل المشكلات من هذا النوع:

fuslogvw.exe وتشخيص مشكلات ربط مجموعة .NET

وبالطبع ، فإن أداة الغرض العام لتحليل المشكلات مع الملفات غير موجودة:

مراقبة العملية

Answer 2

لا يمكن التنبؤ بمسار التحقيق للتجميعات عندما يبدأ EXE غير المدير العملية. لمجرد أنه تم تحميل C ++/CLI DLL ، ربما من خلال التحميل أو setdlldirectory ليس يؤثر بأي شكل من الأشكال على مسار التحقيق لـ CLR.

لكن هذا مجرد تخمين. ليست هناك حاجة للتخمين عندما تنظر إلى الإخراج الذي تنتجه fuslogvw.exe. إنه يوضح لك بالضبط ما يجري التحقيق وما هي السياسات التي يتم تطبيقها. يمكنك إصلاح المشكلة مع ملف app.exe.config (عنصر التحقيق) أو بالفعل عن طريق AssemblyResolve.