InstallAware

I agree with John and ohali's comments completely. I am in the middle of my first installer that requires the .Net framework and was extremely disappointed at the amount of work I needed to do my self. Possible, Yes. Painless, not even close.

I understand that you can have the defaults work in every case. Unfortunately InstallAware seems blind to the fact that the current way you are supporting "everything" really means you do not support anything. You talk about "GLOBAL LOGIC" like you have it now - you don't.

I told my team that installing the .Net Runtime would be easy because InstallAware had built in support for it. Now several days later I am still not done. In addition my application is a Visual Studio Tools for Office (VSTO) add-in. Yep you guessed it, no built in support for that runtime. I *almost* would have been better off using Visual Studio to install my addin because real built in support for the runtimes exists.

Everytime I come look for answers in this forum and find "it's easy, just write your own script". It is *not* easy - typing in the script is the easy part. Figuring out all the steps involved and testing it in the different situations is very involved and time consuming. The required lines of script may be minimal, but the time I just invested to find out that it didn't work in the first place, why it didn't work, and how to make it work was not minimal. I expect that work to already be done by the vendor I selected for the "out of the box" support for the .Net runtime.

giaviv wrote: I apologize for the inconvenience, but there is a plethora of runtimes out there and obviously adding support for them all would be a ridiculously long task.

giaviv - Here let me help you out with that

giaviv wrote: Please note that creating additional runtimes is a very easy task - here is a tutorial on how to do so:
http://www.installaware.com/installawar ... s_view.pdf

- Mark Elder

Mark,

Your derogatory tone toward InstallAware, as well as your frustration, simply stem from YOUR lack of motivation.
You expect everything to work and to be tailored specifically to your needs, however you have to realize that that is simply not possible in the real world.
If we had to support EVERY single runtime there we would be devoting our entire time to writing runtimes as there are tens of thousands of those.
So instead, not only that we created a good amount of common runtimes, but we also designed InstallAware to allow you to add runtimes PAINLESSLY.
When I first joined InstallAware, my first task was to create a runtime. It took me no longer than half an hour, and I have been able to create runtimes to my desire since.
MSIcode is intuitive, and though it requires learning, there are plenty of tutorials and white-papers explaining how to use it. And once you master it, you can do many things that are not possible otherwise.
Furthermore, your sarcasm is ridiculous and simply incorrect. I suggest you read the tutorials and white-papers that are relevant to what you are trying to do before you get frustrated for not being able to do anything.

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=4498

I 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…

Mark,

Thank you for your comments. In fact, we are going to use your bullet points to create white-papers that answer your specific questions.
Regarding your step 11, yes, you have a way to help. When bitness is also introduced, it seems
to be impossible to generalize runtime installations. Situational and runtime particulars do not
seem to be possible to abstract away into a general solution like the one we developed with the
Include Script and the runtime mechanism, because some 32 bit runtimes are required as prereqs
for 64 bit runtimes, some 32 bit runtimes are allowed to co-exist with 64 bit runtimes but not required,
and some 32 bit runtimes are disallowed with only 64 bit runtimes permitted on the premises.
Given this very broad spectrum, and the impossibility of determining what the setup developer really needs
when checking a 32 bit or 64 bit runtime (are they saying they need any one bitness, or a very specific bitness of it?),
you can help us by describing how you would envision a single checkbox taking care of this all, regardless of the correct runtime bitness.
You need to cut the sarcasm, and yes, we are listening, and improving our documentation.

Giaviv,

I can understand where things can get complicated. I would suggest the following.

In cases where there is really only one install that works - i.e. You are forced to run the x86 or x64 msi to match the OS then just do that. I can't think of a case where I would need to know - at least not as far as the runtime is concerned. You could still have three entires in the list (x86 only, x64 only, Auto Detect x86 or x64). But honestly I think you could just have the Auto Detect version. If my code only runs on one platform I will check that up front in the install. For example if my code only runs on 64 bit I will check the 64 bit Operating System on the Application Requirements page. In that case we will never get to the Prereqs check when running on a 32 bit system. The fact that it *would* have installed the 32 bit runtimes had the install made it that far does not hurt anything. If you really felt you needed the extra step you could use your "options" dialog to let users pick "Install only 32 bit", or "Install only 64 bit".

