Problembehandlung bei Setup- und Bereitstellungsprojekten

In den Themen dieses Abschnitts werden verschiedene Probleme behandelt, die beim Erstellen von Bereitstellungsprojekten und beim Bereitstellen von Anwendungen auftreten können.

Die für das Setupprojekt erforderliche .NET Framework-Version stimmt nicht mit der .NET Framework-Version überein, auf die die Anwendung abzielt.

Setupprojekte verfügen über eine Startbedingung, mit der überprüft werden kann, ob eine bestimmte Version von .NET Framework installiert ist. Diese Version stimmt jedoch u. U. nicht mit der erforderlichen .NET Framework überein, die von der Anwendung verwendet wird. Beispiel: Die Anwendung zielt auf .NET Framework 2.0, ab, aber von der Startbedingung im Setupprojekt wird nach .NET Framework 3.5 gesucht und diese Version installiert. Ein weiteres Beispiel: Eine Visual Studio-Projektvorlage zielt auf .NET Framework 4 Client Profile ab, aber von der Startbedingung des Setupprojekts wird nach .NET Framework 4 gesucht und diese Version installiert.

Zum Ändern dieses standardmäßig festgelegten Verhaltens führen Sie folgende Schritte aus:

  1. Klicken Sie im Projektmappen-Explorer auf das Setupprojekt.

  2. Zeigen Sie im Menü Ansicht auf Editor, und klicken Sie anschließend auf Startbedingungen.

  3. Klicken Sie auf .NET Framework.

  4. Tragen Sie im Eigenschaftenfenster in die Eigenschaft Version die Version von .NET Framework ein, nach der vom Setupprojekt gesucht werden soll und die installiert werden soll.

Stellen Sie auch sicher, dass vom Programm "Setup.exe" überprüft wird, ob die richtige Version von .NET Framework installiert ist und dass ggf. die richtige Version vom Programm installiert wird. Weitere Informationen finden Sie unter Dialogfeld "Erforderliche Komponenten" und Gewusst wie: Installieren von erforderlichen Komponenten für die Windows Installer-Bereitstellung.

.NET Framework 3.5 SP1 kann nicht unter Windows Server 2008 R2 oder Windows 7 installiert werden

Sie können Setup-Projekte mit .NET Framework 3.5 SP1 als erforderliche Komponente konfigurieren. Beim Installieren dieser erforderlichen Komponente auf einem Computer mit Windows Server 2008 R2 oder Windows 7 wird jedoch die folgende Fehlermeldung angezeigt: "Die Installation oder Konfiguration von .NET Framework 3.5 SP1 muss mithilfe des Rollenverwaltungstools erfolgen". Windows Server 2008 R2 enthält .NET Framework 3.5 SP1 als optionale Komponente des Betriebssystems, diese Komponente ist jedoch standardmäßig deaktiviert. Weitere Informationen finden Sie unter Welche Version von .NET ist in Windows integriert?

Um diesen Fehler zu umgehen, ändern Sie das .NET Framework 3.5 SP1-Bootstrapperpaket.

  1. Erstellen Sie ein ausführbares Programm, das die Befehlszeile "ocsetup Netfx3" ausführt.

  2. Navigieren Sie zum Ordner %Programme (x86)%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX35SP1.

  3. Kopieren Sie das ausführbare Programm in den Ordner DotNetFX35SP1.

  4. Navigieren Sie zum Ordner en, und öffnen Sie die Datei package.xml mit Administratorberechtigungen.

  5. Fügen Sie im <Commands>-Abschnitt ein <Command>-Element hinzu, um das Programm auszuführen.

Fehler bei Verwendung des Microsoft Visual Studio-Hilfsprogramms für die Registrierungsaufzeichnung unter Windows 7

Wenn Sie das Microsoft Visual Studio-Hilfsprogramm für die Registrierungsaufzeichnung (regcap.exe) auf einem Computer mit Windows 7 verwenden, wird möglicherweise die folgende Fehlermeldung angezeigt: "Microsoft Visual Studio registry capture utility funktioniert nicht mehr". Das Installationsprogrammprojekt wird möglicherweise erstellt, die DLL wird jedoch später nicht installiert.

Um diesen Fehler zu umgehen, führen Sie folgende Schritte aus:

  1. Navigieren Sie zu %Programme (x86)%\Microsoft Visual Studio 10.0\Common7\Tools\Deployment.

  2. Klicken Sie mit der rechten Maustaste auf regcap.exe, und klicken Sie dann auf Eigenschaften.

  3. Klicken Sie auf Kompatibilität.

  4. Aktivieren Sie das Kontrollkästchen unter Kompatibilitätsmodus.

In Visual C++-Setup-Projekten werden Abhängigkeiten nicht erkannt

