Laden...

.exe startet nicht auf zweitem Rechner (nur nach einmaliger VS installation)

Erstellt von WMenzel vor 4 Jahren Letzter Beitrag vor 4 Jahren 3.444 Views
W
WMenzel Themenstarter:in
28 Beiträge seit 2012
vor 4 Jahren
.exe startet nicht auf zweitem Rechner (nur nach einmaliger VS installation)

Betrifft: C#
In den meisten Fällen reicht es ja, die Dateien im Release-Ordner auf den PC zu kopieren, wo das Programm laufen soll. Hat bisher auch immer funktioniert!
Jetzt gab es das Problem, dass beim Anklicken der .exe der Cursor 2 Mal sich verändert, aber das Programm nicht startet, es kommt auch keine Fehlermeldung.
Es sind z.B. 2 PC's, auf einem funktioniert es, auf dem anderen nicht, sind beide mit Windows 10 aufgesetzt, das Framework ist gleich. Trotzdem funktioniert es auf einem PC nicht.
Ich habe auch mal mit der Veröffentlichung und mit InnoSetup ein Setup erstellt, aber das ging auch nicht.
Als einzige Lösung habe ich jetzt VS Studio auf dem nicht funktionierenden PC installiert und getestet, dann funktioniert es. Auf nach Deinstallation von VS Studio funktioniert es weiterhin.

Kann jemand was dazu schreiben, woran das liegen kann oder was der beste Weg ist, dieses Problem zu lösen.

Danke im Voraus

Gruß

709 Beiträge seit 2008
vor 4 Jahren
87 Beiträge seit 2016
vor 4 Jahren

Hallo,

steht was in der Windows-Ereignisanzeige?

glandorf

16.806 Beiträge seit 2008
vor 4 Jahren

In den meisten Fällen reicht es ja, die Dateien im Release-Ordner auf den PC zu kopieren, wo das Programm laufen soll.

Tatsächlich dürfte das in den wenigsten (<1%) Fällen reichen, weil _quasi _keine Anwendung (kein Tool!) ohne externe Abhängigkeiten auskommt.
Daher ist dies auch der ungeeignetste Weg, wie man Software verteilen kann 😃

Mit .NET 5 ist dieses Vorhaben grundsätzlich nicht mehr möglich; man muss immer die Dependencies mit liefern (wobei es hier verschiedene Optionen gibt).

W
WMenzel Themenstarter:in
28 Beiträge seit 2012
vor 4 Jahren

Aber wie macht man es dann richtig? Mit Veröffentlichen habe ich ein Setup erstellt, das ging nicht und die Installation mit InnoSetup hat auch nicht funktioniert.

16.806 Beiträge seit 2008
vor 4 Jahren

Richtig gehts zB mit einem Setup; das ist verantwortlich dafür, dass Dependencies mitkommen / da sind.
Wenn "es nicht funktioniert" dann hast wohl was nicht richtig gemacht 😃

4.931 Beiträge seit 2008
vor 4 Jahren

Hallo,

verwendest du denn externe Assemblies (Verweise)? Dann kannst du dies mit DependencyWalker.Net überprüfen (und diese dann in den Release-Ordner kopieren lassen bzw. dem Setup-Programm mitgeben).

Welches .NET-Framework verwendest du denn (und sind jeweils die Versionen auf den Rechnern gleich vorhanden - inkl. Updates)?

Und läuft denn der Prozess nach dem Starten der Anwendung (im TaskManager)? Evtl. hast du dort (unbewußt) irgendwie eine Endlosschleife im Programm erzeugt. Oder greifst du auf andere externe Dateien (Config, DB, ...) zu?

W
WMenzel Themenstarter:in
28 Beiträge seit 2012
vor 4 Jahren

Aber was ist mit der Lösung, dass ich VisualStudio auf dem Rechner, wo es nicht geht installiere und wieder lösche und es geht???? An den .Net-Versionen kann es nicht liegen, die sind gleich.
Ich habe eine Modbus-DLL, aber die ist in jeden Fall dabei.

16.806 Beiträge seit 2008
vor 4 Jahren

Das ist doch nicht Dein Ernst, dass Du so Dependencies verteilen willst...? 🤔
Würde vermuten, dass Deine ModBus DLL Abhängigkeiten will, zB. c++ redistributables.
Aber ne Glaskugel haben wir leider halt auch nicht.

Bitte verteil doch Deine Software ordentlich.

1.040 Beiträge seit 2007
vor 4 Jahren

...und wieder lösche und es geht????

Vermutlich weil nicht alles, was das Visual Studio installiert hat, auch tatsächlich wieder gelöscht wurde. Schaue doch mal, was an dem Tag der VS-Installation noch so installiert wurde. 😉

