Creating an Installer with Inno Setup tutorial now online

[kenkrupa]

Thanks guys. Fred, your suggestion of checking if the runtime is still installed seems like a worthwhile idea. But how to do that? I see that we could be looking for any one of several .arx files, depending on acad version and platform. And it wouldn't get loaded until the OPENDCL command either works or fails. I suppose I could use vl-cmdf instead of command, and then test for one of the odcl functions. Did you have something simpler in mind?

[Fred Tomke]

Hi, kenkrupa,

there are samples of trying to load the runtime in the OpenDCL samples folder (of OpenDCL Studio). If the runtime could not be loaded or has the wrong release, throw an alert.

You can also have a registry research after installing the runtime and check in your code if the registry entries and the runtime files exist (always stored at %COMMONPROGRAMFILES(x86)%\OpenDCL).
Search in the registry path of the running AutoCAD session if the command OpenDCL is already registered.
Please note, that it will not be registered if the AutoCAD release is installed AFTER your application. I have no experiences with the case of reinstalling AutoCAD. At your point I'd give it a try.

Regards,
Fred

[Fred Tomke]

Fred, just to clarify, I think that if an application installs the runtime via the app's own MSI (i.e. by using the OpenDCL Runtime MSM merge module instead of the standalone OpenDCL Runtime MSI), there will be no separate entry in Control Panel.

Owen, does it mean, that only if I use the MSM, the Runtime is not listet in the Control Panel? Installing the Runtime during an Inno Setup installer, the seperate entry will added to the software list. So at least we cannot avoid that runtime files are missing. That's why I mentioned it.
BTW, another question: What will happen if the customer installs an application using Inno Setup Installer after the app of mine which uses the MSM? Will the runtime be listet in the control panel then?

I only wanted to recommend to check the existence of OpenDCL runtime at AutoCAD startup, since there are many cases when the Runtime is not available (user depended deinstallation or deleting, install AutoCAD after runtime ...), that's why I trust nothing, I event don't trust me.

Regards,
Fred

[owenwengerd]

The best way to install the runtime is by using the merge module, because then it does not get listed separately in Control Panel, and because then it is guaranteed to remain installed as long as your app is installed. Just installing the MSI is a kludge for use in installers that do not support merge modules.

I want to challenge your statement that "there are many cases when the Runtime is not available". You have identified one scenario (the user uninstalling OpenDCL Runtime from Control Panel after your app is installed). The other scenario you mention will not occur if your app installer is designed and used correctly, because a new AutoCAD instance that is installed after the initial installation of your app should not be loading your app unless and until the app's installer has been executed (and therefore also updated the runtime installation). If, as you imply, this is a common situation, then I would be interested in hearing some real statistics: how many instances of missing runtime have your customers reported in the last 2 years? If a missing runtime is a real problem, I want to know why.

In any case, you are proposing to solve this problem by adding code and complicating the UI and localization of your application in order to notify the user when this situation is detected, instead of just letting AutoCAD or Windows alert the user to the problem. I can think of a hundred other (more likely) things that users could do on their system to break your app. Will you therefore also add code to detect and notify the user in those other hundred cases? If so, your app will consist primarily of code to detect and notify the user of problems. I don't think that's a good strategy. Users will break your app, and there is no way you can stop them, so design your app so that a simple repair will fix it and don't waste time tilting at windmills.

That, friends, is my installer rant for this month.

[kenkrupa]

Just installing the MSI is a kludge for use in installers that do not support merge modules.

I use Innosetup and have added the .msi per the tutorial. Are you saying this is really no good, and that I should be using a better installer? If so, what? Anything short of going to something expensive and/or much more complex?

[Fred Tomke]

That, friends, is my installer rant for this month.

Thanks Owen. As I already told I have no experiences in using the MSI and MSM. But I know like you that users sometimes are doing things that may harm the functionality. I think, it's a bit too optimistic not to check the existency of components at the beginning. And I like the communication with the customer if something's missing. And, yes - before I start to load any component (DLL, ActiveX, or any other application) I test if it exists. Either I hide the button (which would cause loading the component) in the OnInitialize event or I show an alert with the note to reinstall the app (for instance OpenDCL runtime is missing). But it's my taste.

Because of the history of our app, we were still copying the runtime to the app server as James told. For almost the whole last decade there were nearly 2000 installations a year using the given runtime we were deploying along with the vlx. There were never any problems to any other application. Updating was very easy because only the files (vlx and arx) on the server had to be updated. Of course, that was only working because our app was very specific to a certain kind of customers. That wouldn't work anymore if an international release would be distributed, for instance.

When you call the MSI a "kludge", does it automatically mean that OpenDCL applications should not be distributed by Inno Setup? Did I understand right? Do you know any MSI authoring tool which can although work with the Merge Module. I does not mean Visual Studio, may be not everybody is using that. I've found this list (you see, I'm not familar with it). If so, we should replace the Inno Setup Tutorial with a MSI tutorial.

