Hi Trent,

Just to let you know that the same problem still exist with 1.6.5 installer.    Please see image attached.

P.S.

If you fix this, please send me the link for the new installer so I can test it for you here.

Edhy Rijo

Hi Trent,

Since I am still having problem on my Vista 64bit dev computer, I decided to make a Cantasia video of the most recent SF installation file to show you the process.

I believe what is causing the problem is the location for the "Common Files" and the .NET program used to Configure StrataFrame - Phase 1 and 2 which may be compiled to AnyCPU instead of x86.

You will notice from the video that IA is copying the common files correctly to:

C:\Program Files (x86)\Common Files\MicroFour\StrataFrame

But the "Configure StrataFrame" program is looking at "C:\Program Files\Common Files\MicroFour\StrataFrame" which is the defaut for 64bit OS and of course generated all kind of error since the files are not there.

I know this has been a long battle with the installation and I hope you can see the problem now.

If I am still wrong, when you have a chance, please take a look at the video to see if you can find what could be causing this problem.   www.progytech.com/videos/SF_Installation\SF_Installation.htm

Edhy Rijo

Yes, Edhy, it looks like not all of the processes are running x86.  Since Visual Studio 2008/2005 run in x86 mode, the files must be located within the C:\Program Files (x86)\ directory, or Visual Studio will not be able to locate any of the files.  At runtime, windows x64 will dynamically translate C:\Program Files\ into C:\Program Files (x86)\ (it will also translate the C:\Windows\System32\ into C:\Windows\syswow64\ and the HKLM\Software\ to HKLM\Wow64Node).  So, since the OS is translating the paths, everything will run fine if the install program thinks it's installed/running under x86.  I believe we have our install DLL that contains the installer classes compiled in x86, but it could be the case that the x64 process of the InstallAware program is calling it within the x64 process, so the paths aren't being translated. 

When you run the install, could you do me a favor and when you get the error, use the TaskManager and tell me whether the following processes have *32 after the process names (indicating that the process is running 32-bit):

setup.exe
msiexe.exe
installutil.exe

and anything else that looks like it might be spawing as part of the setup program.  Thanks.

Hi Ben,

Thanks for jump in.

Here are the list of files which are related to the SF Installation:

• StrataFrameInstaller.exe *32
• StrataFrameSetup.exe *.32
• StrataFrameSetup_1.6.5.3.exe *32 (This is the posted file which I renamed to keep track of beta versions).

I also sent you a PM with a SystemCheckLog.htm file.

Edhy Rijo

Sorry, could not sent you the PM or email with the SystemCheckLog.htm file.  If you still need it, let me know so I can post it here then.

Edhy Rijo

Hrm... we're going to have to get our 64-bit virtual machine up and running and test the install.  With the install running in 32-bit, everything should be working.

Sure, there is not rush, I am able to complete the installation by copying the file to the Common Files folder.

Edhy Rijo

Sorry for jumping in but it installs okay on my 64-bit Vista Ultimate. I do have problems with permissions with the Licence Activation wizard as it must be run as administrator to work. However, other than that the SF installation routine runs correctly without elevated permissions on my system.

Aaron

Hi Aaron,

Yeah, same thing happen with Doron's main computer, it is Vista Ultimate 64bit and it installed there just fine.

In my case there is a problem with choosing the right "Common Files" folder location at some point as I tested in my video, just by copying the files from one "Common Files" to the other one and re-run the installation everything will install perfectly, the problem is that I would need to keep doing that all the time, and it gets to a point of frustration when you are updating and get stock and have to do that all over again .

Edhy Rijo

This is actually a simple fix...and something did change between the last build and this build.  We converted the installer class into an executable, which is not being forced to run as x86 (32-bit).  When we do the next build I will force this change.  Thanks.