يقول TypeloadException "لا تنفيذ"، ولكن يتم تنفيذها

Question

لدي علة غريبة للغاية في آلة الاختبار لدينا. الخطأ هو:

System.TypeLoadException: Method 'SetShort' in type 'DummyItem' from assembly 'ActiveViewers (...)' does not have an implementation.

أنا فقط لا أستطيع أن أفهم لماذا. SetShort هناك في DummyItem فئة، وحتى تم إعادة ترجمة إصدار به يكتب إلى سجل الأحداث فقط للتأكد من أنها ليست مشكلة النشر / الإصدار. الشيء الغريب هو أن رمز الاتصال لا يسميه حتى SetShort طريقة.

Answer 1

ملاحظة - إذا لم تساعدك هذه الإجابة، فالرجاء أن تأخذ الوقت المناسب للتمرير من خلال الإجابات الأخرى التي أضافها الأشخاص منذ ذلك الحين.

اجابة قصيرة

يمكن أن يحدث هذا إذا قمت بإضافة طريقة إلى واجهة في مجموعة واحدة، ثم إلى فئة منفذة في مجموعة أخرى، لكنك تقوم بإعادة إنشاء الجمعية المنفذة دون الرجوع إلى الإصدار الجديد من تجميع الواجهة.

في هذه الحالة، ينفذ Dummyitem واجهة من مجموعة أخرى. تمت إضافة طريقة SetShort مؤخرا إلى كل من الواجهة والبلوميتيم - لكن الجمعية التي تحتوي على dummyitem أعيد بناؤها بإعادة بناء الإصدار السابق من تجميع الواجهة. لذلك هناك طريقة SetShort هناك فعليا، ولكن بدون الصلصة السحرية التي تربطها بالطريقة المكافئة في الواجهة.

اجابة طويلة

إذا كنت ترغب في محاولة إعادة إنتاج هذا، فجرب ما يلي:

1. إنشاء مشروع مكتبة فئة: InterFaceDef، أضف فئة واحدة فقط، وبناء:

   public interface IInterface
   {
       string GetString(string key);
       //short GetShort(string key);
   }
   

2. إنشاء مشروع مكتبة من الدرجة الثانية: التنفيذ (مع حل منفصل)، انسخ InterfaceDef.dll في دليل المشروع وإضافة كمرجع ملف، أضف فئة واحدة فقط، وبناء:

   public class ImplementingClass : IInterface
   {
       #region IInterface Members
       public string GetString(string key)
       {
           return "hello world";
       }
   
       //public short GetShort(string key)
       //{
       //    return 1;
       //}
       #endregion
   }
   

3. قم بإنشاء مشروع ثالث، وحدة التحكم: ClientCode، انسخ DLLs في دليل المشروع، إضافة مراجع الملفات، وإضافة التعليمات البرمجية التالية إلى الطريقة الرئيسية:

    IInterface test = new ImplementingClass();
    string s = test.GetString("dummykey");
    Console.WriteLine(s);
    Console.ReadKey();
   

4. قم بتشغيل التعليمات البرمجية مرة واحدة، تقول وحدة التحكم "Hello World"

5. uncomment رمز في مشاريع DLL و REBUILD - نسخ DLLS مرة أخرى في مشروع العميل، وإعادة بناء وحاول تشغيل مرة أخرى. يحدث TypeloAdException عند محاولة إنشاء Instantiate ApplaceClass.

Answer 2

بالإضافة إلى ما ذكرت إجابة Asker الخاصة به بالفعل، قد يكون من المفيد ملاحظة ما يلي. السبب يحدث هذا لأنه من الممكن أن يكون لفئة واحدة من خلال التوقيع نفسه كطريقة واجهة دون تنفيذ هذه الطريقة. يوضح التعليمات البرمجية التالية ما يلي:

public interface IFoo
{
    void DoFoo();
}

public class Foo : IFoo
{
    public void DoFoo() { Console.WriteLine("This is _not_ the interface method."); }
    void IFoo.DoFoo() { Console.WriteLine("This _is_ the interface method."); }
}

Foo foo = new Foo();
foo.DoFoo();               // This calls the non-interface method
IFoo foo2 = foo;
foo2.DoFoo();              // This calls the interface method

Answer 3

