Programm startet nicht auf anderen Rechnern

[Arne Drews]

Moin,

Also ich habe ein kleines Tool, das über HttpWebRequest-Komponenten eine API ansteuert.
Entwickelt habe ich das hier auf der Arbeit auf meinem Dienstrechner. Laufen soll das zukünftig auf Rechnern der Buchhaltung.

Dieses Tool ist nicht das erste, was ich firmenintern entwickelt habe und auch auf mehreren Rechnern genutzt wird.
Jedoch startet das Tool auf anderen, wie dem meinen nicht und meldet mir ein Fenster, in dem ich weitere Informationen zum Datenschutz anklicken kann?!

Entwickelt habe ich das Tool auf Basis des .NET 4.0 ClientProfile Framework.
Alle Rechner haben dieses installiert und auch dieselbe Windows Version, wie ich (Windows 7 64bit).
Auch die aktuellsten Updates sind drin.

Die Systeme an sich unterscheiden sich also nicht wirklich.

Meine Vermutung liegt in den Ausführungsrechten.
Ich selbst bin lokaler Administrator. Die Benutzer in der Buchhaltung natürlich nicht.
Als Administrator habe ich das Tool auch schon gestartet, aber das hilft auch nichts.

Dem widerspricht auch, daß die anderen Tools überall funktionieren und ebenfalls API-Anbindungen über HttpWebRequest nutzen.
Es besteht eigentlich kein technischer Unterschied zu den anderen Tools.

Hat jemand eine Vermutung, wo es noch zu Problemen kommen könnte?
Falls mehr Infos gebraucht werden, stelle ich die natürlich gern zur Verfügung.

Danke
Arne

[Ralf Jansen]

Jedoch startet das Tool auf anderen, wie dem meinen nicht und meldet mir ein Fenster, in dem ich weitere Informationen zum Datenschutz anklicken kann?!

Wenn du uns hier mehr Details verätst fällt uns vielleicht was ein.

[Arne Drews]

Ja, sorry... Hab nur flüchtig gelesen. Der Datenschutzhinweis gilt natürlich für die Möglichkeit, das Problem an Microsoft zu senden.

Naja, wie dem auch sei, dieses bekannte Fenster kommt zum Vorschein:
info-senden.jpg

Die Datein habe ich mir angesehen und festgestellt, daß in der XML eine FileNotFound-Exception registriert wurde.
Allerdings weiß ich nicht, was das soll. Das Programm ist doch physisch da und auf ein anderes File greife ich nicht zu.

Hier mal die XML:

<?xml version="1.0" encoding="UTF-8"?>
<WERReportMetadata>
    <OSVersionInformation>
        <WindowsNTVersion>6.1</WindowsNTVersion>
        <Build>7601 Service Pack 1</Build>
        <Product>(0x30): Windows 7 Professional</Product>
        <Edition>Professional</Edition>
        <BuildString>7601.18247.amd64fre.win7sp1_gdr.130828-1532</BuildString>
        <Revision>1130</Revision>
        <Flavor>Multiprocessor Free</Flavor>
        <Architecture>X64</Architecture>
        <LCID>1031</LCID>
    </OSVersionInformation>
    <ProblemSignatures>
        <EventType>CLR20r3</EventType>
        <Parameter0>buchhaltung.exe</Parameter0>
        <Parameter1>1.0.0.0</Parameter1>
        <Parameter2>52779c8f</Parameter2>
        <Parameter3>Buchhaltung</Parameter3>
        <Parameter4>1.0.0.0</Parameter4>
        <Parameter5>52779c8f</Parameter5>
        <Parameter6>3</Parameter6>
        <Parameter7>1a</Parameter7>
        <Parameter8>System.IO.FileNotFoundException</Parameter8> <!-- HIER ISSER... -->
    </ProblemSignatures>
    <DynamicSignatures>
        <Parameter1>6.1.7601.2.1.0.256.48</Parameter1>
        <Parameter2>1031</Parameter2>
        <Parameter22>0a9e</Parameter22>
        <Parameter23>0a9e372d3b4ad19135b953a78882e789</Parameter23>
        <Parameter24>0a9e</Parameter24>
        <Parameter25>0a9e372d3b4ad19135b953a78882e789</Parameter25>
    </DynamicSignatures>
    <SystemInformation>
        <MID>BD317D5B-AF17-41BA-9047-B07A7B3BABB5</MID>
        <SystemManufacturer>MSI</SystemManufacturer>
        <SystemProductName>MT-7641</SystemProductName>
        <BIOSVersion>V17.28B3</BIOSVersion>
    </SystemInformation>
</WERReportMetadata>

[Ralf Jansen]

Du hast mindestens 2 Möglichkeiten um dahinter zu kommen welche Abhängigkeit er möchte aber nicht da ist.

a.) fuslogvw verwenden um das Laden der Assemblies zu beobachten.
b.) In deine Anwendung ein früh ziehenden Exceptionhandling einbauen um möglichst dem windowseigenen Errorreporting zuvor zukommen. (Ein gutes Exceptionhandling zu haben ist eh immer gut)
Zum Beispiel über das Appication.CurrentDomain.UnhandledException Event

[Arne Drews]

Ok, fuslogvw kannte ich nicht, danke für den Tipp.
Zeigt mir in meinem Fall das hier:

*** Protokolleintrag für Assembly-Binder  (04.11.2013 @ 16:25:02) ***