Ansonsten gilt aber das, was Abt sagt. =)

W
WMenzel Themenstarter:in
28 Beiträge seit 2012
vor 4 Jahren

Na dann gib mir doch bitte mal einen Tipp, wie ich die Software ordentlich verteilen soll. Wie gesagt, ich habe es mit Veröffentlichen und mit InnoSetup versucht, es ist immer das gleiche Ergebnis.
Gruß

5.657 Beiträge seit 2006
vor 4 Jahren

Wie willst du denn deine Software überhaupt veröffentlichen, wenn du nicht weißt, welche Abhängigkeiten sie hat?

Das wirst du doch herausbekommen können.

Was gibt AppDomain.UnhandledException aus, was sagt DependencyWalker, was sagt die Ereignisanzeige? Liest du die Antworten überhaupt, die du hier im Forum bekommst?

Weeks of programming can save you hours of planning

16.806 Beiträge seit 2008
vor 4 Jahren

Wenn Du nur sagst "Ich habs nicht geschafft, ein Setup zu erstellen" - wo sollen wir da helfen?
Wir haben doch keine Glaskugel um Dir zu sagen, wo der Fehler ist 🤔

4.931 Beiträge seit 2008
vor 4 Jahren

@WMenzel: Welche ModBus-DLL verwendest du denn?
Ich tippe jetzt auch darauf, so wie Abt schon vermutet hat, daß es an den Abhängigkeiten zu den C++ Redistributables liegt (welche passend zur VS-Version mitinstalliert werden), s.a. meine Links in Runtime umgebungen unter Windows.
Du müßtest dann also in deinem Setup das passende Redistributable-Setup mitaufrufen.

W
WMenzel Themenstarter:in
28 Beiträge seit 2012
vor 4 Jahren

Ich verwende die MbSlaveV7.ocx von WinTech schon seit Jahren (seit WindowsXP). Die OCX ist ordentlich im Windows registriert.
Ich müsste dann also x86: vc_redist.x86.exe bzw. x64: vc_redist.x64.exe beim Setup mitinstallieren?
Kann es jetzt leider nicht mehr ausprobieren, durch die Installation vom Studio läuft alles, muss es mir für das nächste Mal merken.
DependencyWalker zeigt mir nur 2 DLL's an, die ich aber mit übergebe. In der Ereignismeldung von Windows steht etwas von KernelBase.Dll, was aber völlig unverständlich ist.

Danke

4.931 Beiträge seit 2008
vor 4 Jahren

Dann verwende den nativen Dependency Walker, um die Abhängigkeiten herauszufinden (es kommen generell Warnungen bzgl. "Error: At least one required implicit or forwarded dependency was not found.", welche du aber ignorieren kannst).

Ich habe jetzt mal von WinTech: Demos die "Mbsv7OCX.zip" heruntergeladen und die "mbSlaveV7.ocx" analysiert:

  • die im ZIP enthaltene "Modbusl.dll", welche aber nur 3 System-DLLs referenziert
  • es wird außer der "MSVCRT.DLL", welche standardmäßig bei Windows dabei ist, keine weitere C bzw. C++ Redistributable benötigt
  • es wird neben den System-DLLs nur noch auf die "MFC42.DLL" zugegriffen (welche m.E. aber auch schon von Windows mitinstalliert wird) - aber evtl. wurde diese (bzw. die richtige Version) erst bei der VS-Installation mit installiert?

Laut DLL_Hell#Static_linking gibt es wohl verschiedene Versionen dieser DLL (so daß es also zu eigenartigen Fehlern - wie bei dir - kommen kann, wenn eine andere Version verwendet wird).
Beim Download anderer Programme (z.B. "CDex") bieten diese auch teilweise den separaten Download der MFC42.DLL an.
Evtl. solltest du diese also in dein Setup mitaufnehmen (evtl. dann in den Release-Ordner, um sicherzustellen, daß immer diese DLL für das OCX benutzt wird).

W
WMenzel Themenstarter:in
28 Beiträge seit 2012
vor 4 Jahren

Hallo, danke erstmal für die Anregungen. Ich kann das jetzt aber nicht testen, weil ich dieses Problem durch die Installation und Deinstallation von VS gelöst habe, zwar nicht elegant und richtig aber der Zweck heiligt ja bekanntlich die Mittel.
Schwierig ist eben nur, weil ich keinerlei Fehlermeldungen bekomme, auch in der Ereignisanzeige steht nichts aussagekräftiges drin. DependencyWalker zeigt mir nur 2 Abhängigkeiten, die aber mitgeschickt werden.

4.931 Beiträge seit 2008
vor 4 Jahren