حصلت على هذا عندما لم يكن لدى طلبي مرجعا إلى مجموعة أخرى يحدد فئة أن الطريقة في رسالة الخطأ المستخدمة. أعطى تشغيل Peverify خطأ أكثر فائدة: "لا يمكن للنظام العثور على الملف المحدد".

Answer 4

جئت عبر نفس الرسالة وهنا ما وجدناه: نستخدم DLL جهة خارجية في مشروعنا. بعد إصدار جديد من هؤلاء، غيرنا أننا غيرنا مشروعنا للإشارة إلى مجموعة DLL الجديدة وتجميعها بنجاح.

تم إلقاء الاستثناء عندما حاولت التغيب عن أحد فصولهم المتداخل أثناء وقت التشغيل. تأكد من أن جميع المراجع الأخرى كانت محدثة، لكننا لا تزال لا حظ. كنا بحاجة لفترة من الوقت إلى بقعة (باستخدام مستعرض الكائنات) أن نوع المرتجع للطريقة في رسالة الخطأ كان نوع جديد تماما من تجميع جديد غير معروف.

أضفنا إشارة إلى التجمع واختفت الخطأ.

• كانت رسالة الخطأ مضللة للغاية، ولكن الإشارة إلى الاتجاه الصحيح (الطريقة الصحيحة، رسالة خاطئة).
• الاستثناء الذي ocurred على الرغم من أننا لم نستخدم الطريقة المعنية.
• مما يدفعني إلى السؤال: إذا تم إلقاء هذا الاستثناء في أي حال، فلماذا لا يلتقط الترجمة؟

Answer 5

تلقيت هذا الخطأ في السيناريو التالي.

• كل من التجميعات A و B المشار إليها SYSTEM.WEB.MVC الإصدار 3.0.0.0
• الجمعية التجميع المشار إليها B وكان لديه فصول تنفذ واجهات من التجميع ب مع الأساليب التي عادت فئات من system.web.mvc.
• التجميع ترقية إلى system.web.mvc الإصدار 4.0.0.0
• ركض التجميع C الرمز أدناه (fretpin.classes.contact واردة في التجميع أ):

var target = Assembly.GetAssembly(typeof(FertPin.Classes.Contact));

تم ترقية الإصلاح بالنسبة لي مرجع System.Web.MVC في التجميع ب إلى 4.0.0.0. يبدو واضحا الآن!

كل الشكر للناشر الاصلي!

Answer 6

المرة الأخرى التي يمكنك فيها الحصول على هذا الخطأ إذا كان لديك إصدار غير صحيح من التجميع الموقع. ليس من الأعراض الطبيعية لهذا السبب، ولكن هنا كان السيناريو حيث حصلت عليه

• يحتوي مشروع ASP.NET على التجمع A and Assembly B، B بشدة

• التجميع يستخدم Activator.CreateInstance لتحميل التجميع C (أي لا يوجد إشارة إلى C التي بنيت بشكل منفصل)

• تم بناء C الرجوع إلى إصدار أقدم من التجمع باء موجود حاليا

نأمل أن يساعد شخص ما - استغرق الأمر مني أعمار لمعرفة ذلك.

Answer 7

كان لدي هذا الخطأ أيضا، كان ناتج عن أي وحدة المعالجة المركزية EXE الرجوع إلى أي تجمعات وحدة المعالجة المركزية التي تتم الإشارة إليها بدورها إلى تجميع X86.

اشتكى الاستثناء من طريقة على فئة في MyApp.Implidations (أي وحدة المعالجة المركزية)، والتي مشتقة myapp.interfaces (أي وحدة المعالجة المركزية)، ولكن في Fuslogvw.exe وجدت محاولة "محاولات" مخفية لتحميل برنامج غير صحيح "استثناء من MyApp .commontypes (x86) الذي يستخدم من قبل كليهما.

Answer 8

استمر في العودة إلى هذا ... العديد من الإجابات هنا مهمة رائعة في شرح ما هي المشكلة ولكن ليس كيفية إصلاحه.

الحل لهذا هو حذف ملفات BIN يدويا في دليل المشاريع المنشورة. سوف تنظيف جميع المراجع وإجبار المشروع على استخدام أحدث ملفات DLL.

