myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Entwicklung » Datentechnologien » System.Diagnostics.DiagnosticSource System.IO.FileLoadException
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

System.Diagnostics.DiagnosticSource System.IO.FileLoadException

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
Baumunk77
myCSharp.de-Mitglied

Dabei seit: 08.10.2014
Beiträge: 41
Entwicklungsumgebung: VS 2017
Herkunft: Germany


Baumunk77 ist offline

System.Diagnostics.DiagnosticSource System.IO.FileLoadException

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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:

XML-Code:
<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?
Neuer Beitrag 08.04.2019 14:22 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.953
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Lass das Binding weg und arbeite nur mit dem NuGet Paket.
Ansonsten:  [Tutorial] Vertrackte Fehler durch Vergleich von echtem Projekt mit minimalem Testprojekt finden
Neuer Beitrag 08.04.2019 14:37 Beiträge des Benutzers | zu Buddylist hinzufügen
Baumunk77
myCSharp.de-Mitglied

Dabei seit: 08.10.2014
Beiträge: 41
Entwicklungsumgebung: VS 2017
Herkunft: Germany

Themenstarter Thema begonnen von Baumunk77

Baumunk77 ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von Abt:
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 ?

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Baumunk77 am 08.04.2019 14:55.

Neuer Beitrag 08.04.2019 14:55 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.953
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

NuGet Pakete referenzieren und (im Mix) DLLs direkt referenzieren (ohne Paket) gibt in den meisten Fällen Probleme.
Daher durchweg die Pakete verwenden.
Neuer Beitrag 08.04.2019 15:39 Beiträge des Benutzers | zu Buddylist hinzufügen
Baumunk77
myCSharp.de-Mitglied

Dabei seit: 08.10.2014
Beiträge: 41
Entwicklungsumgebung: VS 2017
Herkunft: Germany

Themenstarter Thema begonnen von Baumunk77

Baumunk77 ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von Abt:
Daher durchweg die Pakete verwenden.

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

Ohne:

XML-Code:
<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...
Neuer Beitrag 08.04.2019 17:42 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.953
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
Neuer Beitrag 08.04.2019 19:35 Beiträge des Benutzers | zu Buddylist hinzufügen
Baumunk77
myCSharp.de-Mitglied

Dabei seit: 08.10.2014
Beiträge: 41
Entwicklungsumgebung: VS 2017
Herkunft: Germany

Themenstarter Thema begonnen von Baumunk77

Baumunk77 ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von Abt:
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?
Neuer Beitrag 08.04.2019 20:58 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.953
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Nicht "Sie", "Du".

Zitat von Abt:
DependencyWalker

Aber eigentlich braucht man das bei korrektem Pakethandling nicht.
Neuer Beitrag 08.04.2019 23:25 Beiträge des Benutzers | zu Buddylist hinzufügen
Baumunk77
myCSharp.de-Mitglied

Dabei seit: 08.10.2014
Beiträge: 41
Entwicklungsumgebung: VS 2017
Herkunft: Germany

Themenstarter Thema begonnen von Baumunk77

Baumunk77 ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
Neuer Beitrag 09.04.2019 11:59 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 5 Monate.
Der letzte Beitrag ist älter als 5 Monate.
Antwort erstellen


© Copyright 2003-2019 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 22.09.2019 03:35