Consider what I consider to be the typical case today. I am developing 32 bit applications that run just fine in 32 bit mode with a 64 bit OS. If I want to install the .Net Runtime I can take the bad example from Microsoft and create two versions of my install. One for 32 bit and one for 64 bit with just different runtimes checked. Otherwise I am forced to immediately start writing custom MSI code to make sure the checks work correctly. If I check just the 32 bit option I will not run on 64 bit and the same is true in reverse. If I check both (which I originally thought I could) then I will not run on either system. This is what I was talking about when I said you don't have Global Logic today. Don't let a "global logic" requirement stop you from creating a runtime install that is better then your current one.

I'm guessing - going out on a limb here. That part of your problem with an "Auto Detect" type of runtime install option is all of your web media blocks are setup in the main script. That probably makes it hard to create an auto detect install script that only downloads the one correct install instead of both. In my case I have been defining the Web Media blocks in the second script, but that does confuse the "visual" part of the IDE - those blocks are not visible. If that is the case I hope you can find a solution. That internal problem does not change my needs for building installs.

For other runtimes I have noticed a trend where a difference in the bits may cause the installer to be split but the 64 bit version will install both the 32 and 64 bit parts. The SQL Native Client seems to work this way. In that case install the 64 bit version when possible. Other than maybe complaining about the download size I don't know any developers that would care in that case. As long as the correct runtimes end up on the system so my program runs I don't care about installing both 32 and 64 bit versions.

---

giaviv wrote: Given this very broad spectrum, and the impossibility of determining what the setup developer really needs
when checking a 32 bit or 64 bit runtime (are they saying they need any one bitness, or a very specific bitness of it?),

Take a poll. I would bet even money that 10 time as many developers need "any bitness". We don't care, we just want our programs to run. I don't want to become an expert on the various ins and outs of the .Net Runtime. I just want it to be present. You seem to be treating each option with equal weight. Make the standard, typical case (which in my opinion is "any bitness") work out of the box and just tell the guys that need something off the wall to create their own MSI Code script.

---

Part of the frustration is with lack of good documentation from Microsoft or other vendors on their runtime requirements. You guys keep referring back to your MIS Code documentation. That is nice but that is not where I want you to stop. I expect you to be experts on Install Issues. I know you can't support every runtime. For example I don't expect to see BDE (the Borland Database Engine) listed. But I really expect one click support for the .Net framework that matches everywhere my exe or dll will run - which is both 32 and 64 bit.

In other cases if you look at the options and still feel you can't build a runtime share what you learned somewhere - on a forum, or in a whitepaper. I'm not just talking about the generic steps. Knowing what decisions made it too complicated to build a standard runtime will help anyone that needs to create one anyway. For example if you know what registry entry to check and see if X is present then say that when answering questions instead of just pointing users to the generic Run Time guide.

---

If you are taking my steps in the previous post for a document here is one I forgot - Checking the return value. VSTO really causes some pain since it is not a MSI. What return values can I expect from the exe. Again I could not find documentation from Microsoft. I choose to fail if I get anything other than zero back. But that is just a guess, I really don't know.

Thank you for your comments Mark. They will be taken into account.

This is a great thread. I agree with ops comments and I am very impressed that vendor listened.

What is missing from this thread is a solution.
I am currently trying to deploy a VSTO solution. I tried it w/ the VS installer and couldnt get it to work.
I searched install tools and found installAware. It looks great...

The VSTO runtime is an exe, not an MSI....
I have all the same issues addressed at length here.

Is there an example file I could start with?

Thanks