System.Diagnostics.DiagnosticSource System.IO.FileLoadException

verwendetes Datenbanksystem: MS-SQL 2017
mit EntityFramework Core

Also Folgende Anwendung Aufbau:

Dll A:
Enthält Models und EntityFramework DataContext classe.

Da ist verweis vorhanden auf System.Diagnostics.DiagnosticSource Version 4.3.0.1

Dll B:
Zeigt Model in Masken, verweis auf Dll A

exe C verweißt Auf Dll B und nutzt klassen daraus die wiederum Classen (darunter DataContext) aus Dll A.

Problem war das, bei ausführen C wurde Exception:
System.IO.FileLoadException:> Fehlermeldung:

Die Datei oder Assembly "System.Diagnostics.DiagnosticSource, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" oder eine Abhängigkeit davon wurde nicht gefunden.

Nach der Recherche lösung:
App.Config:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

      <dependentAssembly>
        <assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="4.0.3.0" newVersion="4.0.3.1" />
      </dependentAssembly>

Funktioniert alles gut

Jetzt aber folgendes
Es ist eine classe in Dll B Vorhanden, die als COM classe deklariert ist und wird aus einer Nativen (nicht .net) Programm aufgerufen.

Da kommt immer noch Exception System.IO.FileLoadException (oben beschrieben).

Eine App.Config zu Dll B hinzuzufügen bring nichts (es reagiert zumindest nicht).
Gleiche Nuget pakete zu verweisen bringt auch nichts.

Was kann man da noch machen?

Lass das Binding weg und arbeite nur mit dem NuGet Paket.
Ansonsten: [Tutorial] Vertrackte Fehler durch Vergleich von echtem Projekt mit minimalem Testprojekt finden

Lass das Binding weg und arbeite nur mit dem NuGet Paket.

Wenn ich Sie richtig verstehe, muss ich anstelle App.Config

für alle Projekte die ursprungliche Dll A nutzen müssen (direkt als auch indirekt, EntityFramework Core Nuget Pakte anbinden, korrekt ?

NuGet Pakete referenzieren und (im Mix) DLLs direkt referenzieren (ohne Paket) gibt in den meisten Fällen Probleme.
Daher durchweg die Pakete verwenden.

Daher durchweg die Pakete verwenden.

90% Assemlblys Nuget pakete hinzugefügt, kein reaktion.

Ohne:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

      <dependentAssembly>
        <assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="4.0.3.0" newVersion="4.0.3.1" />
      </dependentAssembly>

Trotz nuget pakete funktioniert jetzt Word - AddInn nicht mehr...
Gibt's eventuell Tools die anzeugen können welche Assemblys gebunden sind?
Versuche morgen noch restliche 10% Nuget pakete hinzuzufügen. Wenn das auch nicht hilft, prost...

DependencyWalker

Da ich hier Word Addin lese...
Die .NET Schnittstelle für Word gilt als veraltet - und das ist schon gute 3 Jahre so.

Die aktuelle Schnittstelle für Word basiert komplett auf einer JavaScript API.
Und so wie Office sich gerade weiterentwickelt würde ich auch eher davon ausgehen, dass die .NET / COM Schnittstelle komplett verschwindet.

Die Gefahr, dass Du hier derzeit Wegwerf-Code produzierst, ist sehr sehr hoch - fast schon garantiert.
Meine persönliche Empfehlung, wenn Du Office Extensions mit Zukunft schreiben willst: JavaScript.

DependencyWalker

Die aktuelle Schnittstelle für Word basiert komplett auf einer JavaScript API.

Ja, da arbeiten wir dran, es stimmt. Aber ein Modul, muss noch mit "alten" Modulen laufen (leider), wenn ich das fertig kriege (auch wegen Nativer Anwendung), wird der Rest schnell gehen (1-2 tage)...

Das Blödsinn bremst mich enorm...

Also Sie kennen kein Tool?

Nicht "Sie", "Du".

DependencyWalker

Aber _eigentlich _braucht man das bei korrektem Pakethandling nicht.

Hab gelöst... hura

Es waren falsche versionen an core Dll gebunden.

system.Component.Anntotation 4.4.1 statt 4.5

und

system.diagnostic.diagnostigsource 4.5.0 statt 4.5.1

wenn man "Bildungsumleitung automatisch generieren" ausmacht lief auch ursächliche dll nicht.