Regards, Fred

P.S. June is almost over so I'm looking forward to your installer rant of July

[owenwengerd]

I use Innosetup and have added the .msi per the tutorial. Are you saying this is really no good, and that I should be using a better installer? If so, what? Anything short of going to something expensive and/or much more complex?

Adding the MSI is indeed a kludge, but it's a pretty good one as kludges go. Several like Fred have mentioned scenarios that *could* happen, but nobody has ever documented a case where it *did* happen. That is why I challenged Fred's statement. Yes, using the MSM is preferable, but embedding the MSI is 100 times better than manually copying files.

[owenwengerd]

For almost the whole last decade there were nearly 2000 installations a year using the given runtime we were deploying along with the vlx. There were never any problems to any other application.

What you are doing *will* break if and when it encounters another OpenDCL app in the wild, and then it will be *your* fault. There is a 100% chance of that eventually happening, yet you do nothing. On the other hand there is a .01% chance of an app encountering a missing runtime, yet you believe that potential justifies extraordinary measures to alert the user to the situation. Do you see the dichotomy?

[owenwengerd]

When you call the MSI a "kludge", does it automatically mean that OpenDCL applications should not be distributed by Inno Setup? Did I understand right? Do you know any MSI authoring tool which can although work with the Merge Module. I does not mean Visual Studio, may be not everybody is using that. I've found this list (you see, I'm not familar with it). If so, we should replace the Inno Setup Tutorial with a MSI tutorial.

I believe even InnoSetup supports merge modules, but I don't use it, so I can't offer any advice on how. It's possible that there's a limited free version that doesn't, I'm not sure. I don't think the problem is serious enough to worry about the existing tutorial. As I told Ken, the embedded MSI is not very high on the application deployment sin scale.

[Fred Tomke]

Owen, any site I've found to Inno Setup and Merge Modules recommend to wrap the MSM into an MSI and to start the MSI like in the tutorial. I had a successful try with Advanced Installer 8.2 Freeware. But I'm still looking for anyone who has experiences in WiX and WiXEdit, then we could create a MSI tutorial, too.

Fred

[Fred Tomke]

On the other hand there is a .01% chance of an app encountering a missing runtime

Indeed, there is a 100% chance: if a newer or different AutoCAD release is installed after the app was installed. And this is very often. At least once a year, if a new AutoCAD release will be published.

I need to know: if I use the MSM, is there any chance to initiate repairing the OpenDCL without reparing or reinstalling the whole app when I don't see the OpenDCL runtime in the control panel?

Regards, Fred

[owenwengerd]

Indeed, there is a 100% chance: if a newer or different AutoCAD release is installed after the app was installed.

I meant 0.01% of normal apps. I think yours is, shall we say, structurally deficient. [Ok, now I will stop giving you a hard time - at least until July  ]

If a new release of AutoCAD is installed, a conventionally installed app will not initially load in the new release until it is reinstalled (or repaired, to use Windows Installer terminology). When your app is installed for the new release of AutoCAD, OpenDCL will be installed as well. At least, that is, if your app is installed by conventional means.

If you do some hokey startup with a custom exe that starts and loads itself into a new release of AutoCAD that has been freshly installed even though you never tested your app with it, then yes, your app starter is responsible to make sure the runtime is installed as well. I would avoid such a startup system at all costs, but your custom autocad starter can certainly check and run the MSI if needed.

[Fred Tomke]

Hello, Owen, I hoped that you've noticed that I've tried to use the past tense form here. But obviously, I was not clear enough. In the past we could be sure to 100% that these customers which would install this single product of us wouldn't use any other OpenDCL based app and we were not disappointed. One of the parts was an AutoCAD-OEM and we were forced by contract to remove any way to extend the OEM. So our product was the only app in this case. But as I already mentioned, it was in the past. Currently, we are splitting our app because of many other reasons (localisation, supporting thick clients not at least because of non-signed .NET-DLL's, and so on), which are not OpenDCL-related. Since there won't be any ObjectDCL forms anymore, all lisp based forms are OpenDCL based now and we can choose an other way of installation now.

I never wanted to say the copying the files is a "better" solution or a solution at all - I only wanted to say that it worked for ten years.

Regards, Fred

[owenwengerd]

Ah, ok, I understand that using AutoCAD OEM changes the equation in your favor. I hope it is now clear that your experience in that unusual case does not apply in the general case. In the general case, installing the MSI via Innosetup is not perfect, but still pretty good -- certainly good enough for the vast majority of applications, and certainly way better than trying to reinvent DLL Hell.

[Peter2]

Owen, any site I've found to Inno Setup and Merge Modules recommend to wrap the MSM into an MSI and to start the MSI like in the tutorial. ...

I just searched the Innosetup Online Help http://www.jrsoftware.org/ishelp/ for "MSM" -> no result. So I can assume that there is nothing new?