none
Installationspfad auslesen RRS feed

  • Frage

  • Guten Tag, 

    ich steh vor foldenden Problem.

    Ich muß ein Registration-Tool so bauen, das wenn auf den Button OK geklickt wird, das das Tool eine Verbindung zu einem Webservice aufbaut, dieser trägt Daten in eine Datenbank ein, generiert dann ein Zertifikat und eine Lizenzdatei in .txt. 

    Das Tool tut das alles auch, aber nicht wenn es aus der Installation heraus gestartet wird.

    Ich habe als letzten Prozess der Installation ein "Benutzer registrieren"-Formular eingefügt und an dieses mein Registration-Tool eingebunden.

    Wenn man nach der Installation dann darauf klickt, öffnet sich das Tool, die Daten werden eingetragen, die Verbindung zum Webservice klappt, ein Zertifikate wird erstellt und eine MessageBox bestätigt auch den Erfolg der Regisitrierung, jedoch wird kein Textfile erstellt und in dieses der Registrierungcode eingetragen.

    Wird das Tool erst nach der vollständigen Installation ausgefüht, dann klappt alles zu 100%.

    Mit

    string path = Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);

    habe ich herausgefunden, das das Tool nicht wie gewünscht aus dem Installationsordner heraus gestartet wird sondern aus einem Temp Ordner, in welchlen das Tool keine Schreibrechte hat und da auch nicht die Textdatei hinein soll.

    Hardcodet den Installationspfad einzutragen kann ich nicht machen, da ich von den Kunden nicht verlangen kann, den Pfad nicht zu ändern.

    Wie kann ich also vom Visual Studio bereit gestellten Installationsmodul ("Installationsordner") welches für den Installationspfad zuständig ist den gewählten Pfad auslesen?

    Im Vorraus schon mal vielen Dank.

    Mit freundlichen Grüßen

    Christian Hudetz-Valland

    Donnerstag, 23. Februar 2012 07:45

Antworten

  • Hallo Christian,

    wieso nimmst Du nicht den Pfad in der Umgebungsvariable %UserProfile% zum Ablegen der txt-Datei? Denn hier hat der User immer volle Rechte.

    Gruß

    Tu

    • Als Antwort markiert Huddry Sonntag, 26. Februar 2012 11:36
    Freitag, 24. Februar 2012 08:12
  • Hallo Christian,

    Du scheinst für dein Registrierungs-Tool eine benutzerdefinierte Aktion zu verwenden. In Visual Studio angelegte benutzerdefinierte Aktionen werden lt. Dokumentation nicht im Benutzer-, sondern im SYSTEM-Kontext ausgeführt (standardmäßig ist NoImpersonate auf true gesetzt). Selbst wenn der aktuell angemeldete Benutzer z.B. über Schreibrechte auf den Zielordner verfügt, würde eine Standard-Aktion möglicherweise also *nicht* über diese Rechte verfügen. Wenn auf dem Zielrechner zudem Dateivirtualisierung eingeschaltet ist, und der Zielordner virtualisiert wurde, würde die Datei gar nicht erst in den definierten Zielordner, sondern in ein temporäres Verzeichnis umgeleitet werden, was dem von dir geschilderten Szenario ziemlich nahe kommt.

    Falls das angemeldete Benutzerkonto über genügend Rechte für die Installation verfügt, könntest Du versuchen, NoImpersonate auf false zu setzen. Das geht leider nicht direkt aus Visual Studio, aber Du kannst das über das Aufrufen eines Skript im PostBuild-Ereignis erreichen (siehe Links weiter unten). Damit würde die benutzerdefinierte Aktion im Benutzerkontext ausgeführt werden.

    Dass entspricht aber nicht unbedingt den best practices. Normalerweise wird empfohlen (vor allem bei der Installation für alle Benutzer), benutzerdefinierte Daten erst beim ersten Programstart zu schreiben. Das bringt vor allem im Enterprise-Kontext viele Vorteile mit sich, z.B. kann man dann  - wie Tu das bereits empfahl - %userprofile%, bzw. - je nach Bedarf - Application.UserAppDataPath, Environment.SpecialFolder.ApplicationData, Environment.SpecialFolder.LocalApplicationData o.ä. bedenklos verwenden.

    Aaron Stebner - Mailbag: How to set the NoImpersonate flag for a custom action in Visual Studio 2005
    http://blogs.msdn.com/b/astebner/archive/2006/10/23/mailbag-how-to-set-the-noimpersonate-flag-for-a-custom-action-in-visual-studio-2005.aspx

    Custom Action In-Script Execution Options
    http://msdn.microsoft.com/de-de/library/aa368069.aspx

    Gruß
    Marcel

    • Als Antwort markiert Huddry Sonntag, 26. Februar 2012 11:36
    Freitag, 24. Februar 2012 09:59
    Moderator

