This tutorial describes how to create an installer to deploy your ODCL application & install the ODCL runtime at the same time.
By Lance Gordon (Thanks)
You can download it here:
https://opendcl.com/forum/index.php?topic=2911.0 (https://opendcl.com/forum/index.php?topic=2911.0)
A very, very long time ago Bryan Blattel had on his CadWerx website and example of how to use pascal scripting to do stuff like add folders to AutoCAD's search path and even load menus in Inno Setup exe's.
I used to use it with great success when I managed AutoCAD for several architectural firms. Does anyone have any info? This would be a great tool for setups.
If I find anything I'll post it.
jb
Oh, Happy New Year!!
Wow, can't believe I found it. It's a copyrighted exe though. It was a free download - but could we use and distribute here?
Don't post anything unless you've first contacted Byron and asked permission (and I'll bet he will gladly permit it if you ask).
Good idea Owen - thanks. This is a great tool for people developing programs.
I for one, would be very interested in this. I'll be following this thread with great interest.
Havn't heard from Byron - don't even know if the email I have is any good.
I'm having trouble with the msiexec.exe syntax:
Filename: msiexec.exe; Parameters: “/i “”{app}\OpenDCL.Runtime.5.1.0.2.msi”” /qn”
I get the dialog (which means there is something wrong with the syntax). Any suggestions?
Thanks!!
Got it. I cut and pasted from the pdf and there was some character confusion in the translation.
Any news?
Unfortunately no. The only thing I would use it for was adding a menu to menugroups. Pretty much everything else (paths, loading apps, etc.) can be handled in the .mns file. Oh well. If I here anything Ilet you all know.
This was very helpful, and seems to work just fine (so far I have tested with Studio uninstalled so I could see that it worked). I have a few concerns though.
UninstallRun. Let's say I am installing Runtime.6.0.2.3 with my app, and someone has already done so with their app. If my app gets uninstalled, what happens - does the Runtime that was already installed get removed? Or is this method somehow smart enough to know that it did not get installed with my app and leave it?
Also, what if that other app that installed the runtime before me gets uninstalled - will that remove the runtime leaving my app without it?
What if the user is running R2010 with some other app that has installed the Runtime.5 - does that app now load the Runtime.6 that I installed, with no problem? Or what?
These are questions that have made me shy away from using OpenDCL until I had a real need. Now that I'm into it, I love it. But I'd feel better about going live with it until I know the answers.
Hi,
Unfortunately, I cannot help you very much because I have no experiences with the installer. As far as I remember another topic with such a question a counter shall be work in the background which tells the uninstaller if any other application is still using this component (OpenDCL in this case). As far as I remember the Runtime.msi won't install if any newer release is already installed, but a newer release will uninstall the existing and install the newer files after that. There is no way for side-by-side installation.
I'm sure that others can tell you more about it. We are distributing the runtime files with our program files and we're not using the msi. We are loading OpenDCL by the application which is wrapping and controlling AutoCAD as an external application.
Regards,
Fred
As long as everyone follows the rules and installs the runtime via the standard .msm or .msi, everything will work correctly for every OpenDCL based application. Windows Installer keeps a reference count and will not remove the files until the last relying application is uninstalled. As long as your application requires the runtime, it will remain installed.
Unfortunately some application developers do not follow the rules, so there is a risk of your app getting clobbered. A reinstall should fix the problem in that case.
kenkrupa,
I recommend you to check up the existing OpenDCL runtime when your application is loading at AutoCAD startup. Since the installed runtime can be manually uninstalled in Windows control panel > software, it is worth to check if OpenDCL runtime is still installed and if it is the release your application needs. If not, throw an alert with the hint of reinstall.
Regards, Fred
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.
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?
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
Quote from: owenwengerd on June 23, 2011, 04:13:43 PM
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
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. :)
Quote from: owenwengerd on June 24, 2011, 10:21:27 AM
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?
Quote from: owenwengerd on June 24, 2011, 10:21:27 AM
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 (http://www.opendcl.com/forum/index.php?topic=1641.msg8108#msg8108). 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 (http://www.installsite.org/pages/en/msi/authoring.htm) (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 ;)
Quote from: kenkrupa on June 24, 2011, 10:54:39 AM
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.
Quote from: Fred Tomke on June 24, 2011, 11:31:03 AM
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?
Quote from: Fred Tomke on June 24, 2011, 11:31:03 AM
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 (http://www.installsite.org/pages/en/msi/authoring.htm) (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.
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 (http://www.advancedinstaller.com/download.html). But I'm still looking for anyone who has experiences in WiX and WiXEdit, then we could create a MSI tutorial, too.
Fred
Quote from: owenwengerd on June 24, 2011, 01:56:53 PM
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
Quote from: Fred Tomke on June 24, 2011, 03:24:40 PM
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 8) ]
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.
Hello, Owen, I hoped that you've noticed that I've tried to use the past tense form here (http://www.opendcl.com/forum/index.php?topic=721.msg8113#msg8113). 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
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 (http://en.wikipedia.org/wiki/DLL_hell).
Quote from: Fred Tomke on June 24, 2011, 02:51:37 PM
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?
Quote from: kenkrupa on June 23, 2011, 07:44:49 PM
Thanks guys. Fred, your suggestion of checking solar panel (http://www.shinesolar.net) 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?
Yes the tutorial was extremely beneficial.. I just was able to create installer with this and it worked nice.
I made the installation package for my application with InnoSetup.
It seems to work fine, but today I noticed a problem:
1 I install AutoCAD 2014
2 I install my application: everything ok, OpenDCL is loaded correctly.
3 After I install AutoCAD 2015
4. reinstall my application: in this case in AutoCAD 2015 OpenDCL is not loaded.
It seems that the installation package when run 2 or more times that verifies "OpenDCL.Runtime.8.0.0.6.msi" is already installed, so not proceed with a new installation and then do not look for new cad.
Can you help me solve this problem?
Here is an excerpt of the code used
AppName=TEST
AppVerName=TEST R8.0.0
DefaultGroupName=TEST
AppPublisher=TEST
AppVersion=8.0.0
VersionInfoVersion=8.0.0
AllowNoIcons=yes
DisableDirPage=yes
DisableProgramGroupPage=yes
PrivilegesRequired=admin
OutputBaseFilename=TESTAPP
UsePreviousAppDir=yes
DefaultDirName={pf}\TESTAPP
[Files]
Source: OpenDCL.Runtime.8.0.0.6.msi; DestDir: {app}; Permissions: users-full; Flags: ignoreversion
[Run]
Filename: msiexec.exe; Parameters: "/i ""{app}\OpenDCL.Runtime.8.0.0.6.msi"" /qn"; StatusMsg: Installation OpenDCL ...
Thank you
Simply installing again should trigger a repair, which should configure AutoCAD 2015 in that case. Can you repeat the test, but see if a manual repair works as expected? Also, please test the latest 8.0.0.7 in case there was a problem with the installer only in 8.0.0.6.
Quote from: owenwengerd on September 04, 2014, 07:51:19 AM
Simply installing again should trigger a repair, which should configure AutoCAD 2015 in that case. Can you repeat the test, but see if a manual repair works as expected? Also, please test the latest 8.0.0.7 in case there was a problem with the installer only in 8.0.0.6.
The user did exactly what you said and it solved the problem.
However, when he tried to install several times my application, the problem has never been solved.
So I think that the InnoSetup project is set to not reinstall OpenDCL.Runtime.8.0.0.6.msi, when it is already installed in the system.
Unfortunately, now I can not do the test, and I have to trust what he says my client.
Next week I will be more precise.