لا أقترح استخدام وظيفة DESURAND DELETET لأن هذا يميل إلى إخراج IIS.

Answer 9

لدي حل غير مرئي آخر لرسالة الخطأ هذه. قمت بترقية إطاري المستهدف من .NET 4.0 إلى 4.6، وكان مشروع اختبار الوحدة الخاص بي يعطيني "system.typeloadexception ... ليس لديه تطبيق" عندما حاولت بناء. كما قدم رسالة خطأ ثانية حول نفس الطريقة غير المنفذة من المفترض أنها مفيدة "فشلت مهمة" BuildshadowTask "بشكل غير متوقع". بدا أيا من النصيحة هنا للمساعدة، لذلك بحثت عن "BuildshadowTask"، ووجدت وظيفة على MSDN مما دفعني إلى استخدام محرر نصوص لحذف هذه الأسطر من ملف CSProj اختبار وحدة اختبار الوحدة.

<ItemGroup>
  <Shadow Include="Test References\MyProject.accessor" />
</ItemGroup>

بعد ذلك، ذهب كلا من الأخطاء بعيدا ومشروع بنيت.

Answer 10

واجهت هذا الخطأ في سياق حيث كنت أستخدم Autofac والكثير من تحميل التجميع الديناميكي.

أثناء إجراء عملية دقة Autofac، سيفشل وقت التشغيل في تحميل إحدى التجمعات. اشتكت رسالة الخطأ ذلك Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. وبعد حدثت الأعراض عند التشغيل على Windows Server 2012 R2 VM، ولكن ليس تحدث على نظام التشغيل Windows 10 أو Windows Server 2016 VMS.

ImplementationAssembly المشار إليها System.Collections.Immutable 1.1.37، وتواصل تطبيقات IMyInterface<T1,T2> الواجهة، التي تم تعريفها في منفصلة DefinitionAssembly. DefinitionAssembly المشار إليها System.Collections.Immutable 1.1.36.

طرق من IMyInterface<T1,T2> التي "لم تنفذ" لديها معلمات من النوع IImmutableDictionary<TKey, TRow>, ، والتي يتم تعريفها في System.Collections.Immutable.

النسخة الفعلية من System.Collections.Immutable وجدت في دليل البرنامج كان الإصدار 1.1.37. على Windows Server 2012 R2 VM، تحتوي GAC على نسخة من System.Collections.Immutable 1.1.36. على Windows 10 و Windows Server 2016، تحتوي GAC على نسخة من System.Collections.Immutable 1.1.37. حدث خطأ التحميل فقط عند احتوى GAC على الإصدار الأقدم من DLL.

لذلك، كان السبب الجذري لفشل تحميل التجميع هو الإشارات غير المعطاة إلى System.Collections.Immutable. وبعد كان تعريف الواجهة والتنفيذ توقيعات طريقة متطابقة، ولكنها تعتمد فعلا على إصدارات مختلفة من System.Collections.Immutable, ، مما يعني أن وقت التشغيل لم يفكر في فئة التنفيذ لتتناسب مع تعريف الواجهة.

إضافة إعادة توجيه الربط التالي إلى ملف تكوين التطبيق الخاص بي ثابت المشكلة:

<dependentAssembly>
        <assemblyIdentity name="System.Collections.Immutable" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-1.1.37.0" newVersion="1.1.37.0" />
</dependentAssembly>

Answer 11

حصلت على هذا مع تبعية مشاريع "الماس":

• مشروع يستخدم مشروع B والمشروع د
• يستخدم Project B المشروع د

أنا recompiled Project A ولكن ليس مشروع B، الذي سمح للمشروع ب "بحقن" النسخة القديمة من المشروع D DLL

Answer 12

واجهت هذا عندما قمت بإعادة تسميته مشروع (واسم التجميع)، والذي كان يعتمد عليه مشروع ASP.NET. أنواع في مشروع الويب نفذت واجهات في الجمعية التابعة. على الرغم من تنفيذ الحل النظيف من قائمة الإنشاء، ظل الجمعية مع الاسم السابق في bin المجلد، وعند تنفيذ مشروع الويب الخاص بي

var types = AppDomain.CurrentDomain.
   GetAssemblies().
   ToList().
   SelectMany( s => s.GetTypes() /* exception thrown in this call */ )
