I had actually submitted a support ticket on this. I was told this would be fixed in Version 7 and is not.
When I was a pretty green IA user I was having a common problem that many others have had with files COM objects not regsitering properly. Since I had quite a few custom DLL's and OCX's I used the Import from feature to add the registry information and I used it for pretty much all of my COM Objects.
The result of doing this caused build times to take hours and not minutes and then the Installation would appear to hang with Windows installer message being displayed in the Progresstext for 20 minutes or longer.
My original workaround was to do part of the install in InstallShield and part in IA, because InstallShields registration mechanism never fails.
Since the Registration problem is file specific (still don't know why) I have since nailed down the problem files and am using Import just on them and the self-register on the others, so I can now create an entire acceptable installer in IA.
The thing about the Import option is I know it will always work not matter what.
The reason why InstallShield's does not fail is when you build the project it is actually using it's own Import routine and doing it when the project is being built. When the product is installed is not using the self-registration option, but writing the data on it's own. In IA you have to Import and the Edit all of this information file by file and then it greatly reduces the Installations performance in the IDE and built executable.
Just a note, Wise has the same problem registering these files and so does InstallWizard XP. The WiX based installers I have tried (Setup Factory for one) does not have the problem.
It's pretty hard for me to understand why writing registry entries would bog down a program as much as it does in IA.
...as I said before, I am an old Wise Script fan, because it did not lock me up in a box and I could become real creative with it. When I moved to the Windows Installer, Installations locked me in a box and Installs were not fun any more. IA put the fun back in it. Just would like to see this problem get fixed and few other tweaks and suggestions made in some earlier threads and IA would basically have no competition.
http://www.installaware.com/forum/viewtopic.php?t=2722
Problem in 6 persits in 7
-
- Posts: 36
- Joined: Tue Aug 07, 2007 11:25 am
Registering COM classes
It sounds like you are having a problem similar to one I asked about in another post recently. I'm having problems with Register Assembly in Server 2003 R2 which I need because all my .NET DLLs are Active-X controls which need to be registered for COM Interop.
I have a one self-registering DLL written in C++ and I think that one registers OK. It's just the .NET stuff that doesn't work. Even calling regasm instead of using Register Assembly still doesn't work. And no errors get logged anywhere that I can find.
Is there something fundamentally broken in IA? Or am I doing something stupid?
I have a one self-registering DLL written in C++ and I think that one registers OK. It's just the .NET stuff that doesn't work. Even calling regasm instead of using Register Assembly still doesn't work. And no errors get logged anywhere that I can find.
Is there something fundamentally broken in IA? Or am I doing something stupid?
It is broke
There is something fundamentally broke in IA. I paid for a support incident on it and was told, yes it is a problem but will be fixed in 7. It was passed up the chain. Wasn't fixed and haven't heard anything else on it.
...
I have become a big IA fan after using it for a bit now, but this issue does kind of get my cookie, because I paid money for a support incident and it really has never been handled. I did get offered a deal to update to IA7 because of the lack of response and fix - because it is a true IA bug, but then it came to bare my update was free anyway because my original purchase was within the 3 month time frame, so I basically spent the money for nothing.
Similar Bug Found/Solved
I had a similar problem in IA 7 r2 (that was not present in previous releases) where the install script would hang indefinitely at the "Windows Installer" message...
In my case, this bug occurs when you attempt to assign the value of a variable to itself.
i.e.:
COMMANDVAR = $COMMANDVAR$
~InstallAware Clipboard Data~
~Set Variable~
~{E43F84AF-D543-474E-8D7E-C93E15D97D11}~
~COMMANDVAR$MYAH$MYAH$FALSE~
~$COMMANDVAR$~
Not a particularly intelligent thing to do in code, but completely valid.
The back-story is that when I was first composing this script, I was trying (unsuccessfully) to pass IA command line parameters to set variables. I later backed out of this, but this line was left in tact from my experiments. The script only started to manifest this bug in 7.0r2 - it had been fine in 6.x and 7.0.
I'm passing this along to other IA users via this forum, since I have found reading other's messages and responses quite helpful. (IA Support was unable to isolate the problem on their own; nor were they able to provide a licensed copy of 7.0 (without r2) for me to use in the meanwhile.)
-Ed Lecuyer
Build/Release Engineer
Maptech, inc.
In my case, this bug occurs when you attempt to assign the value of a variable to itself.
i.e.:
COMMANDVAR = $COMMANDVAR$
~InstallAware Clipboard Data~
~Set Variable~
~{E43F84AF-D543-474E-8D7E-C93E15D97D11}~
~COMMANDVAR$MYAH$MYAH$FALSE~
~$COMMANDVAR$~
Not a particularly intelligent thing to do in code, but completely valid.
The back-story is that when I was first composing this script, I was trying (unsuccessfully) to pass IA command line parameters to set variables. I later backed out of this, but this line was left in tact from my experiments. The script only started to manifest this bug in 7.0r2 - it had been fine in 6.x and 7.0.
I'm passing this along to other IA users via this forum, since I have found reading other's messages and responses quite helpful. (IA Support was unable to isolate the problem on their own; nor were they able to provide a licensed copy of 7.0 (without r2) for me to use in the meanwhile.)
-Ed Lecuyer
Build/Release Engineer
Maptech, inc.
Last edited by elecuyer on Thu Apr 24, 2008 11:14 am, edited 1 time in total.
...
Actually r2 has solved the issue I was having, by using some of there optimization settings.
I do have an occassional problem with builds freezing up, but deleting the temp files and starting the build over solves it.
I do have a copy of all prior builds of IA since I first got it v6 something or other. Not sure if I would be violating any rules by letting someone download them?
I do have an occassional problem with builds freezing up, but deleting the temp files and starting the build over solves it.
I do have a copy of all prior builds of IA since I first got it v6 something or other. Not sure if I would be violating any rules by letting someone download them?
I do have a copy of all prior builds of IA since I first got it v6 something or other. Not sure if I would be violating any rules by letting someone download them?
The problem with prior builds of IA is not lack of the actual download files (I have those, too) - the issue is:
1. Knowing the password for each download (They have changed over the years)
2. Having the "License File" for that download. A 7.0r2 license file will not work on 7.0 or 6.x. Moreover, IA support claims that they have no possible way of generating older license files. Thus, you need to keep those around too, otherwise you'll end up with an unlicensed copy.
In the process of debugging my issue, I did reverse engineer the IA licensing scheme and created an "unsupported" work-around. Rather than publish that here, anyone reading this is welcome to contact me back-channel and I can explain how to rollback from 7.0r2 to 7.0.
Register Library Problem
I was having a problem with register library that many here seem to have encountered and came up with a simple (if baffling) solution. I was trying to use the built-in "register library" command; when the script got to that point, I would hear an error chime, but see no error message, and the installation would effectively be hung.
I noticed that regsvr32, when run directly, cannot handle long file names. I tried shortening the TargetDir, just to test whether Register Library would work; it didn't make any difference.
Then, out of desperation, I tried wrapping $TARGETDIR$ in double quotes;
Register Library "$TARGETDIR"\\myapp.dll
Unbelievably, that immediately solved the problem. Still testing, but so far, I've had no more problems.
I noticed that regsvr32, when run directly, cannot handle long file names. I tried shortening the TargetDir, just to test whether Register Library would work; it didn't make any difference.
Then, out of desperation, I tried wrapping $TARGETDIR$ in double quotes;
Register Library "$TARGETDIR"\\myapp.dll
Unbelievably, that immediately solved the problem. Still testing, but so far, I've had no more problems.
Who is online
Users browsing this forum: No registered users and 97 guests