Wenn Sie einer Visual C++-Projektmappe ein Setup-Projekt hinzufügen und der Name des Ordnerpfads Leerzeichen enthält, werden die Abhängigkeiten in der Visual C++-Projektmappe nicht erkannt. Um das Problem zu umgehen, entfernen Sie die Leerzeichen im Ordnerpfad des Projekts, oder fügen Sie die Abhängigkeiten manuell hinzu. Benennen Sie beispielsweise Dokumente\Visual Studio 2010\Projekte in Dokumente\VisualStudio2010\Projekte um.

Setupprojekte können in Visual Studio nicht mit Quellcodeverwaltung erstellt werden.

Bei der Erstellung von Setupprojekten in Visual Studio 2008 erhalten Sie möglicherweise Fehlermeldungen, z. B. "Der Befehl kann nicht ausgeführt werden, da sich die Datei "filename.vdproj" unter der Quellcodeverwaltung befindet und nicht ausgecheckt werden kann.". Dateien werden von Setupprojekten nicht automatisch aus der Quellcodeverwaltung ausgecheckt.

Unterstützte Betriebssysteme

Der Visual Studio-Bootstrapper und das Visual Studio-Installationsprogramm (Setupprojekte) werden nicht auf Windows Server 2008 Server Core oder Windows Server 2008 R2 Server Core unterstützt, die eine Serverumgebung mit niedriger Wartungsstufe und beschränkter Funktionalität bereitstellen. Zum Beispiel unterstützt die Server Core-Installationsoption nur das .NET Framework 3.5 Server Core-Profil. Visual Studio-Funktionen, die vom vollständigen .NET Framework abhängen, können also nicht ausgeführt werden. Weitere Informationen finden Sie unter Server Core.

Verwaltete benutzerdefinierte Aktionen können nicht installiert werden.

Wenn Sie eine verwaltete benutzerdefinierte Aktion installieren, erhalten Sie möglicherweise eine Fehlermeldung, dass die Datei ".installstate" nicht vorhanden ist. Dies tritt auf, wenn von der verwalteten benutzerdefinierten Aktion die Installationsaktion nicht implementiert wird. Die Datei ".installstate" wird von der Installationsaktion erstellt und von den anderen Aktionen aktualisiert.

Implementieren Sie die Install-, Uninstall-, Commit- und Rollback-Aktionen in die benutzerdefinierte Aktion, um diesen Fehler zu umgehen.

Die Language Packs von .NET Framework 3.5 SP1 können nicht für ein Gebietsschema installiert werden, wenn von Visual Studio 2008 ein anderes Gebietsschema verwendet wird.

Wenn Sie .NET Framework 3.5 SP1 als erforderliche Komponente für Setupprojekte auswählen, wird von Visual Studio kein Bootstrapper oder Setupprogramm zur Installation eines Language Packs für ein anderes Gebietsschema erstellt. Wenn Sie z. B. eine nicht japanische Version von Visual Studio verwenden, wird vom Setupprojekt das japanische Language Pack von .NET Framework 3.5 SP1 nicht eingeschlossen.

Erstellen Sie unter "%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX35SP1" ein neues Verzeichnis mit der Bezeichnung "ja", um diesen Fehler zu umgehen und eine verteilbare Datei in japanischer Sprache für .NET Framework 3.5 SP1 zu erstellen. Das Verzeichnis "ja" muss die Dateien "eula.rtf" und "package.xml" enthalten.

Ist .NET Framework 3.5 SP1 bereits installiert, können keine Language Packs installiert werden.

Sind die zentralen Komponenten von .NET Framework 3.5 SP1 bereits auf dem Computer installiert, können die Language Packs von .NET Framework 3.5 SP1 nicht installiert werden. Ist auf einem Computer z. B. .NET Framework 3.5 SP1 bereits installiert, kann das japanische Language Pack von .NET Framework 3.5 SP1 nicht als erforderliche Komponente in einem anderen Anwendungsinstallationsprogramm installiert werden.

Erstellen Sie ein Bootstrapperpaket für die Language Packs, um das Problem zu umgehen. Fügen Sie im Bootstrapperpaket eine Abhängigkeit von .NET Framework 3.5 SP1 hinzu, damit die Language Packs nur installiert werden, wenn die zentralen Komponenten von .NET Framework bereits installiert sind. Alternativ können Sie die Language Packs manuell installieren.

Verwaltete benutzerdefinierte 64-Bit-Aktionen lösen eine System.BadImageFormatException-Ausnahme aus.

Wenn Sie einem Setupprojekt eine verwaltete benutzerdefinierte 64-Bit-Aktion hinzufügen, wird vom Visual Studio-Buildprozess eine 32-Bit-Version von "InstallUtilLib.dll" als InstallUtil in das MSI eingebettet. In der 32-Bit-Version von .NET Framework wird dann eine verwaltete benutzerdefinierte 64-Bit-Aktion ausgeführt und eine BadImageFormatExceptionAusnahme verursacht.