;

تم إلقاء الاستثناء أعلاه، ويشكو أن أساليب الواجهة في أنواع الويب المنفذة لم تنفذ بالفعل. حذف التجميع يدويا في مشروع الويب bin مجلد حل المشكلة.

Answer 13

حصلت أيضا على هذا الخطأ عندما قمت بتمكين تغطية التعليمات البرمجية مسبقا أثناء اختبار الوحدة لأحد التجمعات. لسبب ما السبب Visual Studio "مخزنة" الإصدار القديم من هذا DLL معين على الرغم من أنني قمت بتحديثه لتطبيق إصدار جديد من الواجهة. تتخلص تغطية التعليمات البرمجية تعطيل الخطأ.

Answer 14

تفسير آخر لهذا النوع من المشكلات التي تنطوي على C ++ المدارة.

إذا حاولت تشغيل واجهة محددة في مجموعة تم إنشاؤها باستخدام C ++ المدارة التي تحتوي على توقيع خاص، فستحصل على الاستثناء عند إنشاء كعب كعب.

هذا صحيح بالنسبة لحوض سمك القرن، وربما أي إطار سخرية يستخدم System.Reflection.Emit.

public interface class IFoo {
  void F(long bar);
};

public ref class Foo : public IFoo {
public:
  virtual void F(long bar) { ... }
};

يحصل تعريف الواجهة على التوقيع التالي:

void F(System.Int32 modopt(IsLong) bar)