DependencyWalker.Net und Dependency Walker sind zwei unterschiedliche Programme für den jeweiligen Einsatz (erste für managed .NET-Assemblies und zweite für unmanaged (native) DLL/EXE/OCX (meist in C oder C++ geschrieben)).

Und die Fehlermeldung bzgl. "KernelBase.dll" wurde dann von einer von der OCX referenzierten DLLs ausgelöst (höchstwahrscheinlich die "MFC42.dll" oder "MSVCRT.dll", welche es leider in verschiedenen Versionen gibt - mit mehr oder weniger Fehlern).

Auf meinem Rechner z.B. habe ich folgende Dateiversionen (kannst du auch mit dem Dependency Walker per Kontextmenü "Properties..." -> "Details" aufrufen):

  • MFC42.dll: 6.6.8063.0 (mit Produktversion 6.06.400)
  • MSVCRT.dll: 7.0.18362.1

PS: Beim Dependency Walker am besten einmal nach den Öffnen "Collapse All" (CTRL+W) aufrufen und dann auf das "+" klicken, um beim Abhängigkeitsbaum nur die oberste Ebene (direkte Abhängigkeiten) zu sehen.

S
248 Beiträge seit 2008
vor 4 Jahren

... steht etwas von KernelBase.Dll, was aber völlig unverständlich ist.

Wieso postest du die Meldung denn nicht einfach? Vielleicht kann hier jemand damit etwas anfangen.

U
135 Beiträge seit 2009
vor 4 Jahren

Kann es jetzt leider nicht mehr ausprobieren, durch die Installation vom Studio läuft alles, muss es mir für das nächste Mal merken.

So eine VM mit Windows ist doch schnell aufgesetzt?

Bietet sich eh an, mit einer VM zu testen: Snapshot machen, vermutete fehlende Abhängigkeit (z.B. eine bestimmte VC++ Redistributable Version) installieren, testen. Geht? Fein. Geht nicht? Snapshot zurück und nächsten Verdacht probieren.

Über den Snapshot kannst Du Dir sicher sein, dass Du auch wirklich wieder einen sauberen Stand hast. Deinstallation ist eine schlechte Idee, wie Du ja selbst bereits gemerkt hast... insbesondere wenn es sich um einen "Moloch" (im Sinne von: installiert unglaublich viele Komponenten mit, die teilweise bei einer Deinstallation auf dem System verbleiben) wie Visual Studio handelt 😉

W
113 Beiträge seit 2006
vor 4 Jahren

So eine VM mit Windows ist doch schnell aufgesetzt?

Die gibt es sogar fertig direkt bei Microsoft:
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

1.040 Beiträge seit 2007
vor 4 Jahren

Leider sind es keine aktuellen Windows 10-Versionen, weswegen z.B. die Installation vom .NET-Framework 4.8 nicht möglich ist.

16.806 Beiträge seit 2008
vor 4 Jahren

Dann macht man sich eben selbst ne VM, wenn die VMs nicht passen.
Ändert an der Weise der Problem-Identifizierung nichts. 😃

1.040 Beiträge seit 2007
vor 4 Jahren

Mein Kommentar/Hinweis bezog sich auf die vorgefertigten VMs, die so eben nicht brauchbar sind.
Den Rest habe ich nicht in Frage gestellt. 😉

16.806 Beiträge seit 2008
vor 4 Jahren

Nur weil 4.8 (zumindest aktuell) nicht dabei sind sind die VMs noch lange nicht pauschal "unbrauchbar" - der Ersteller hat nicht mehr eine spezifische .NET Version zur Sprache gebracht.
Es kommt auf den Zweck an. Daher ist das von Dir eine eher unfaire Aussage. 😃

1.040 Beiträge seit 2007
vor 4 Jahren

Passt schon. 😭

Nächstes Mal verfasse ich den Hinweis detaillierter, nämlich dass für die VMs dort aktuell (Stand: 21.01.2020) Windows 10 Build 10240 (aus dem Jahre 2015) verwendet wird. Dann kann jeder selbst entscheiden, was er damit anfängt.

463 Beiträge seit 2009
vor 4 Jahren

VMs dort aktuell (Stand: 21.01.2020) Windows 10 Build 10240 (aus dem Jahre 2015)

Verstehe dein Problem nicht - Windows Update aufrufen und gut ist.. Oder wie Abt schon sagte einfach eine eigene VM installieren (aber auch da musst du Windows Update aufrufen um up 2 date zu sein). Hat man keine Probleme - macht man sich Probleme. Sonst wäre das Leben ja langweilig!

W
113 Beiträge seit 2006
vor 4 Jahren

Nachtrag: Hier gibts auch aktuelle VMs vom Microsoft:
https://developer.microsoft.com/en-us/windows/downloads/virtual-machines