VS zeigt seltsames Verhalten auf unterschiedlichen Maschinen

[C. W. (chefkoch)]

Hallo *,

ich habe ein komisches Verhalten im Visual Studio (VB .net) auf 
verschiedenen Maschinen:

Eine Anwendung wir im gleichen Stand aus einem SVN-Repo auf zwei 
unterschiedlichen Maschinen ausgecheckt. Es handelt sich bei den 
Maschinen um VMs. Auf beiden läuft das gleiche Visual Studio unter der 
gleichen Windows 10 Version. Auf Maschinen A geht alles problemlos, wie 
seit Jahren auf jeder anderen physischen Maschine auch, und bei Maschine 
B knallt es mit einer Meldung wie:

System.TypeInitializationException
  HResult=0x80131534
  Nachricht = Der Typeninitialisierer für "xxx.Funktionen" hat eine 
Ausnahme verursacht.
  Quelle = xxx
  Stapelüberwachung:
   bei xxx.Funktionen.GetDatatable(String SQLstring) in 
C:\Users\xxx\source\repos\Project1\xxx\Funktionen.vb: Zeile119
   bei xxx.FormUsr.ButtonOK_Click(Object sender, EventArgs e) in 
C:\Users\xxx\source\repos\Project1\V2013\FormUsr.vb: Zeile17
   bei System.Windows.Forms.Control.OnClick(EventArgs e)
   bei System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons 
button, Int32 clicks)
   bei System.Windows.Forms.Control.WndProc(Message& m)
   bei System.Windows.Forms.ButtonBase.WndProc(Message& m)
   bei System.Windows.Forms.Button.WndProc(Message& m)
   bei System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, 
Int32 msg, IntPtr wparam, IntPtr lparam)
   bei System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& 
msg)
   bei 
System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.U 
nsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr 
dwComponentID, Int32 reason, Int32 pvLoopData)
   bei 
System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 
reason, ApplicationContext context)
   bei 
System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 
reason, ApplicationContext context)
   bei 
Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.On 
Run()
   bei 
Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Do 
ApplicationModel()
   bei 
Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Ru 
n(String[]  commandLine)
   bei xxx.My.MyApplication.Main(String[] Args) in : Zeile83

Innere Ausnahme 1:
FileNotFoundException: Die Datei oder Assembly "System.Data.Common, 
Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" oder 
eine Abhängigkeit davon wurde nicht gefunden. Das System kann die 
angegebene Datei nicht finden.

Hat jemand dieses Verhalten schon beobachtet? Maschinen A lief "out of 
the box" und Maschine B wurde bereits neu aufgesetzt.

[Franko P. (sgssn)]

Hallo
.net braucht dotnet. :-) Bei C# hatte ich auch schon das Problem, dass 
da auf dem Rechner eine Installation vom richtigen dotnet fehlte.

Gruß

[c-hater (Gast)]

Franko P. schrieb:

> .net braucht dotnet. :-) Bei C# hatte ich auch schon das Problem, dass
> da auf dem Rechner eine Installation vom richtigen dotnet fehlte.

Genau. Hier fehlt wohl konkret DotNet5. Und wenn das so ist, dann sehr 
wahrscheinlich nicht nur die Runtime, sondern vor allem auch das 
entsprechende TargetingPack für das Studio.

[C. W. (chefkoch)]

Nette Idee - leider ohne Erfolg. Das Targetframework ist ja schon in den 
Projekeigenschafen definiert, egal ob dort 4.7.2 oder 4.8 ausgewählt ist 
kommt die gleiche Meldung.

[Hans-Georg L. (h-g-l)]

Kannst ja mal mit einem Dependency Walker die Abhängigkeiten auflisten 
und schauen was fehlt. Das Original ist total veraltet und funktioniert 
bis Vista.
Hier gibt es ein neueres, habe ich aber noch nicht selbst ausprobiert.

https://github.com/lucasg/Dependencies

[c-hater (Gast)]

C. W. schrieb:

> Nette Idee - leider ohne Erfolg. Das Targetframework ist ja schon in den
> Projekeigenschafen definiert, egal ob dort 4.7.2 oder 4.8 ausgewählt ist
> kommt die gleiche Meldung.

Hast du nun das DotNet5-TargetingPack auf der Problem-Kiste installiert 
oder nicht?

[C. W. (chefkoch)]

Mit dem Visual Studio 2022 ist als Targetframework gar kein 5.0 möglich. 
4.8 ist das höchste der Gefühle.

[c-hater (Gast)]

C. W. schrieb:

> Mit dem Visual Studio 2022 ist als Targetframework gar kein 5.0 möglich.
> 4.8 ist das höchste der Gefühle.

Das kann ganz sicher DotNet5, denn das konnte selbst schon das Studio 
2019.

Allerdings wird man bei VS2022 kein TargetingPack dafür installieren 
müssen, das dürfte hier bereits "ab Werk" enthalten sein. Wurde 
vielleicht aber bei der Installation abgewählt. Wenn das der Fall ist, 
muss es halt nachinstalliert werden.

[Schlaumaier (Gast)]

C. W. schrieb:
> C:\Users\xxx\source\repos\Project1\xxx\Funktionen.vb: Zeile119
>    bei xxx.FormUsr.ButtonOK_Click(Object sender, EventArgs e) in
> C:\Users\xxx\source\repos\Project1\V2013\FormUsr.vb: Zeile17


Das sind die einzigen Zeilen der Fehlermeldung die wirklich was 
aussagen.

Also

Was steht in Zeile 119 in der Datei  Funktionen.vb

und was in Zeile 17 in der Datei FormUsr.vb

Ich rate mal: Da steht ein Funktionsaufruf einer API o.s.ä. drin.

Und die ist nicht auf den richtigen Stand.

Also poste mal so je 10 Zeilen um die besagte jeweils Zeile damit man 
sehen kann wo man weiter suchen muss.

[Schlaumaier (Gast)]

Nachtrag :

https://docs.microsoft.com/de-de/dotnet/api/system.data.common?view=net-6.0

Ich würde mal vermuten das der Datenbanktreiber nicht installiert ist, 
da ja dein normaler Prg.-Code auf der anderen Kiste läuft.

[c-hater (Gast)]

Schlaumaier schrieb:

> C. W. schrieb:
>> C:\Users\xxx\source\repos\Project1\xxx\Funktionen.vb: Zeile119
>>    bei xxx.FormUsr.ButtonOK_Click(Object sender, EventArgs e) in
>> C:\Users\xxx\source\repos\Project1\V2013\FormUsr.vb: Zeile17
>
>
> Das sind die einzigen Zeilen der Fehlermeldung die wirklich was
> aussagen.

Unsinn. Die einzigen Zeilen, die wirklich was aussagen sind diese:

> Innere Ausnahme 1:
> FileNotFoundException: Die Datei oder Assembly "System.Data.Common,
> Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" oder
> eine Abhängigkeit davon wurde nicht gefunden. Das System kann die
> angegebene Datei nicht finden.

Da steht ganz klar, dass System.Data.Common von DotNet5 an irgendeiner 
Stelle verwendet wird, diese aber nicht gefunden werden kann. Was mit an 
Sicherheit grenzender Wahrscheinlichkeit halt daran liegt, dass das 
entsprechende TargetingPack nicht installiert ist (denn das würde 
zwangsläufig die entsprechende Runtime mitinstallieren).

[Schlaumaier (Gast)]

c-hater schrieb:
> (denn das würde
> zwangsläufig die entsprechende Runtime mitinstallieren).

Nicht unbedingt.

Deshalb ist der Aufruf in den Zeilen wichtig.  Das lässt mit etwas Glück 
auf die verwendete Datenbank schließen. Wenn ich die habe, dann kann man 
schauen warum die nicht installiert ist.

Es ist nämlich in VS (relativ) problemlos möglich fast JEDES 
Datenbank-System/Modul anzusprechen. Entweder direkt oder über passende 
DB-Treiber.

Aber ich geben dir (wie im Nachtrag gesagt) recht. Der Grundfehler hängt 
mit System.Data.Common zusammen.

Zitat MS

System.Data.Common Namespace
Dieser Namespace enthält Klassen, die von .NET-Datenanbietern verwendet 
werden.

Und genau DA sehe ich den Fehler. Der Datenanbieter (was immer das in 
den Fall ist) fehlt. !!!

Ich muss bei meinen Prg. z.b. die SQLite DLL einbinden ins Projekt und 
dann bei den Installer VON HAND hinzufügen. Wenn die DLL Fehlt (oder 
nicht registiert ist) knallt es mir mit ähnlichen Sprüchen genau so weg.

[C. W. (chefkoch)]

Ja - es war der MySQL-Connector der gefehlt hat.

Schande über mein Haupt!

[Schlaumaier (Gast)]

C. W. schrieb:
> Ja - es war der MySQL-Connector der gefehlt hat.
>
> Schande über mein Haupt!

och passiert den besten. tröst

Ist doch schön wenn ich auch mal Recht habe. ;)