لاحظ أن نوع C ++ long خرائط إلى System.Int32 (أو ببساطة int في C #). إنه غامض إلى حد ما modopt هذا يسبب المشكلة كما ذكرت Ayende Rahien على القائمة البريدية لحضور القرن .

Answer 15

يمكن أيضا أن يكون سبب هذا الخطأ إذا تم تحميل التجميع باستخدام الجمعية. تحميل (سلسلة) ويشير إلى مجموعة تم تحميلها بالفعل باستخدام التجميع. تحميل (البايت []).

على سبيل المثال، قمت بتضمين التجميعات المرجعية في التطبيق الرئيسي كموارد ولكن تطبيقك يقوم بتحميل المكونات الإضافية من مجلد معين.

بدلا من استخدام LoadFrom يجب عليك استخدام الحمل. الرمز التالي سيفعل الوظيفة:

private static Assembly LoadAssemblyFromFile( String filePath )
{
    using( Stream stream = File.OpenRead( filePath ) )
    {
        if( !ReferenceEquals( stream, null ) )
        {
            Byte[] assemblyData = new Byte[stream.Length];
            stream.Read( assemblyData, 0, assemblyData.Length );
            return Assembly.Load( assemblyData );
        }
    }
    return null;
}

Answer 16

لقد قمت فقط بترقية حل من MVC3 إلى MVC5، وبدأت في تلقي نفس الاستثناء من مشروع اختبار الوحدة الخاص بي.

فحص كل المراجع التي تبحث عن الملفات القديمة، اكتشفت الأحداث التي احتاجت إلى القيام ببعض bindingredirects for MVC، في مشروع اختبار الوحدة الخاص بي.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-5.1.0.0" newVersion="5.1.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Answer 17

في حالتي، ساعدت في إعادة تعيين مربع أدوات WinForms.

حصلت على الاستثناء عند فتح Form في المصمم؛ ومع ذلك، كان تجميع وإدارة الرمز ممكنا وكود تصرف كما هو متوقع. حدث الاستثناء في محلي UserControl تنفيذ واجهة من واحدة من مكتباتي المشار إليها. ظهر الخطأ بعد تحديث هذه المكتبة.

هذه UserControl تم إدراجها في Toolbox WinForms. ربما أبقى Visual Studio مرجعا على نسخة قديمة من المكتبة أو تم التخزين المؤقت نسخة قديمة في مكان ما.

إليكم كيف تعافت من هذا الموقف:

1. انقر بزر الماوس الأيمن فوق Toolbox WinForms وانقر فوق Reset Toolbox في قائمة السياق. (هذا يزيل عناصر مخصصة من مربع الأدوات).
   في حالتي، تم استعادة عناصر Toolbox إلى حالتها الافتراضية؛ ومع ذلك، فقد كان سهم المؤشر مفقودا في صندوق الأدوات.
2. أغلق Visual Studio.
   في حالتي، تم إنهاء Visual Studio باستثناء انتهاك وإحباطه.
3. إعادة تشغيل Visual Studio.
   الآن كل شيء يعمل بسلاسة.

Answer 18

FWIW، حصلت على هذا عندما كان هناك ملف تكوين يعيد توجيه إلى إصدار غير موجود من التجميع المشار إليه. سجلات الانصهار للفوز!

Answer 19

حصلت على هذا الخطأ لأنني كان لدي فئة في التجمع "C" الذي كان في الإصدار 4.5 من الإطار، وتنفيذ واجهة في التجميع "A" الذي كان في الإصدار 4.5.1 من الإطار ويقدم كطبقة أساسية للتجميع "B" الذي كان أيضا في الإصدار 4.5.1 من الإطار. ألقى النظام الاستثناء أثناء محاولة تحميل التجمع "B". بالإضافة إلى ذلك، قمت بتثبيت بعض حزم Nuget التي استهدفت .NET 4.5.1 على جميع التجمعات الثلاث. لسبب ما، على الرغم من أن مراجع Nuget لم تكن تظهر في التجمع "B"، فقد كان بناء بنجاح.

اتضح أن القضية الحقيقية هي أن التجمعات كانت تشير إلى إصدارات مختلفة من حزمة Nuget التي تحتوي على الواجهة وتغيير واجهة الواجهة بين الإصدارات.

Answer 20

في حالتي كنت قد أشارت سابقا mylib مشروع في مجلد الأخوة خارج الريبو - دعونا نسمي ذلك v1.0.

|-- myrepo
|    |-- consoleApp
|    |-- submodules
|         |-- mylib (submoduled v2.0)
|-- mylib (stale v1.0)

في وقت لاحق لقد فعلت ذلك بشكل صحيح واستخدمها عبر منشط GIT - دعنا ندعو ذلك v2.0وبعد مشروع واحد consoleApp ومع ذلك لم يتم تحديثه بشكل صحيح. كان لا يزال يشير إلى القديم v1.0 مشروع خارج مشروعي جيت.

مربك, ، على الرغم من أن *.csproj كان خطأ واضح ويشير إلى v1.0, ، أظهر برنامج Visual Studio IDE المسار كما v2.0 المشروع! F12 لتفقد الواجهة والطبقة ذهبت إلى v2.0 النسخة أيضا.

كانت الجمعية الموضوعة في مجلد بن من المترجم v1.0 نسخة، وبالتالي الصداع.

هذه الحقيقة أن IDE كانت مستلقية بالنسبة لي جعلت من الصعب إدراك الخطأ.

المحلول: مراجع المشروع المحذوف من ConsoleApp وقراءة لهم.

نصيحة عامة: إعادة ترجمة جميع التجمعات من نقطة الصفر (حيثما كان ذلك ممكنا، لا يمكن لحزم Nuget بالطبع) وتحقق من طوابع DateTime في bin\debug مجلد. أي جمعيات مؤرخة قديمة هي مشكلتك.

Answer 21

واجهت نفس القضية تقريبا. كنت أخدش رأسي ما الذي يسبب هذا الخطأ. لقد تم فحصها، وتم تنفيذ جميع الطرق.

على googling حصلت على هذا الرابط من بين آخر. بناء على تعليق Paul Mclink، حل هذه الخطوتين المشكلة.

1. إعادة تشغيل Visual Studio.
2. نظيفة، بناء (إعادة بناء)

و ال حدث خطأ.

إعادة تشغيل مقابل البرنامج المساعد

شكرا بول :)

آمل أن يساعد هذا الشخص الذي يأتي عبر هذا الخطأ :)

Answer 22

ركضت أيضا في هذه المشكلة أثناء تشغيل بلدي التغريد. ركض التطبيق غرامة مع عدم وجود أخطاء. كان سبب المشكلة في حالتي أنني قد أوقفت بناء مشاريع الاختبار. إعادة تشغيل بناء الخصية الخاصة بي حل المشكلات.

Answer 23

