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

Directory does not exist and can not be created!


Best Answer deramor , 19 August 2014 - 15:22

After talking with installshield support, they inform me this is a known defect in 2014.

http://flexerasoftwa...PROBLEM/Q210255

I am working with them to understand how this registry key gets written. It would appear that my 2010 projects are writing this key while the 2014 projects are having an error with the key. Go to the full post


11 replies to this topic

deramor

deramor
  • Full Members
  • 187 posts

Posted 14 August 2014 - 16:20

I have this weird error message.

 

ISError.png

 

It unfortunately happens during install startup and before logging is started so my debug options are limited.  Does anyone have any ideas?  I did validation on my project but that didn't turn up anything.



Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 14 August 2014 - 22:14

Is this your own setup? Or is it a third party setup? Try to flush all messages to a log file and check what log entries are actually written:

msiexec.exe /i C:\Path\Your.msi /L*v! C:\Your.log

Further details here: http://www.installsi...ifaq/a/1022.htm


Edited by Glytzhkof, 14 August 2014 - 22:14.

Regards
-Stein Åsmul

deramor

deramor
  • Full Members
  • 187 posts

Posted 14 August 2014 - 22:34

It is my setup.  It is a InstallScript MSI project type which means I must use the /verbose flag to generate a log.  This error happens before this log is created.



Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 15 August 2014 - 16:23

Maybe there is an error in the Directory table, but it really could be anything. Without a log file there isn't much to go on. Are you launching the setup with full admin rights?


Regards
-Stein Åsmul

deramor

deramor
  • Full Members
  • 187 posts

Posted 15 August 2014 - 16:32

Yes full admin rights.  Also as I mentioned, I ran validation.  I was looking for something to pop up in the directory table and didn't see anything.

 

I currently have a ticket open with installshield.  This is just one vector of support for me.  Do you know of any other debugging methods I could try?  I did run ProcMon and having it watch the setup process to see if I found some disk file access going on.  That early in the install process is almost exclusively registry reads.

 

To add onto this problem, I just finished a brand new Installscript MSI project for another project and it too displayed this pop-up.  I think this is environment related but without knowing what it is, I can't tell if a customer will see it.  On 3 computers this was tried with, 2 of them show the pop-up.  Any suggestions for debug options are welcome.



Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 16 August 2014 - 01:03

Sorry if this seems out of place, but I would strongly recommend that you ditch the Installscript MSI project type - it is very buggy. Though this may seem extreme, there are many good reasons to do so (the following thread discusses it, and it is 3 pages long): http://forum.install...?showtopic=8734

 

Here is another thread on the same topic in a more condensed, summary form: http://forum.install...showtopic=19783


Edited by Glytzhkof, 16 August 2014 - 12:45.

Regards
-Stein Åsmul

deramor

deramor
  • Full Members
  • 187 posts

Posted 16 August 2014 - 17:17

I usually use basic msi however in one case there is legacy concerns I must consider which forced me into the project type. In the other, there are limitations of basic msi that installscript msi can get around.

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 16 August 2014 - 19:33

The only limitation that I can think of for Basic MSI is with regards to the GUI, and using some C++ code you will be able to create spawned dialogs to enter the information you need into your setup. See a short example here: http://www.robertdic...tips.html#spawn . I have never used this particular code, but did write a feature to open a standard windows dialog from a Basic MSI dialog years ago. I had some dialog update issues going back to the Basic MSI dialog, but as I recall I managed to fix this using some window activation code.

 

More on MSI custom action dll coding: http://www.codeproje...stom-Action-DLL

 

What I would do would be to decompile your existing MSI using dark.exe from the Wix toolkit, and rewrite the MSI after cleaning out all the custom Installshield stuff. Then I would write a small C++ launcher application that would gather whatever data is necessary for your application using full-featured Windows dialogs, and then kick off the installer silently with a command line sending data to msiexec.exe via command line:

 

msiexec.exe /I "C:\Install.msi" /QN /L*V "C:\msilog.log" STARTAPP=1 APPLYRULE=1 RULE="Long string here"

 

Or you can kick it of via Win32 API calls or DTF as described here: http://serverfault.c...i/596519#596519

 

Here is an OK quick start project for Wix:

  1. http://www.codeproje...-installer-with
  2. http://stackoverflow...allers-from-wix
  3. A Wix quick start suggesting from me on stackoverflow.com

I am only suggesting this because I know for a fact that as long as you keep using Installscript MSI you will face new and serious problems along the line of what you are seeing already.


Edited by Glytzhkof, 16 August 2014 - 23:03.

Regards
-Stein Åsmul

deramor

deramor
  • Full Members
  • 187 posts

Posted 17 August 2014 - 01:09

One very specific use case that Installscript MSI allows me to perform is to script one or many other installations along with the main install.

 

In my case, I sequence one or more different installers during install and one or more during uninstall.  This works during install since the setup.exe has an administrator manifest embedded in it.  Since all the child installs require admin rights to install this is fine.  However on uninstall, a basic MSI project does not save the setup.exe and therefor the admin manifest is not available.  During uninstall, the child products do not launch from lack of privilege.  The Basic MSI will elevate during the execution sequence.  However only 1 install can be active during this time.

 

The writing of a c++ custom action does present a curious solution.

 

Would the custom dll be able to elevate even without the admin manifest? 

 

Could you request a rights token from the dll and make it seem like it was coming from the parent installer? 

 

Further, would this prompt only be presented once? 

 

Suppose I had 3 child products to remove.  Would the elevation during the execution of the first uninstall be carried over to the second and third using different custom actions?  Taken a step further, would any elevation be carried to the parent install so the total number of UAC prompts be 1?

 

As far as the original problem, I feel more and more that the pop-up is dependent on the environment.  On 4 pcs this was executed on, only 2 of them showed this pop-up.



Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 17 August 2014 - 01:52

Wix has features to handle multiple setups via its Burn framework - essentially a launcher for several setups. I have regrettably not used this feature so far.

 

Is the central issue being able to uninstall everything as a bundle? You could write your own bootstrapper installer / uninstaller application with a manifest along the lines of the Visual Studio installer and then hide all MSI packages from ARP (add / remove programs). Then you can handle uninstall via this application, and it can uninstall the setups in the sequence you require. You will need to register this bootstrapper application to launch from ARP for uninstall operations - I have never done this, but it shouldn't be too hard to achieve.


Regards
-Stein Åsmul

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 19 August 2014 - 08:29

Is your setup packaged in a single, self extracting setup.exe? Where is the extraction path set? Looks like something is trying to write to "C" instead of "C:\" or a sub folder (write access to the root folder may be restricted). In any case, Process Monitor should show the write attempt.

BTW I've never seen this error message and it looks a bit unusual (the actual error text in the head of the message box). Could this be something custom? Or a prerequisite?



deramor

deramor
  • Full Members
  • 187 posts

Posted 19 August 2014 - 15:22   Best Answer

After talking with installshield support, they inform me this is a known defect in 2014.

http://flexerasoftwa...PROBLEM/Q210255

I am working with them to understand how this registry key gets written. It would appear that my 2010 projects are writing this key while the 2014 projects are having an error with the key.