Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Laufzeitfehler: "Zugriff auf Netzwerkadresse..."


8 replies to this topic

JuergenBlatz

JuergenBlatz
  • Members
  • 8 posts

Posted 30 April 2003 - 14:35

Nach dem ich das Projekt nun komplett unter dem Developer 8.1 fehlerfrei übersetzen konnte,
kommt nun der Fehler sad.gif

Installerinformationen:
"Zugriff auf die Netzwerkadresse false war nicht möglich"

Dieser Fehler kommt nach dem Aufstarten der zusammengebauten Installation,
nach dem der Installer die Tabellen scheinbar geladen hat. Leider habe ich
keinerlei konkreten Anhaltspunkt, wie ich diese Fehlermeldung umgehen
könnte.

Das Projekt konnte schon einmal mit dem Developer 8.0 gebunden und
fehlerfrei installiert werden. Ich habe nun etliche Änderungen vorgenommen
und bekomme jetzt den Fehler.

Vielen Dank für jede Hilfe
Jürgen Blatz

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 30 April 2003 - 19:33

Ich vermutle einen falsch eingetragenen Shell-Folder in der Registry. MSI liest nämlich zu Beginn alle Shell-Folder auf dem Zielcomputer aus und überprüft sie auf Gültigkeit.
Alternativ könnte es auch ein Fehler in der Directory Tabelle des Setups sein.
Tritt der Fehler auf einem frishcen Betriebssystem auf? Auch auf unterschiedlichen Betriebssystemen? Was steht im Install-Log?

JuergenBlatz

JuergenBlatz
  • Members
  • 8 posts

Posted 07 May 2003 - 08:07

Danke für die Info.

Im Installations-Log stehen die gleichen Meldungen mit der Kennung 1606. Dies führte mich dann
auch zu der Support-Info von InstallShield Q107104, in der die ähnliche Info wie die von Stefan
Krueger stand.

Um es aber abzukürzen. Diese Tips helfen definitiv nichts. Nach wirklich 3 Tagen harter Arbeit stellt
sich für mich folgendes Bild:

* Evt, aber wirklich nur evt. kommt das Problem daher, dass wir in verschiedenen Kompoenten
teilweise gleichnamige Dateinamen haben, die JETZT IM DEVELOPER IN DER FILE-TABELLE
nicht immer eine neue Kennung bekommen. D.h., es kann sein dass die Datei A.TXT zweimal
in der Datei-Tabelle mit der gleichen Kennung steht. Dies passiert definitiv nur dann, wenn mit
der aktuellen Developer 8.1 Version (German) diese Dateien ganz normal in die Komponente
dazuaddiert werden (über Hinzufügen).

* Das gravierenste Problem ist aber, dass wenn der Fehler 1606 auftritt, die Projektdatei
DEFINITIV KAPUTT IST!!!
Es hilft wirklich nichts mehr. Ich kann alles zurückbauen, der Fehler tritt nach dem ersten
Mal IMMER auf. Er ist in einer bestehenden Projektdatei durch nichts mehr zu eliminieren.

Ich konnte den Fehler erst wieder umgehen, in dem ich auf einen ca. 4 Tage alten Stand
wieder aufgesetzt habe. Dazu habe ich alle (auch unfertigen Stände) übersetzt, bis
der Fehler nicht mehr auftritt.

Jetzt arbeite ich ständig mit vielen Sicherungen. Der Fehler tritt nämlich trotzdem immer
wieder (z.B. heute morgen) nach weiteren Anpassungen einfach auf. Und ab dann
ist die Arbeitsdatei nicht mehr zu gebrauchen, und ich muss auf der vorherigen Sicherung
wieder aufsetzen!