رأيت هذا في Visual Studio Pro 2008 عندما بنيت مشاريعان تجميعات مع نفس الاسم، واحدة من فئة LIB SDF.DLL، وواحدة تشير إلى lib مع اسم التجميع SDF.exe. عندما غيرت اسم الجمعية المرجعية، ذهب الاستثناء بعيدا

Answer 24

هذا يعني ببساطة أن مشروع التنفيذ قديم في حالاتي. تم إعادة بناء DLL التي تحتوي على الواجهة ولكن تم التنفيذ DLL قديم.

Answer 25

إليك تأخذ هذا الخطأ.

وأضاف extern الطريقة، لكن معجني كان معيبا. ال DllImportAttribute حصلت على وضع على خط التعليق.

/// <returns>(removed for brevity lol)</returns>[DllImport("user32.dll")] 
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool IsWindowVisible(IntPtr hWnd);

ضمان إدراج السمة في الواقع في المصدر الثابتة المشكلة.

Answer 26

حصلت على هذا في خدمة WCF بسبب وجود نوع بناء X86 المحدد، مما يؤدي إلى تعيش الصناديق ضمن BIN X86 بدلا من الصندوق. تسبب تحديد أي وحدة المعالجة المركزية في إعادة ترجمة DLLs للذهاب إلى المواقع الصحيحة (لن أخوض بالتفصيل حول كيفية حدوث ذلك في المقام الأول).

Answer 27

كان لي نفس المشكلة. احصل على أن التجمع الخاص بي، الذي يتم تحميله بواسطة البرنامج الرئيسي، كان لديه بعض المراجع مع تعيين "نسخ محلي" إلى True. تبحث هذه النسخ المحلية من المراجع عن مراجع أخرى في نفس المجلد، والذي لم يكن موجودا لأن "نسخ المحلي" من المراجع الأخرى تم تعيينها إلى FALSE. بعد حذف المراجع المنسوخة "بطريق الخطأ"، انتهى الخطأ لأنه تم تعيين البرنامج الرئيسي للبحث عن المواقع الصحيحة للمراجع. يبدو أن النسخ المحلية من المراجع ثمل تسلسل الاتصال نظرا لاستخدام هذه النسخ المحلية بدلا من تلك الأصلية الموجودة في البرنامج الرئيسي.

الرسائل الرئيسية تأخذ هي أن هذا الخطأ يظهر بسبب الرابط المفقود لتحميل التجميع المطلوب.

Answer 28

في حالتي، كنت أحاول استخدامها TypeBuilder لإنشاء نوع. TypeBuilder.CreateType رمى هذا الاستثناء. أدركت في النهاية أنني بحاجة إلى إضافة MethodAttributes.Virtual إلى السمات عند الاتصال TypeBuilder.DefineMethod للحصول على طريقة تساعد في تنفذ واجهة. هذا لأنه بدون هذه العلامة، لا تنفذ الطريقة الواجهة، بل طريقة جديدة بنفس التوقيع بدلا من ذلك (حتى دون تحديد MethodAttributes.NewSlot).

Answer 29

كإضافة: يمكن أن يحدث هذا أيضا إذا قمت بتحديث حزمة Nuget التي تم استخدامها لتوليد مجموعة مزيفة. قل لك تثبيت V1.0 من حزمة Nuget وإنشاء مجموعة مزيفة "fakelibrary.1.0.0.0.fakes". بعد ذلك، يمكنك التحديث بأحدث إصدار من حزمة Nuget، قل V1.1 التي أضافت طريقة جديدة إلى واجهة. مكتبة المصفصية لا تزال تبحث عن v1.0 من المكتبة. ببساطة إزالة التجمع المزيف وتجديده. إذا كانت هذه هي المشكلة، فمن المحتمل أن يصلح ذلك.

Answer 30

تلقيت هذا الخطأ بعد تحديث Windows حديث. كان لدي خدمة فئة الخدمة للوصول من واجهة. تضمن الواجهة توقيعا عاد قيمة ValueTuple، ميزة جديدة إلى حد ما في C #.

كل ما يمكنني تخمينه هو أن Windows Update مثبت واحد جديد، ولكن حتى الرجوع إليه صراحة، تحديث إعادة توجيهات ملزمة، إلخ ... كانت النتيجة النهائية تغيير توقيع الطريقة لشيء ما "قياسي" أعتقد أنك يمكن أن تقول.