Ersetzen Sie die 32-Bit-Version von InstallUtilLib.dll durch die 64-Bit-Version, um das Problem zu umgehen.

  1. Öffnen Sie die resultierende MSI-Datei in Orca (Windows Installer-SDK).

  2. Wählen Sie die binäre Tabelle aus.

  3. Doppelklicken Sie auf die Zelle [Binäre Daten] für den Datensatz "InstallUtil".

  4. Stellen Sie sicher, dass die Option zum Lesen der binären Daten aus dem Dateinamen ausgewählt ist, und klicken Sie auf die Schaltfläche "Durchsuchen".

  5. Navigieren Sie zu "%WINDIR%\Microsoft.NET\Framework64\v2.0.50727".

    Tipp

    Das Verzeichnis "Framework64" ist nur auf 64-Bit-Plattformen installiert und für 64-Bit-Prozessoren erforderlich.

  6. Wählen Sie die Datei "InstallUtilLib.dll" aus.

  7. Klicken Sie auf die Schaltfläche "Öffnen".

  8. Klicken Sie auf die Schaltfläche "OK".

Weitere Informationen erhalten Sie unter 64-bit Managed Custom Actions with Visual Studio.

Erstellen eines Pfads für benutzerdefinierte Dialogfelder mit Textfeldern

Wenn Sie ein benutzerdefiniertes Dialogfeld mit einem Textfeld erstellen, muss das Dialogfeld "Installationsordner" nach dem benutzerdefinierten Dialogfeld platziert werden. Anschließend wird der Verzeichniswert automatisch weitergegeben. Wird die Reihenfolge des Dialogfelds und des Dialogfelds "Installationsordner" umgekehrt, muss der Verzeichniswert manuell weitergegeben werden.

Im Ausgabefenster treten zusätzliche Buildfehler auf.

Tritt ein bestimmter Buildfehler auf, werden möglicherweise auch generische Fehlermeldungen, wie "Allgemeiner Fehler beim Erstellen des Bootstrapper" oder "Nicht behebbarer Buildfehler", ausgegeben. Ignorieren Sie die generischen Fehlermeldungen, und beheben Sie den speziellen Fehler.

Zuvor ausgeschlossene Dateien werden beim erneuten Öffnen der Lösung wieder eingeschlossen.

Wenn Sie eine Datei aus einem Setupprojekt ausschließen, wird die Datei nach dem Schließen und erneuten Öffnen möglicherweise wieder in die Lösung eingeschlossen. Dies kann auftreten, wenn sich zwei Kopien der gleichen DLL-Datei an zwei unterschiedlichen Quellspeicherorten befinden.

Ändern Sie die Eigenschaft Lokale Kopie für eine der beiden Dateien, um diesen Fehler zu umgehen:

  1. Klicken Sie im Projektmappen-Explorer auf den DLL-Verweis, der entfernt werden soll.

  2. Klicken Sie im Menü Ansicht auf Eigenschaftenfenster.

  3. Ändern Sie die Eigenschaft Lokale Kopie in "False".

Für Setupprojekte wir die Fehlermeldung "Für diesen Vorgang ist nicht genügend Speicher verfügbar" ausgegeben.

Wenn Sie einem Setupprojekt große Dateien hinzufügen, tritt, selbst wenn auf der lokalen Festplatte genügend freier Speicherplatz zur Verfügung steht, bei der Erstellung des Setupprojekts folgender Fehler auf: "Für diesen Vorgang ist nicht genügend Speicher verfügbar". Während des Buildprozesses wird möglicherweise auch der Bedarf an virtuellem Speicher erhöht.

Rüsten Sie den Arbeitsspeicher des Buildcomputers auf, um diesen Fehler zu umgehen, oder versuchen Sie diese Problemumgehung:

  1. Fügen Sie im Projekt eine Datei hinzu, die den gleichen Namen wie die große Datei trägt.

  2. Legen Sie auf der Seite für die Projekteigenschaften für das Installationsprogramm die Option für das Paket mit losen dekomprimierten Dateien fest.

  3. Erstellen Sie das Projekt.

  4. Kopieren Sie die großen Dateien an den Buildspeicherort.

Geänderte Dateien werden vom Setupprojekt nicht aktualisiert.

Selbst wenn das Setupprojekt für die Entfernung von früheren Dateiversionen konfiguriert wurde, werden von Windows Installer keine Dateien ersetzt, die geändert oder vom Benutzer ersetzt wurden. Weitere Informationen erhalten Sie unter Neither File Has a Version with File Hash Check (Keine Datei weist eine Version mit Dateihashüberprüfung auf).

Für die Prüfung auf .NET Framework 3.5 SP1 kann keine Startbedingung verwendet werden.

Die erforderliche Erkennung von .NET Framework 3.5 SP1 wird in Nur-MSI-Szenarios nicht unterstützt. Stattdessen müssen Sie den Setup.exe-Bootstrapper für die Versionsprüfung und die Installation von .NET Framework 3.5 SP1 konfigurieren. Weitere Informationen finden Sie unter Dialogfeld "Erforderliche Komponenten".

So erstellen Sie einen 64-Bit-Bootstrapper, der .NET Framework einschließt