Insgesamt ist der Developer 8.1. mehr als instabil. Ich werde dazu einen gesonderten Top
aufnehmen. Zumindestens setzen wir seit der Version 8.1 auch das Language Package EAST
ein, da wir auch eine russische Installation benötigen. Diese funktioniert nicht, und der
Support von InstallShield hat bis heute uns nur mit Standard-Mails abgespeist (teilweise
die gleichen, bereits beantworteten Fragen) in der nächsten Standard-Mail erneut gestellt.
Eine englische Installation funktioniert seit der Version 8.1. überhaupt nicht mehr. Die
InstallShield-Dateien für die englische Version werden nicht installiert, egal wie oft man
Englisch (GB) als Sprache dazuinstalliert.

Unsere InstallShield Installation ist in der Zwischenzeit komplett neu installiert auf einen
neuen Rechner:
8.1 + LanguagePack West + Language Pack EAST

Dies ist der momentane, eher frustrierende Stand. Ich bin gerade am Überlegen, da das
Projekt überfällig ist, ob ich wieder auf die Version ISWI2.01 zurückgehe!!!


JuergenBlatz

JuergenBlatz
  • Members
  • 8 posts

Posted 07 May 2003 - 08:09

Beim Durchlesen ist mir folgendes aufgefallen:

Die Fehler in der File-Tabelle habe ich natürlich korrigiert, so dass keine gleichen
Namen mehr vorhanden sind.

Nur um entsprechende Nachfragen vorzubeugen.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 07 May 2003 - 08:23

Hast du die MSI-Datei mal validieren lassen? Um festzustellen, ob noch weitere Inkonstistenzen drin sind?

Wenn die Ursache gefunden ist, kann man evtl. die Projektdatei reparieren, denn man kann sie mit Orca öffnen und bearbeiten (ism verwendet das gleiche Dateiformat wie msi)

In der Logdatei solltest du sehen können, bis zu welchem Shell-Folder das Setup kommt.

JuergenBlatz

JuergenBlatz
  • Members
  • 8 posts

Posted 07 May 2003 - 09:02

Ja, ich validiere die Daten ab und zu.
Da wir eine äusserst komplexe Installation haben, kommt es zu einigen Fehlern, die sich leider
nicht beheben lassen.

Wir haben einen Konstrukt, für den ich sonst (und das Forum hier auch) keine andere Lösung
weis, als eine (fehlerhafte) mehrfache Installation unserer Programmdatei.

Unsere Programmdatei wird je nach Funktionsweise mit unterschiedlichen Parametern
installiert (auch mehrfach), die über einen Dialog eingestellt werden können.
Daher haben wir auf dem Desktop und im Startmenü bis zu 8 Einträge, die die
gleiche EXE starten, aber mit unterschiedlichen Parmetern. Um dies zu realisieren,
habe ich je Shortcut eine Komponente, die immer die gleiche EXE startet, aber mit
unterschiedlichen Parametern.

Um dies zu verdeutlichen, ein fiktives Beispiel:
Z.B. für ein Malprogramm, wird unsere EXE mit dem Parameter /malen aufgerufen.
Für ein Schreibprogramm mit /schreiben.
Hat ein Kunde nun beide Module gekauft, so hat er zwei Shortcuts auf das gleiche
Programm, einmal mit /malen und einmal mit /schreiben.

Diese Konstellation mag der Developer (und ISWI) überhaupt nicht, und melden etliche
Fehler, dass die gleiche EXE durch zig verschiedene Komponenten installiert wird.
Dies ist richtig und funktioniert bisher auch immer.

Das Problem ergibt sich daraus, das abhängig von einer Einstellung ein Shortcut
erzeugt werden soll oder nicht. Das geht nur über verschiedene Komponenten,
die die jeweilige Logik tragen (soweit ich weis).

Ansonsten meldet die Validierung nichts auffälliges - leider!

Die Log-Datei hat NUR zwei Einträge mit 1606 und der bekannten Fehlermeldung,
ohne weitere Angaben.
Ein setup /Verbose.... schreibt gar nichts in die LOG-Datei, da der Fehler
bereits vor dem Ablauf der eigentlichen Installation auftritt.

Der Fehler tritt unabhängig auf den verschiedensten Rechnern absolut
gleich auf. Hat also nichts mit lokalen Shell-Foldern zu tun, die aber
trotzdem alle (soweit ersichtlich) richtig gesetzt sind.