Alle Antworten

  • Hallo Christian,

    wieso nimmst Du nicht den Pfad in der Umgebungsvariable %UserProfile% zum Ablegen der txt-Datei? Denn hier hat der User immer volle Rechte.

    Gruß

    Tu

    • Als Antwort markiert Huddry Sonntag, 26. Februar 2012 11:36
    Freitag, 24. Februar 2012 08:12
  • Hallo Christian,

    Du scheinst für dein Registrierungs-Tool eine benutzerdefinierte Aktion zu verwenden. In Visual Studio angelegte benutzerdefinierte Aktionen werden lt. Dokumentation nicht im Benutzer-, sondern im SYSTEM-Kontext ausgeführt (standardmäßig ist NoImpersonate auf true gesetzt). Selbst wenn der aktuell angemeldete Benutzer z.B. über Schreibrechte auf den Zielordner verfügt, würde eine Standard-Aktion möglicherweise also *nicht* über diese Rechte verfügen. Wenn auf dem Zielrechner zudem Dateivirtualisierung eingeschaltet ist, und der Zielordner virtualisiert wurde, würde die Datei gar nicht erst in den definierten Zielordner, sondern in ein temporäres Verzeichnis umgeleitet werden, was dem von dir geschilderten Szenario ziemlich nahe kommt.

    Falls das angemeldete Benutzerkonto über genügend Rechte für die Installation verfügt, könntest Du versuchen, NoImpersonate auf false zu setzen. Das geht leider nicht direkt aus Visual Studio, aber Du kannst das über das Aufrufen eines Skript im PostBuild-Ereignis erreichen (siehe Links weiter unten). Damit würde die benutzerdefinierte Aktion im Benutzerkontext ausgeführt werden.

    Dass entspricht aber nicht unbedingt den best practices. Normalerweise wird empfohlen (vor allem bei der Installation für alle Benutzer), benutzerdefinierte Daten erst beim ersten Programstart zu schreiben. Das bringt vor allem im Enterprise-Kontext viele Vorteile mit sich, z.B. kann man dann  - wie Tu das bereits empfahl - %userprofile%, bzw. - je nach Bedarf - Application.UserAppDataPath, Environment.SpecialFolder.ApplicationData, Environment.SpecialFolder.LocalApplicationData o.ä. bedenklos verwenden.

    Aaron Stebner - Mailbag: How to set the NoImpersonate flag for a custom action in Visual Studio 2005
    http://blogs.msdn.com/b/astebner/archive/2006/10/23/mailbag-how-to-set-the-noimpersonate-flag-for-a-custom-action-in-visual-studio-2005.aspx

    Custom Action In-Script Execution Options
    http://msdn.microsoft.com/de-de/library/aa368069.aspx

    Gruß
    Marcel

    • Als Antwort markiert Huddry Sonntag, 26. Februar 2012 11:36
    Freitag, 24. Februar 2012 09:59
    Moderator
  • Hallo,

    ich danke für die hilfreichen Antworten und hab das Problem umgangen, sodass ich ich mir den Installationspfad aus der Registry ausgelesen habe.

    Ich lass das Tool beim Starten in die Registry schreiben wo es sich befindet und so wird dann auch die Textdatei dorthin geschrieben. Oft sind die einfachsten Lösungen die, auf die man erst als letztes kommt. :)

    Das klappt hervorragend und mein Kunde ist sehr zufrieden.

    Gruß Christian

    Sonntag, 26. Februar 2012 11:41