Wird .NET Framework 3.0 als erforderliche Komponente in den Bootstrapper eingeschlossen und der Setup.exe-Bootstrapper auf einem 64-Bit-Computer installiert, wird eine Fehlermeldung ausgegeben, die anzeigt, dass 64-Bit-Betriebssysteme nicht unterstützt werden.

Von .NET Framework 3.5 werden 32-Bit- und 64-Bit-Betriebssysteme unterstützt. Wenn die Anwendung sowohl auf 32-Bit- als auch auf 64-Bit-Betriebssysteme abzielt, wählen Sie im Dialogfeld "Erforderliche Komponenten" die Option ".NET Framework 3.5" aus. Weitere Informationen finden Sie unter Dialogfeld "Erforderliche Komponenten".

Wie installiere ich die Bootstrapperpakete für SQL 2008 und .NET Framework 3.5 SP1?

Die Bootstrapperpakete für SQL 2008 und .NET Framework 3.5 SP1 werden mit den Visual Studio Express-Editionen auf dem Entwicklungscomputer installiert. In Visual Studio 2010 sind SQL 2008 und die .NET Framework 3.5 SP1-Bootstrapperpakete bereits enthalten, und diese Problemumgehung ist nicht erforderlich.

Ein umgekehrter Schrägstrich im Textfeld verursacht einen Ausnahmefehler (ungültiges Verzeichnis oder ungültige URL).

Wenn für die benutzerdefinierte Aktion die Eingabe eines Pfads für einen Installationsordner erforderlich ist, wird möglicherweise eine ArgumentException-Fehlermeldung ausgegeben. Dies hängt möglicherweise mit einem ungültigen Verzeichnis oder einer ungültigen URL zusammen.

Ersetzen Sie den umgekehrten Schrägstrich in der Eigenschaft Edit1 und dem Textfeld Edit1Value durch ein Leerzeichen, um den Fehler zu umgehen: /name="[TARGETDIR]". Analysieren Sie dann den Wert, und erstellen Sie einen voll qualifizierten Pfad mithilfe der Combine-Methode.

Einer Fehlermeldung in einem Setupprojekt kann kein Zeilenumbruch (\n) hinzugefügt werden.

Wenn Sie eine Fehlermeldung in ein Setupprojekt schreiben, kann das Zeilenumbruchzeichen nicht im Setupprojekt oder mit Orca.exe hinzugefügt werden. Stattdessen können Sie es mit der Windows Installer-API in einer Postbuildaktion mit dem folgenden Befehl hinzufügen: "INSERT INTO `Property` (`Property`, `Value`) VALUES 'ERRORMESSAGELINES', 'first\r\nnext\r\nlast')". Weitere Informationen zum Verwenden einer Postbuildaktion finden Sie unter http://go.microsoft.com/fwlink/? LinkId=150770.

.NET Framework 2.0 SP1 oder .NET Framework 3.0 SP1 kann nicht im Dialogfeld "Erforderliche Komponenten" ausgewählt werden.

Im Dialogfeld "Erforderliche Komponenten" wird .NET Framework 2.0 SP1 oder .NET Framework 3.0 SP1 nicht in der Liste der Anwendungen für die Installation angezeigt, wenn diese nicht bereits installiert sind. Diese sind als eigenständige verteilbare Datei nicht verfügbar. Damit sie als erforderliche Komponenten auf Endbenutzercomputern installiert werden, wählen Sie im Dialogfeld "Erforderliche Komponenten" .NET Framework 3.5 aus. Weitere Informationen finden Sie unter Dialogfeld "Erforderliche Komponenten".

Befehlszeilenparameter werden mit dem Standardwert im Textfeld überschrieben.

Wenn Sie das Installationsprogramm mit dem \qb-Flag ausführen und in Befehlszeilenparameter zur Festlegung von Eigenschaften in einem Benutzerdialogfeld übergeben, werden diese Parameter möglicherweise überschrieben. Ändern Sie die MSI-Datei mit der Datei "Orca.exe", damit der Standardwert einer Eigenschaft nicht mehr von Kunden überschrieben wird.

  1. Legen Sie den Eingabefeldwert im Dialogfeld auf seinen Eigenschaftennamen fest. Legen Sie die Edit1Value-Eigenschaft z. B. auf [EDITB1] fest.

  2. Erstellen Sie die MSI-Datei in Visual Studio.

  3. Bearbeiten Sie die MSI-Datei mit ORCA, und tragen Sie den Standardwert der Eigenschaft in die Eigenschaftentabelle ein.

  4. Speichern Sie die MSI-Datei.

Sie können diese Änderung auch mithilfe einer Postbuildaktion vornehmen. Weitere Informationen zum Verwenden einer Postbuildaktion finden Sie unter http://go.microsoft.com/fwlink/?LinkId=150770.

Assembly-Abhängigkeiten wurden nicht erkannt