Fehler bei diesem Vorgang.
Ergebnis der Bindung: hr = 0x80070002. Das System kann die angegebene Datei nicht finden.

Der Assemblymanager wurde geladen aus:  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Als EXE-Datei ausgeführt.  C:\Users\Arne\Documents\Visual Studio 2010\Projects\Buchhaltung\Buchhaltung\bin\Debug\Buchhaltung.exe
--- Ein detailliertes Fehlerprotokoll folgt.

=== Zustandsinformationen vor Bindung ===
LOG: Benutzer = XEON\ArneLOG: DisplayName = Buchhaltung.resources, Version=1.0.0.0, Culture=de, PublicKeyToken=null (Fully-specified)
LOG: Appbase = file:///C:/Users/Arne/Documents/Visual Studio 2010/Projects/Buchhaltung/Buchhaltung/bin/Debug/
LOG: Ursprünglicher PrivatePath = NULLLOG: DynamicBase = NULLLOG: CacheBase = NULLLOG: AppName = Buchhaltung.exeAufruf von Assembly : Buchhaltung, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: Diese Bindung startet im default-Load-Kontext.
LOG: Die Anwendungskonfigurationsdatei wird verwendet: C:\Users\Arne\Documents\Visual Studio 2010\Projects\Buchhaltung\Buchhaltung\bin\Debug\Buchhaltung.exe.Config
LOG: Die Hostkonfigurationsdatei wird verwendet:
LOG: Die Computerkonfigurationsdatei von C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config wird verwendet.
LOG: Die Richtlinie wird derzeit nicht auf den Verweis angewendet (private, benutzerdefinierte, teilweise oder pfadbasierte Assemblybindung)
LOG: Download von neuem URL file:///C:/Users/Arne/Documents/Visual Studio 2010/Projects/Buchhaltung/Buchhaltung/bin/Debug/de/Buchhaltung.resources.DLL.
LOG: Download von neuem URL file:///C:/Users/Arne/Documents/Visual Studio 2010/Projects/Buchhaltung/Buchhaltung/bin/Debug/de/Buchhaltung.resources/Buchhaltung.resources.DLL.
LOG: Download von neuem URL file:///C:/Users/Arne/Documents/Visual Studio 2010/Projects/Buchhaltung/Buchhaltung/bin/Debug/de/Buchhaltung.resources.EXE.
LOG: Download von neuem URL file:///C:/Users/Arne/Documents/Visual Studio 2010/Projects/Buchhaltung/Buchhaltung/bin/Debug/de/Buchhaltung.resources/Buchhaltung.resources.EXE.
LOG: Fehler bei allen Such-URLs.

Welche Datei das System nun genau nicht findet, kann ich mir nicht erklären...

[Ralf Jansen]

offensichtlich deine lokalisierten deutschen Resourcen die man normalerwiese im 'de' Unterordner zur Anwendung liegen hat und Buchhaltung.resources.DLL heißen sollte (der Fusion Prozess kennt noch ein paar Alternativen die er hier abspullt)

[Arne Drews]

Aber wo soll die DLL herkommen? Ich hab doch keine extra DLL angelegt. Es existiert auch im gesamten Projektverzeichnis keine zugehörige DLL.

[Ralf Jansen]

Dann ist das vielleicht eine eigentlich stille Exception die fuslogvw da loggt(der loggt halt alles). Also quasi nach dem Motto "wenn ich deutsche Resourcen nicht finde dann nehm ich halt die in der Executable und mach einfach weiter". Die sind zwar üblicherweise eher als "en" markiert sind aber wenn nix gefunden werden kann eben der Fallback. In dem Fall solltest du aber noch ein weiteres gescheitertes Binding im Fuslogvw Log sehen für den eigentlichen Auslöser der Exception.

[Bernhard Geyer]

Normalerweise sollte bei .NET eine vernünftige Fehlermeldung kommen wenn etwas fehlt.
Bei so einem harten Absturz würde ich eher darauf Tippen das die .NET-Runtime auf dem Rechner kaputt ist.

Kannst du mal ein "Hello World"-C#-Programm machen und mal auf diesem Rechner testen?

[Arne Drews]

Also ein HelloWorld hab ich jetzt nicht gemacht, aber ein anderes Tool getestet, das ich letzte Woche auf selber Basis fertig gestellt habe und bisher nie auf den Rechnern verfügbar war.
Selbes Prinzip: kurze Auswahl und per Button auf externe API -> Läuft einwandfrei! .NET 4 scheint ok zu sein...

Diese Zeile macht mich stutzig:

Ergebnis der Bindung: hr = 0x80070002. Das System kann die angegebene Datei nicht finden.

Die 0x80070002 referenziert soweit ich das rauslesen konnte auf die System.IO.FileNotFoundException.
Also scheint beim Binding etwas schief zu laufen. Nur was verstehe ich leider nicht...

[Arne Drews]

[ERLEDIGT] Problem gefunden und behoben

Mich hat die ganze Zeit beschäftigt, was es mit diesem Verzeichnis de auf sich hat.
Beim verzweifelten durchqueren aller Projektdateien fiel mir in der Form.cs folgende Zeile auf:

using System.Globalization;

Wie auch immer das dort hin gekommen ist (es war bei Projektstart definitiv nicht da!), nachdem ich die Zeile auskommentiert habe, funktioniert es auf allen anderen Rechnern auch!

Danke für eure Mühen!
Gruß Arne