Gateway_man Geschrieben 7. Dezember 2009 Geschrieben 7. Dezember 2009 (bearbeitet) Hallo, vorweg einen kleinen Einblick in das besagte Projekt: Ich habe eine Anwendung geschrieben die Geschäfts - sowie Privatkontakte verwaltet. Man kann zudem Serienbriefen sowie Serien E-mails schreiben. Desweiteren agiert das Programm zusätzlich als E-Mail Client, sprich man kann seine bestehenden gmx ( o. ä.) Accounts abrufen. Das Programm hat jetzt schon eine für mich schwer überschaubare größe angenommen, was die Fehlersuche enorm erschwert. Erschwährend kommt noch hinzu das einige DLL's in C und Delphi geschrieben wurde zwecks Sicherheit und Performance. (Auf diese werden direkt beim Programmstart zugegriffen und mir fällt die Differenzierung bei der Fehlersuche leider etwas schwer.) Folgende Problematik hat sich ergeben! Ich habe einem Freund eine Art Beta Version gegeben, die er testen sollte. Bei ihm läuft Windows 7 auf dem Rechner. Vor kurzem schreibt er mich an und sagt mir, als er es das erste mal aufrufen wollte, kam direkt ein Fehler. Dieser sieht wie folgt aus: Beschreibung: Stopped working Problemsignatur: Problemereignisname: CLR20r3 Problemsignatur 01: dca.exe Problemsignatur 02: 1.0.1.8 Problemsignatur 03: 4b183449 Problemsignatur 04: DCA Problemsignatur 05: 1.0.1.8 Problemsignatur 06: 4b183449 Problemsignatur 07: 3f Problemsignatur 08: e9 Problemsignatur 09: System.InvalidOperationException Betriebsystemversion: 6.1.7100.2.0.0.256.1 Gebietsschema-ID: 1031 Lesen Sie unsere Datenschutzbestimmungen online: Windows 7 Privacy Highlights - Microsoft Windows Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline: C:\Windows\system32\de-DE\erofflps.txt Ich habe bereits nach dem Fehler System.InvalidOperationExeption gegoogled jedoch konnte ich das Problem nicht eingrenzen. Da ich zu eben solchen Testzwecken VM's mit verschiedenen OS's habe, testete ich es ebenfalls auf Windows 7. Bei mir kam kein Fehler. Weder auf Windows 7 noch auf Windows Vista oder auf Windows XP. In der Arbeit habe ich ebenfalls eine Win 7 RC in ner VM und habe es ebenfalls dort getestet. Da kam exakt der selbe Fehler. Das Verhalten scheint für mich sehr sporadisch aufzutreten, da ich auf allen System exakt die selben Aktionen durchgeführt habe. ==> Installation des .NET Frameworks 3.5 ==> Installation des Programmes Ich verstehe die Welt nichtmehr und bin auch etwas verärgert, da ich in dieses Projekt schon eine Menge Zeit investiert habe.... Ich würde mich über hilfreiche Vorschläge sehr Freuen. Lg Gateway Bearbeitet 7. Dezember 2009 von Gateway_man Zitieren
Argbeil Geschrieben 8. Dezember 2009 Geschrieben 8. Dezember 2009 Stehen im Windows Eventlog Details? Hast du mal .net 3.5 sp1 getestet? War die Entwicklungsumgebung XP? Schreibst du Daten in den Programme Ordner? Ist der ausführende User Administrator? Zitieren
Gateway_man Geschrieben 8. Dezember 2009 Autor Geschrieben 8. Dezember 2009 Stehen im Windows Eventlog Details? Hast du mal .net 3.5 sp1 getestet? War die Entwicklungsumgebung XP? Schreibst du Daten in den Programme Ordner? Ist der ausführende User Administrator? -In den Eventlog habe ich nochnicht gesehn, aber gute Idee danke. -Nein das SP1 habe ich nicht installiert und die Entwicklungsumgebung war und ist Windows Vista. -Das Programm wird standartmäßig im Programmeordner installiert und tätigt in den dafür vorgesehenen Subfolder einige Zugriffe, wie beispielsweise Datebankzugriffe und erstellt auch in besagten Ordner Files zu weiteren Verarbeitung. -Auf allen Testsystemen hatte der ensprechende User Administrative Rechte. Lg Gateway Zitieren
Argbeil Geschrieben 8. Dezember 2009 Geschrieben 8. Dezember 2009 Ein Subfolder unter dem Programme-Ordner? Teste mal ohne Admin Rechte. Zitieren
Gateway_man Geschrieben 8. Dezember 2009 Autor Geschrieben 8. Dezember 2009 (bearbeitet) Ein Subfolder unter dem Programme-Ordner? Teste mal ohne Admin Rechte. Subfolder im Sinne von: %root%\Programme\%Programmname%\"Subfolder"\ Das Testen ohne Admin Rechte habe ich bereits getan mit folgenden Ergebnissen: XP ==> Funktionalität gewährleistet Vista ==> Funktionalität gewährleistet Win 7 ==> Fehlende Berechtigungen bei der Installation der Anwendung! Bearbeitet 8. Dezember 2009 von Gateway_man Zitieren
Argbeil Geschrieben 8. Dezember 2009 Geschrieben 8. Dezember 2009 Ich weiß nicht ob es daran liegt ohne das Programm zu kennen, aber: In diesen Ordner darf eine Applikation "niemals-nie" Daten schreiben, das ist schon seit Windows 2000 eine Microsoft Guideline für Windows Entwicklung. Damit macht man sehr viele Funktionen unmöglich (User-Roaming, Terminal Services, Clusterfähigkeit, generelle Multi-User Nutzung, ..). Ich hab die genaue Entwicklung nicht im Kopf, aber ich glaube seit Vista braucht man Admin Rechte dafür und seit 7 geht es gar nicht mehr, am besten mal selber nachsehen, für jeden Windows Version gibt es da Regeln. Das "Problem" ist, das Microsoft zwar gesagt hat "macht es nicht" aber das OS es nicht direkt verboten hat. Für Applikationsdaten gibt es den ApplicationData Folder, den bekommst du über: Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) Für User-Spezifische Daten gibt es den UserData Folder. Zitieren
Gateway_man Geschrieben 8. Dezember 2009 Autor Geschrieben 8. Dezember 2009 Das könnte ich aber auch umgehen, indem ich den Standartinstallationpfad auf "C:\" setzte. Oder irre ich mich da? Zitieren
Argbeil Geschrieben 8. Dezember 2009 Geschrieben 8. Dezember 2009 Ne, das Problem bleibt ja das gleiche. Wenn auf dem Rechner z.B. Terminal Services laufen können zwei User beim zeitgleichen Zugriff Probleme bekommen. Aber das wird auch nicht das generelle Problem sein, hier sollte eigentlich eine SecurityException oder sowas geworfen werden. Kann es sein das deine Anwendung ein WPF Frontend hat und du keinen globalen Exception Handler geschrieben hast? Zitieren
Gateway_man Geschrieben 8. Dezember 2009 Autor Geschrieben 8. Dezember 2009 Ne, das Problem bleibt ja das gleiche. Wenn auf dem Rechner z.B. Terminal Services laufen können zwei User beim zeitgleichen Zugriff Probleme bekommen. Aber das wird auch nicht das generelle Problem sein, hier sollte eigentlich eine SecurityException oder sowas geworfen werden. Kann es sein das deine Anwendung ein WPF Frontend hat und du keinen globalen Exception Handler geschrieben hast? Das Programm lässt sich grundsätzlich nur für den aktuell angemeldeten User Installieren. Nein eine Security Exeption erhalte ich nicht. Jedoch gestaltet sich das analysieren des Fehlers als sehr schwierig, da ich wie gesagt zuhause diesen Fehler nich reproduzieren kann. Ich muss also mit dem Input vorlieb nehmen, den mir mein "Tester" schickt. Nein die Anwendung hat kein WPF Frontend. Was ich inzwischen vermute ist, das ich einen Pfad benötige, auf den selbst ein normaler User vollzugriff hat und das wäre wie oben schon erwähnt der Root Pfad. Mit dem Programme Ordner hatte ich schon öffters wegen der eingeschränkten Rechte Probleme. Wir werden sehn. Lg Gateway Zitieren
Argbeil Geschrieben 9. Dezember 2009 Geschrieben 9. Dezember 2009 Dann bau doch mal um dein Application Objekt ein try catch und gib eine detaillierte Fehlermeldung aus, inkl. aller InnerExceptions, kann man z.B. so machen: try { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new Form1()); } catch (Exception ex) { StringBuilder sb = new StringBuilder(); while (ex != null) { sb.Append("-->"); sb.Append(ex.Message); ex = ex.InnerException; } MessageBox.Show( sb.ToString(), "Unhandeled Exception", MessageBoxButtons.OK, MessageBoxIcon.Stop); throw; } Trotz allem - eine Windows Anwendung sollte niemals eigene Daten in oder unter ihrem Programmverzeichnis ablegen, dafür sind die genannten Special Folders da. Auch bei nur einem Benutzer funktioniert sonst das Roaming nicht. Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.