Wenn eine Projektausgabegruppe, eine Assembly oder ein Mergemodul zu einem Bereitstellungsprojekt hinzugefügt wird, werden alle abhängigen Assemblys automatisch erkannt und dem Projekt hinzugefügt. Es empfiehlt sich, eine Projektausgabegruppe mit einer Assembly hinzuzufügen, da die Bereitstellungstools leichter Abhängigkeiten für eine Projektausgabegruppe ermitteln können.

Wenn eine abhängige Assembly zur Laufzeit unter Verwendung des Codes geladen wird, kann sie nicht von den Bereitstellungstools erkannt werden. Sie sollten möglichst keine Assemblys aus dem Code laden, oder fügen Sie abhängige Assemblys manuell zum Bereitstellungsprojekt hinzu. In der folgenden Tabelle sind Probleme, bei denen Abhängigkeiten nicht erkannt werden, und ihre Lösungen aufgeführt.

Abhängigkeitsproblem

Lösung

Das Projekt verweist auf eine Komponente, die nur als Teil eines anderen Produkts installiert sein sollte.

  • Schließen Sie die Komponente vom Bereitstellungsprojekt aus.

  • Fügen Sie eine Startbedingung hinzu, um auf dem Zielcomputer nach der Komponente zu suchen. Wird die Komponente nicht gefunden, halten Sie die Installation an.

Das Projekt verweist auf eine nicht verwaltete Komponente, die nicht alle ihre Abhängigkeiten verfügbar macht.

Das Projekt verweist auf eine Assembly, die über eine Abhängigkeit zu einer nicht verwalteten Komponente verfügt.

Wenn eine MFC-Anwendung auf einem Computer installiert wird, dessen Gebietsschema nicht Englisch ist, wird sie nicht lokalisiert.

Beim Bereitstellen einer MFC-Anwendung mithilfe eines Visual Studio-Bereitstellungsprojekts werden Abhängigkeiten für die lokalisierten Mergemodule Mfc_loc_e.msm und Mfc_loc_fe.msm nicht erkannt. Die Mergemodule sind in Visual C++ enthalten. Der standardmäßige Installationspfad lautet "\Programme\Gemeinsame Dateien\Merge Modules". Wenn Sie eine lokalisierte MFC-Anwendung weitergeben möchten, müssen Sie die zwei Mergemodule manuell zum Bereitstellungsprojekt hinzufügen.

Dateien können nach der Installation auf einem Webserver nicht gefunden werden

Beim Installieren eines Websetups auf einem Webserver wird durch die VirtualDirectory-Eigenschaft für den Web Application-Ordner und alle Web Custom-Ordner festgelegt, wo in diesen Ordnern befindliche Dateien relativ zum Webstammverzeichnis installiert werden. Wenn diese Eigenschaft leer gelassen wird, werden die Dateien im Webstammordner (inetpub\wwwroot) installiert. Weitere Informationen finden Sie unter VirtualDirectory-Eigenschaft.

Wie wird eine Webanwendung im Stammverzeichnis des Webservers installiert?

Standardmäßig werden beim Installieren einer Webanwendung mittels eines Websetup-Bereitstellungsprojekts Dateien direkt unterhalb des Webstammordners in einem Ordner installiert, der den gleichen Namen wie das Bereitstellungsprojekt hat. Die VirtualDirectory-Eigenschaft des Ordners Web Application bestimmt, wo die Dateien installiert werden. Zum Installieren in das Webstammverzeichnis müssen Sie die VirtualDirectory-Eigenschaft in null ändern (löschen Sie den Standardwert). Weitere Informationen finden Sie unter VirtualDirectory-Eigenschaft.

Wie deaktiviere ich die Abhängigkeitsanalyse?

Leider gibt es keine direkte Möglichkeit, das Suchen und Auflösen im Rahmen der Abhängigkeitsanalyse zu deaktivieren. Dieses Problem lässt sich aber folgendermaßen umgehen: Deaktivieren Sie im Dialogfeld, das durch Klicken auf die SearchPath-Eigenschaft angezeigt wird, die Option Standardsuchpfade einschließen.

Es müssen noch einige weitere Punkte beachtet werden:

  • Die Dateien müssen mit dem Befehl Datei hinzufügen hinzugefügt werden (klicken Sie im Menü Projekt auf Hinzufügen und dann auf Datei). Wenn Sie den Befehl Projektausgabe hinzufügen verwenden (klicken Sie im Menü Projekt auf Hinzufügen und dann auf Projektausgabe), werden aus dem Codeprojekt gemeldete Abhängigkeiten mit eingeschlossen.

  • Beim Erstellen werden möglicherweise eine oder mehrere Warnungen mit dem Inhalt Die Abhängigkeit konnte nicht gefunden werden angezeigt, die jedoch in diesem Fall ignoriert werden können.

  • Wenn Sie die Abhängigkeitsanalyse nur für einige Dateien deaktivieren möchten, können Sie diese Dateien einem Mergemodulprojekt mit deaktivierten Standardsuchpfaden hinzufügen. Verwenden Sie anschließend Mergemodul hinzufügen (klicken Sie im Menü Projekt auf Hinzufügen und dann auf Mergemodul hinzufügen), um die MSM-Datei in einem normalen Setup-Projekt mit aktivierten Standardsuchpfaden aufzunehmen.

