Announcement

Collapse
No announcement yet.

Zielplattform WinXP Embedded - womit entwickeln

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Zielplattform WinXP Embedded - womit entwickeln

    Hallo Experten,

    das hier ist zwar ein ausgesprochenes Microsoft-Visual-Studio-Problem, aber einen passenderen Bereich als .NET Allgemein habe ich nicht gefunden. Wenns den gibt, bitte verschieben.

    Ich habe hier ein Gerät liegen, für das ich eine Anwendung schreiben soll. Ich bevorzuge C# und benutze seit etwa 18 Monaten Visual Studio 2005 Express und 2008 Standard. Das Gerät enthält eine 5GB-CF-Karte partitioniert in C: und D:. Windows XP Embedded und .Net 2.0 sind installiert.

    1. Ich kann Visual Studio 2008 Express nicht auf dem Gerät installieren, weil nicht genügend temporärer Speicher zur Verfügung steht.
    Kann man das umgehen?
    Kann ich Visual Studio mit einem anderen Rechner auf einen USB-Stick entpacken und von dem aus auf das Gerät installieren? Von mir aus auch vom Stick auf den Stick, nur dass das Gerät als System herhält.

    2. Auf meinem Entwicklungsrechner habe ich Visual Studio 2008 Standard.
    Meinen Recherchen nach unterstützt das kein Remote Debugging (Programm läuft auf Embedded-Gerät, Debugger auf Entwickler-Rechner).
    Gibt es einen Workaround, evtl mit älteren Express-Versionen?

    3. Sollte ich eine andere Entwicklerumgebung in Betracht ziehen, gibt es Remote Debugging für C# z.B. in Eclipse?

    Danke schonmal fürs Interesse


    luker

  • #2
    Versuch doch mal herauszufinden ob SharpDevelop 3.0 Remote Debugging unterstützt es ist wesentlich schlanker und dürfte sich zur not auch ohne Probleme auf dem Embedded Rechner installieren lassen.

    Hab nochmal nachgesehen ein RemoteDebugging wird noch nicht unterstützt jedoch denke ich nicht dass es sich nicht auf dem Rechner installieren ließe
    Unsere Jugend ist unerträglich, unverantwortlich und entsetzlich anzusehen! - Aristoteles

    Comment


    • #3
      Zum Probieren mit Remote Debugging nutze ich jetzt Visual Studio 2008 Pro 90-Day-Trial. Ich habe eine Netzwerkverbindung zwischen Entwickler-PC und Embedded-Gerät.

      Auf dem Embedded-Gerät existiert nur ein Benutzer. Der ist Administrator. Er startet msvsmon.exe und konfiguriert
      [ ] Windows Authentication
      [v] No Authentication (native only)
      und
      [v] Allow any user to debug


      Auf dem Entwickler-PC stelle ich unter
      Projekteigenschaften -> Debuggen -> Arbeitsverzeichnis
      und
      Projekteigenschaften -> Debuggen -> [v] Remotecomputer verwenden
      und
      Projekteigenschaften -> Erstellen -> Ausgabepfad
      die entsprechenden Parameter ein.


      F6 bewirkt das Erstellen des Programms im gewünschten Zielverzeichnis auf dem Embedded-Gerät.

      F5 erstellt ebenfalls wie gewünscht. Das anschließende Debuggen schlägt allerdings fehl mit der Meldung "Fehler beim Ausführen des Projekts: Das Debuggen kann nicht gestartet werden. Anmeldung fehlgeschlagen: unbekannter Benutzername oder falsches Kennwort."


      Ich kann auf dem Embedded-Gerät das Programm starten und auf dem Entwickler-PC
      Debuggen -> an den Prozess anhängen
      wählen.
      In diesem Fall erscheinen Breakpoints nicht als rote Punkte, sondern als Kreise mit einem kleinen gelben Warnschild und der Meldung "Der Haltepunkt wird momentan nicht erreicht. Für dieses Dokument wurden keine Symbole geladen."


      Was ist die korrekte Vorgehensweise für das Remote Debugging?

      Comment


      • #4
        Die oben genannte Konfiguration funktionierte nicht. Offenbar ist es grundsätzlich so, dass .NET in Bezug auf Remote Debugging anders behandelt wird als C++.

        Ich muss also das Embedded-Gerät konfigurieren als
        [v] Windows Authentication
        [ ] No Authentication (native only)
        und
        [ ] Allow any user to debug

        Auf dem Entwickler-PC stelle ich unter
        Projekteigenschaften -> Debuggen -> Arbeitsverzeichnis
        und
        Projekteigenschaften -> Debuggen -> [v] Remotecomputer verwenden: MeinBenutzerName@Embedded-Gerätename
        und
        Projekteigenschaften -> Erstellen -> Ausgabepfad
        die entsprechenden Parameter ein.

        Ich habe auf dem Embedded-Gerät einen Benutzer (Computeradministrator) angelegt, der den selben Namen hat, wie mein Benutzer auf dem Entwickler-PC.

        F6 bewirkt das Erstellen des Programms im gewünschten Zielverzeichnis auf dem Embedded-Gerät.

        F5 erstellt ebenfalls wie gewünscht.
        Der Debugging Monitor auf dem Embedded-Gerät verlautet "Datum Uhrzeit Embedded-Gerätename\MeinBenutzerName connected."

        Das anschließende Debuggen schlägt allerdings fehl mit der Meldung "Fehler beim Ausführen des Projekts: Das Debuggen kann nicht gestartet werden. Visual Studio Remote Debugger auf dem Zielcomputer kann keine Verbindung mit diesem Computer herstellen. Fehler bei der Authentifizierung. Weitere Informationen finden Sie in der Hilfe."

        Der letzte Satz stimmt leider nicht. Die Information mag in der Hilfe stehen, aber gefunden habe ich sie nicht.

        Sowohl auf dem Entwickler-PC als auch auf dem Embedded-Gerät gibt es Freigaben, die der jeweils andere geöffnet hat. Seit Benutzername und Passwörter identisch sind, werden sie beim ersten Öffnen nach einem Neustart auch nicht mehr abgefragt.


        Wie bekomme ich den Remote-Debugger nun zum Laufen?

        Comment


        • #5
          gelöst

          Nachdem ich nun in den Einstellungen von Visual Studio alle Remote-Pfade vom Netzlaufwerk Z:\... auf die IP-Adresse 192.168... umgestellt habe, scheint tatsächlich der Debugger zu arbeiten.

          Natürlich gibt es auch gleich wieder ein Problem. Weil das aber thematisch nicht mehr in diesen Thread passt, gibt es einen neuen:
          Originally posted by luker View Post
          Debuggen auf dem Netzwerk - wie SecurityException verhindern?

          Comment


          • #6
            Welches Framework benutzt du auf dem XP Embedded System? Wenn es nicht 3.5SP1 ist solltest du das mal installieren. Dort wurde die Security bezüglich starten aus dem Netz gelockert. So wie du das beschreibst könnte das auch beim debuggen helfen.

            Wenn das nicht möglich ist musst du dem debuggenden User die notwendigen Rechte geben. Stichworte 'Caspol.exe' und 'Fulltrust'.

            Comment

            Working...
            X