Alright - I can't believe that I am going to invest time in this again but here I go.
My frustration stems from InstallAware being very close to being great on these issues but not quite getting it. That frustration is added to by support choosing to attack customers instead of listening to what we have to offer. Pardon me if I don't agree that my frustration comes from my laziness.
For readers who are finding this while evaluating InstallAware - Let me be clear - I have not found a better tool for producing MSI installs. Am I frustrated? - very much so, and I am even more disappointed in how InstallAware is treating this issue and those that bring it up. I have looked hard at moving to a different Install toolset but there is nothing else out there that meets my needs.
Giaviv - my only motivation for posting here is to try and help make InstallAware better. Was there sarcasm in my last post? Absolutely. I am not sure that justified you implying that I am lazy and stupid.
I have read the documentation, and I have built scripts for new runtimes. In fact I even posted one back to the forum for others to use 2 years ago.
http://www.installaware.com/forum/viewt ... f=4&t=4498I don’t expect InstallAware to have thousands of runtimes. But you are falling way short of what I expect out of the box. From the comments on this and other posts here I don’t think I am alone. I may be wrong in my expectations, but the ability to write MSI code is only a small piece of the runtime install puzzle. A bigger part is figuring out how to get the runtime installed correctly. For every runtime that InstallAware supports your entire user base gets the benefit of that expertise. I look to my vendors as being smarter than me their field. The issues regarding runtimes can be complex. Looking at the scripts you have are proof of that. There are items in the scripts that I would not have considered if I wrote them myself.
In my opinion your suggestion that building a new runtime only takes 30 minutes is not realistic for a production install. If you can really turn them out that fast then I suggest the following. Take half a week – 20 hours, and roll out the 40 most requested runtimes to the forum. You already have a button in the IDE that jumps to the forum with the caption “Download Runtimes”. My suggestion would be to start with .Net runtimes that will run on either a 32 or 64 bit machine, VSTO 4, and SQL Server Native Client 10 (again running on both 32 and 64 bit machines). Now I am personally using these, but I already have my installs running so the immediate benefit to me in minimal. However, I can’t believe that these are so rarely needed that they would not be used by other users.
The problems I have run into are not because of how hard or easy it is to write MSI code. It has to do with the quirks of the runtime itself. Take the VSTO runtime for example. Consider some of the steps I needed to take to get this runtime working correctly. Now some of the problems I ran into below were self-inflicted, but those still cause pain…
Step 1:
There is both a x86 and x64 version. Sometimes the Microsoft installs will run on both type of OSes, sometimes they don’t. In this case I needed to take a clean 32 bit and clean 64 bit virtual machine and run the installs in both locations to see what happens. My add-in eventually calls into a 32 bit native code dll so it will only run with 32 bit Office. I was not sure (and Microsoft documentation did not explain) if I could run the 32 bit VSTO runtime on a 64 bit OS. It turns out you can’t, you have to run the 64 bit runtime on a 64 bit OS even with 32 bit Office.
Step 2:
How do I determine if the VSTO is already installed. The VSTO runtimes are an exe, not an MSI. What is the best way to see if they are installed? Registry key, product code? I found several different posts each checking in a different way. Can’t find official documentation from Microsoft. How do I decide which one to use? Then the registry key I choose to check is under a branch that on 64 bit windows uses a WOW6432Node for 32 bit programs. Where do I need to look? Where will InstallAware’s CheckRegistry call end up looking? Are they the same?
Step 3:
Since the VSTO runtime is not an msi file are there different command line flags to run the install in silent mode? Are there other options that I need to consider? What happens if my install is run with silent flags and I don’t have a silent flag to pass to the runtime?
Step 4:
Revisit an old question of mine – Is it a problem to define Web Media blocks in scripts. In my SQL Native Client script I made the switch in the install script instead of the main script. I checked to see if there were any new posts on that. I needed to decide to keep my old method or my new method.
Step 5:
Figure out why my install is flat broke. Oh ya – don’t copy script files and just rename them. Variables have an internal GUID that will be left the same, and if you have both the original and copied script in the same install project bad stuff will happen. The fix is easy select the entire script, cut and then paste back in to regenerate new GUIDs. Do I really understand that right in the first place? But it seems to have fixed the problem.
Step 6:
Install still not running – I’m not getting the correct file location out of the file bag. That’s right, the result from the File Bag call need to be initialized to “” before the file bag call. OK so file bag is a plugin and variables need to be initialized before calling a plugin. Yes the documentation says that, but really you can’t let me know at compile time?
Step 7:
Re-add my other required runtimes - .Net 4 Client and XML 6. Run test install on a clean 64 bit machine.
Step 8:
Find out that the Runtimes in InstallAware are specific to the OS bitness. Really! There is no built in way to just check a box and have the .Net runtime installed? This must be a joke – there is no choice to make here, If I want the .Net runtime just install the correct version.
Step 9:
Jump out to the forums to see what I am missing. Find this post, add my 2 cents with a touch of sarcasm.
Step 10:
Get a response that tells me “your frustration, simply stem from YOUR lack of motivation”, “we also designed InstallAware to allow you to add runtimes PAINLESSLY.” , “my first task was to create a runtime. It took me no longer than half an hour”
Step 11:
Ponder the question: “Do I respond?” Will anyone listen? Do I have a chance to help make things better for all InstallAware users?
Step 12:
Well I guess if you took the time to read this far you know how I answered my question in step 11. Only time will tell if the effort to respond was worth it or not…