Wie deaktiviere ich die Reparatur einer Datei, die von Benutzern geändert oder gelöscht werden soll?

Visual Studio erstellt angekündigte Verknüpfungen, sodass das Programm beim Start überprüft, ob alle Dateien vorhanden sind. Wenn dieses Verhalten so geändert werden soll, dass die Datei nicht repariert wird, wählen Sie die Dateien im Setup-Projekt aus, und ändern Sie die Condition-Eigenschaft in NOT REINSTALL, damit die Dateien bei einer Reparatur nicht neu installiert werden, und deren Transitive-Eigenschaft in TRUE, damit die Bedingung neu ausgewertet wird. Dies hat zur Folge, dass das Installationsprogramm nach dem erstmaligen Löschen der Datei kurz auf dem Bildschirm blinkt, während es überprüft, ob die Datei nicht neu installiert werden soll. Danach wird der Installer nicht mehr angezeigt.

Wie debugge ich eine benutzerdefinierte Aktions/Installer-Klasse?

Wählen Sie eine der folgenden Methoden:

  • Fügen Sie dem Code einen Aufruf von System.Diagnostics.Debugger.Launch hinzu. Diese Methode startet das Just-In-Time-Debuggen und ermöglicht das Anfügen eines neuen Debuggers an Ihren Code.

  • Fügen Sie dem Code einen Aufruf von MessageBox.Show("Debug Me") hinzu. Wenn das Meldungsfeld angezeigt wird, fügen Sie mithilfe von Visual Studio an den MessageBox-Prozess an. Fügen Sie dann break-Anweisungen (bei Visual C#-Projekten) bzw. stop-Anweisungen (bei Visual Basic-Projekten) im Code ein.

  • Legen Sie die Debugeinstellungen für den Start von %windir%\Microsoft fest. net\Framework\Version\InstallUtil.exe als externes Programm auf der Debug-Seite des Projekt-Designers. Der Name der benutzerdefinierten Aktionsassembly ist das Befehlszeilenargument. Wenn Sie F5 drücken, erreichen Sie den Haltepunkt. InstallUtil.exe führt die benutzerdefinierten Aktionen genauso wie MSI aus.

Das Registrieren von Assemblys mit COM-Schnittstellen funktioniert nicht

Dies ist ein bekannter Fehler in RegAsm. Wenn die Assembly eine Abhängigkeit (z. B. zu einer anderen Klassenbibliothek) besitzt, funktioniert RegisterCOM möglicherweise nicht, da zum Abrufen der Registrierungsinformationen RegAsm aufgerufen wird. Da RegAsm im Verzeichnis \obj aufgerufen wird, bleibt die Abhängigkeit unbemerkt, und RegAsm schlägt ohne Benachrichtigung fehl. Am besten umgehen Sie dieses Problem, indem Sie die Assembly manuell aus dem Verzeichnis \bin hinzufügen. Ein weitere Möglichkeit besteht in der Verwendung von RegisterSelfReg.

Außerdem müssen Sie sicherstellen, dass Sie die Registrierung manuell mit RegAsm/CodeBase ausführen. Wenn sich die Assembly nicht an einem freigegebenen Speicherort befindet, wird sie nur gefunden, wenn sie im gleichen Verzeichnis wie der aufrufende Code liegt. /CodeBase gibt das Verzeichnis in die Registrierung ein.

Wie behandle ich Probleme bei Windows Installer-Installationen mithilfe von Protokolldateien?

Windows Installer protokolliert seine Vorgänge beim Installieren von Programmen in einer Protokolldatei. Die Protokolldatei befindet sich im selben Verzeichnis wie die MSI-Datei.

Wie rufe ich eine Protokolldatei für die Installation ab?

Es gibt zwei Methoden:

  • Führen Sie in der Befehlszeile den folgenden Befehl mit dem Protokollierungsschalter aus:

    misexec /i mysetup.msi /l*v mylog.txt
    
  • Speichern Sie Folgendes in einer REG-Datei, und laden Sie diese in die Registrierung:

    REGEDIT4
    
    [HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer]
    "Logging"="voicewarmup"
    "Debug"=dword:00000007
    

    Öffnen Sie dann das \temp-Verzeichnis, und sortieren Sie nach Datum. Die aktuellste msi*.log-Datei stammt von der letzten Installation bzw. Deinstallation.

Wie installiere ich in ein Unterverzeichnis eines zuvor installierten Produkts?

  1. Nehmen wir an, dass das zuvor installierte Produkt (Product 1) installiert ist und über eine Datei mit dem Namen MyFile.txt verfügt.

  2. Verwenden Sie die Datei "Orca.exe" (aus dem Windows Installer-SDK), um die Dateitabelle anzuzeigen, und suchen Sie die Zeile, die "MyFile.txt" darstellt.

  3. Rufen Sie den Wert der Spalte Component_ ab, und öffnen Sie die Tabelle Component.

  4. Suchen Sie in der Tabelle Component die Zeile mit dem Wert Component_ in der Spalte Component, und rufen Sie ComponentID ab. Kopieren Sie diesen Wert in die Zwischenablage. Beenden Sie Orca.exe.

  5. Öffnen Sie in Ihrem Setup-Projekt den Editor für Startbedingungen, und fügen Sie eine Windows Installer-Komponentensuche hinzu. Fügen Sie für die ComponentID-Eigenschaft der neuen Suche die ComponentID ein.

  6. Kopieren Sie die Eigenschaft Eigenschaft. Diese sollte ungefähr so lauten: COMPONENTEXISTS1.

  7. Öffnen Sie den Dateisystem-Editor, und wählen Sie den Anwendungsordner aus.

  8. Bearbeiten Sie die DefaultLocation-Eigenschaft, sodass sie ungefähr [COMPONENTEXISTS1]MySubFolder entspricht (da der Pfad in COMPONENTEXISTS1 einen nachgestellten Schrägstrich '\' enthält).

Nach Schritt 6 in der vorherigen Vorgehensweise sollten Sie dem Editor für Startbedingungen eine Bedingung hinzufügen, um zu überprüfen, ob die Komponente gefunden wurde, und die Installation blockieren und eine Meldung anzeigen, wenn dies nicht der Fall ist. Die Bedingung würde COMPONENTEXISTS1 lauten (d. h. der Installer darf ausgeführt werden, wenn COMPONENTEXISTS1 nicht leer ist).

Wie installiere ich benutzerdefinierte Webordner an einem nicht standardmäßigen Anschluss?

Zum Installieren benutzerdefinierter Webordner an einem standardmäßig nicht dafür vorgesehenen Anschluss müssen Sie die Installation über die Befehlszeile ausführen. Der Befehl muss die Property-Eigenschaftswerte für jeden Ihrer Web Custom-Ordner enthalten. In der Regel liegt ein Wert wie NEWWEBPROPERTY1 vor. Außerdem müssen Sie TARGETPORT für den Webanwendungsordner mit einschließen.

Wenn sich der Webserver z. B. an Anschluss 20 befindet, sollte die Befehlszeile Folgendes enthalten:

msiexec /i mywebsetup.msi TARGETPORT=20 NEWWEBPROPERTY1PORT=20

Der vorherige Befehl dient nur für einen Webordner. Wenn Sie über mehrere Webordner verfügen, fügen Sie für jeden Ordner ein weiteres PROPERTY=VALUE-Paar hinzu, um den Anschluss jedes aufgelisteten Ordners an den angegebenen Anschluss umzuleiten.

Unter Umständen empfiehlt es sich, das Dialogfeld Installationsadresse zu entfernen: Wenn der Anschluss in der Benutzeroberfläche bei der Installation geändert wird, gilt für die benutzerdefinierten Webordner der Befehlszeilenwert.

Wie installiere ich in den Stamm einer Website?

Um in den Stamm einer Website zu installieren, z. B. c:\inetpub\wwwroot, legen Sie VirtualDirectory auf eine leere Zeichenfolge fest. Sie können dies im Websetup-Projekt oder während der Installation durchführen.

Wie installiere ich eine ServicedComponent in den GAC und konfiguriere sie im COM+-Katalog?

Wenn Sie versuchen, eine ServicedComponent in den globalen Assemblycache (GAC) zu installieren und sie im COM+-Katalog zu konfigurieren, kann der folgende Kompilierungsfehler auftreten:

"Unable to build custom action named 'Primary output from RegServer (Active)' because the file's Folder property is set to Global Assembly Cache."

Diese Installation wird nicht unterstützt, da beim Ausführen benutzerdefinierter Aktionen Assemblys im GAC nicht immer verfügbar sind (nicht an den GAC übergeben werden).

Dieses Problem lässt sich umgehen, indem Sie den Code in verschiedene Dateien ablegen und den benutzerdefinierten Code für die Aktion in einer Datei speichern, die nicht an den GAC übergeben wird. Manchmal können Sie den Code nicht auf diese Weise verteilen.

  1. Erstellen Sie im Verzeichnis des Setup-Projekts eine neue Uninstall.bat-Datei.

  2. Kopieren Sie im Setup-Projekt die ProductCode-Eigenschaft (einen Wert wie [12345678-1234-1234-1234-123412341234]).

  3. Bearbeiten Sie die Datei Uninstall.bat so, dass sie eine Zeile wie die folgende enthält (dabei ist Produktcode der Wert, den Sie in Schritt 2 kopiert haben):

    Msiexec /x Produktcode

  4. Fügen Sie Uninstall.bat zum Anwendungsordner des Setup-Projekts hinzu.

  5. Klicken Sie mit der rechten Maustaste auf Uninstall.bat, und wählen Sie Verknüpfung erstellen aus, um eine Verknüpfung zu erstellen.

  6. Legen Sie die Verknüpfung in den entsprechenden Startmenüordner des Setup-Projekts.

  7. Benennen Sie die Verknüpfung um, zum Beispiel in "<Anwendungsname> deinstallieren".

Wo finde ich Beispiele für das Verwenden von Setup-Projekten?

Beispiele für das Verwenden von Setup-Projekten finden Sie unter Aufgaben und exemplarische Vorgehensweisen für die Bereitstellung.

Wie plane ich die Bereitstellung von .NET Framework-basierten Anwendungen?

Dieses Handbuch enthält alle notwendigen Informationen zum Planen und Implementieren einer effektiven Bereitstellung von .NET Framework-basierten Anwendungen: Deploying .NET Framework-based Applications.

Wo kann ich das Windows Installer SDK herunterladen?

Sie können das Windows Installer-SDK im Microsoft Download Center herunterladen:

http://go.microsoft.com/fwlink/?LinkId=161393.

Wo finde ich Updates und Hilfeinformationen für Crystal Reports?

Aktualisierte Software und Mergemodule können Sie über die Seite "Downloads & Updates" auf der BusinessObjects.com-Website installieren:

https://websmp102.sap-ag.de/~sapidp/002006825000000234912001e

Wie löse ich "Nicht behebbarer Buildfehler"-Fehlermeldungen?

Wenn Sie beim Erstellen von Setup- oder Bereitstellungsprojekten eine Fehlermeldung zu einem nicht behebbaren Buildfehler erhalten, lesen Sie folgenden Artikel:

"PRB: 'Unrecoverable Build Error' Error Message When You Build Setup and Deployment Projects" unter http://support.microsoft.com/?id=329214.

Wie löse ich Validierungsfehlermeldungen?

Wenn Sie Fehlermeldungen wie An error occurred when validating. HRESULT = '80040155 erhalten, lesen Sie "PRB: "Unrecoverable Build Error" Error Message When You Build Setup and Deployment Projects" unter http://support.microsoft.com/?id=329214, und folgen Sie den Anweisungen unter "Missing Registrations".

So ändern Sie IIS bei der Bereitstellung mit benutzerdefinierten Aktionen

Der Artikel "Modifying Internet Information Services During Deployment with Custom Actions" unter http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchUsingCustomActionsToModifyInternetInformationServerDuringDeployment.asp?frame=true bietet Lösungsvorschläge für gängige Probleme. Hierzu gehören folgende Elemente:

  • So ändern Sie Einstellungen für IIS-Ordner, die für einen Webordner im Dateisystem-Editor nicht zur Verfügung stehen.

  • So stellen Sie eine Hybridanwendung bereit, von der sowohl Visual Basic 6 als auch Visual Basic .NET oder spätere Versionen verwendet werden.

  • Änderungen beim Bereitstellen von Anwendungen, die in Visual Studio .NET und später erstellt wurden, im Vergleich zu Visual Basic 6-Anwendungen.

Wie stelle ich ASP.NET-Anwendungen bereit?

Weitere Informationen über das Bereitstellen einer ASP.NET-Anwendung mit Visual Studio .NET finden Sie unter Deploying an ASP.NET App Using Visual Studio .NET.

Nach der Installation unter Windows 2000 schlägt die Ausführung der Anwendung mit der Warnung fehl, dass MDAC 2.8 erforderlich ist

Jede Anwendung, die auf den System.Data-Namespace verweist, ist von Microsoft Data Access Components (MDAC) 2.8 oder später abhängig. In den meisten Fällen ist die Datei bereits mit dem Betriebssystem installiert. Unter Windows 2000 Service Pack 3 und früher muss möglicherweise die Komponente gemeinsam mit der Anwendung installiert werden. Dazu wird sie dem Bootstrapperpaket hinzugefügt und die Datei während der Installation von Microsoft heruntergeladen. Weitere Informationen finden Sie unter Vorbedingungen für die Anwendungsbereitstellung.

Wie ändere ich die Berechtigungsstufe für die benutzerdefinierten Aktionen?

Standardmäßig werden benutzerdefinierte Aktionen mit SYSTEM-Rechten ausgeführt, aber möglicherweise erfordert die benutzerdefinierte Aktion mehr Rechte zur Ausführung der Aufgabe. Deaktivieren Sie das "noimpersonate"-Flag in der benutzerdefinierten Aktion, um dieses Standardverhalten zu ändern. Weitere Informationen finden Sie unter Custom Action In-Script Execution Options.

Verwandte Knowledge Base-Artikel

Die folgenden Knowledge Base-Artikel enthalten Informationen zu Problemen bei Windows Installer-Bereitstellungen:

Siehe auch

Referenz

VirtualDirectory-Eigenschaft

Weitere Ressourcen

Bereitstellen von Anwendungen und Komponenten

Aufgaben und exemplarische Vorgehensweisen für die Bereitstellung