JuergenBlatz

JuergenBlatz
  • Members
  • 8 posts

Posted 07 May 2003 - 09:56

Die Log-Datei enthält genau folgende Infos:

Fehler 1606. Zugriff auf die Netzwerkadresse false war nicht möglich.
Fehler 1606. Zugriff auf die Netzwerkadresse false war nicht möglich.
=== Protokollierung beendet: 07.05.2003 10:50:09 ===

Leider ist der Fehler jetzt wieder aufgetreten, scheint also wirklich an
irgend welchen weiteren internen Problemen liegen.

Wie kann ich eine genauere Protokolldatei erstellen?


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 08 May 2003 - 08:17

Die ausführlichste Log-Datei bekommt man über den Registry-Eintrag (incl. Debug-Einstellung). Siehe http://www.msifaq.de unter "Laufzeitfehler".

Bei den Shortcuts ist wohl das Problem, dass jede Komponente nicht nur den Shortcut enthält, sondern auch das EXE. Könntest du nicht Komponenten nur mit Shortcuts anlegen? (Die wären dann allerdings non-advertised, d.h. sie unterstützen kein Repair)

Andernfalls könnte man die MSI-Richtlinien dadurch erfüllen, dass die EXE in jeder Komponente unterschiedliche Namen verwendet, also etwa
malen.exe /malen
anstatt
programm.exe /malen


JuergenBlatz

JuergenBlatz
  • Members
  • 8 posts

Posted 08 May 2003 - 09:50

Hallo Stefan,

vielen Dank für die Hilfe.

Ich habe den Kern des Problemes jetzt bereits gestern abend gefunden.

Ich habe eine neue Programmversion namens 'LOGIC'. Dazu gibt es eine interne Eigenschaft names
LOGIC, die über einen Dialog gesteuert wird. Als Voreinstellung wird LOGIC im Eigenschaften-Manager
auf false gesetzt.

Spezifische Dateien werden über die Installation teilweise in einen Pfad installiert, der als letzte
Directory ebenfalls ....\logic besitzt. Dieser Pfad wird intern anscheinend in der Eigenschaft LOGIC
zwischengespeichert, was mir Debug-Ausgaben bestätigt haben. Dadurch habe ich die Pfadvariable
durch meine Vordefinition auf 'false' gesetzt, was zu dem gemeldeten Fehler geführt hat.

Jetzt habe ich auf jeden Fall etwas dazugelernt. Man darf keine Eigenschaft verwenden, die
gleichlautend wie irgendeine Pfadendung der Installation ist!


Zur Konstallation der Shortcuts:

Ich kann die EXE nicht einfach verschieden benamens, da ja genau dies der Trick ist, dass
die EXE beim Kunden nur EINMAL vorliegt. Unabhängig davon, wieviele unserer Teilprodukte
der Kunde gekauft hat. Das Programm handelt die Versionen dann intern über Lizensierungen
und beim Aufstarten durch den Parameter.
Das heisst, ich habe in der Installation (bei gepackter Installation) tatsächlich pro Shortcut
eine Kopie unseres Programmes. Nach der Installation hat der Kunde aber nur eine
Programmdatei vorliegen. Binde ich eine nicht gepackte Installation, so enthält diese
auch nur einmal die Programmdatei.

Komponenten nur mit Shortcuts haben im bisher verwendeten ISWI nicht funktioniert.
Beim Zusammenbau der neuen Installation ist mir auch aufgefallen, dass der Developer
dies anscheinend unterstützt. Jedoch habe ich auch Sicherheitsgründen, da mir die Ursache
des gemeldeten Fehlers nicht klar war, auch bei den neuen Komponenten die
Programmdatei mit eingebunden.

Da jetzt das Grundproblem behoben ist, werde ich letzteres noch einmal testen.

Nochmals vielen Dank,
und schöne Grüße aus Ulm
Jürgen Blatz