OpenDCL Forums

OpenDCL => Deployment => Topic started by: kenkrupa on June 24, 2011, 09:27:12 AM

Title: Large scale deployment
Post by: kenkrupa on June 24, 2011, 09:27:12 AM
So far I have the Runtime .msi file being installed along with my new app by Innosetup, per the tutorial. However, I'm thinking that this won't play well with company-wide customers. I'm not well versed in this subject, but I understand that they will typically install my current app (which does not use any ODCL yet) on one system and then just push it out to all others. They do not want to have to go install my app on each system. I don't think just pushing out the \Common Files\OpenDCL folder would make it happen, would it?

I'm wondering, what if, instead of installing the .msi and using (command "_OPENDCL"), I were to include the .arx files along with my stuff, determine the correct one for the current version and platform, and just load it?
Title: Re: Large scale deployment
Post by: Fred Tomke on June 24, 2011, 09:44:32 AM
kenkrupa, I recommend you to deploy the runtime with the installer as you wrote in your first sentence. It's the best way.

Regards, Fred
Title: Re: Large scale deployment
Post by: jbuzbee on June 24, 2011, 10:04:11 AM
When I was supporting a large Arch firm I included the arx on the server (along with my apps).  Local machines got a mns file and the paths to the server only needed to be set up once (I actually used innosetup for a local and server install)  Worked like a charm.
Title: Re: Large scale deployment
Post by: owenwengerd on June 24, 2011, 10:26:32 AM
Quote from: kenkrupa on June 24, 2011, 09:27:12 AM
I'm wondering, what if, instead of installing the .msi and using (command "_OPENDCL"), I were to include the .arx files along with my stuff, determine the correct one for the current version and platform, and just load it?

If you do that, you will perpetrate the very crime you were worried about in the first place. It's self defeating logic to think that your application is more important than every other application; if you follow that path, your application will eventually get trumped and lose the tug of war. Just build an MSI with a merge module, then your corporate customers will love you, your app will never break, and other developers will never cuss you.
Title: Re: Large scale deployment
Post by: kenkrupa on June 24, 2011, 11:15:16 AM
Quote from: owenwengerd on June 24, 2011, 10:26:32 AM
Quote from: kenkrupa on June 24, 2011, 09:27:12 AM
I'm wondering, what if, instead of installing the .msi and using (command "_OPENDCL"), I were to include the .arx files along with my stuff, determine the correct one for the current version and platform, and just load it?

If you do that, you will perpetrate the very crime you were worried about in the first place. It's self defeating logic to think that your application is more important than every other application; if you follow that path, your application will eventually get trumped and lose the tug of war.

Owen - I don't understand why any of this would happen. Maybe you didn't understand that in my proposal I would include the .arx files in with my stuff, not in the Common Files\OpenDCL folder. I certainly do not think my app is more important. I just thought that if I provided these files in my own folder, it would make it easier for distribution within a company, and NOT interfere with what others might do.

Fred - I still don't see why the .msi is the best way. Doesn't that mean my app would need to be installed on each system to install the .msi? That's what I'm trying to avoid making my customers do. (Otherwise they would just copy my stuff onto other systems.) It sounds like jbuzbee is saying he did something similar, with success. And I believe this is still the way to load DosLib.
Title: Re: Large scale deployment
Post by: Fred Tomke on June 24, 2011, 11:33:48 AM
Quote from: kenkrupa on June 24, 2011, 11:15:16 AM
... I would include the .arx files in with my stuff, not in the Common Files\OpenDCL folder.

That is exactly the reason Owen mentioned!
If any product comes with its own OpenDCL runtime stuff, it is going to collision course to each other.

Regards, Fred
Title: Re: Large scale deployment
Post by: Fred Tomke on June 24, 2011, 11:43:39 AM
Quote from: kenkrupa on June 24, 2011, 11:15:16 AM
Doesn't that mean my app would need to be installed on each system to install the .msi?
That's correct. It has to be installed on each workstation to make your app running.

Quote from: kenkrupa on June 24, 2011, 11:15:16 AM
That's what I'm trying to avoid making my customers do. (Otherwise they would just copy my stuff onto other systems.)

There's absolutely no difference to the installation: in both cases files are copied to the worksation. The only difference of using the MSI (or MSM :) ) is that there is only one runtime for all OpenDCL based applications.

Quote from: kenkrupa on June 24, 2011, 11:15:16 AM
It sounds like jbuzbee is saying he did something similar, with success.

Sure, it will work as long yout app is the only OpenDCL based application on the workstations.
And, can you be sure? ;)

Regards, Fred
Title: Re: Large scale deployment
Post by: kenkrupa on June 24, 2011, 11:47:31 AM
Quote from: Fred Tomke on June 24, 2011, 11:33:48 AM
If any product comes with its own OpenDCL runtime stuff, it is going to collision course to each other.
Sorry - I don't understand. If I have a separate folder of .arx files, how would a collision occur?
Title: Re: Large scale deployment
Post by: kenkrupa on June 24, 2011, 12:04:41 PM
Quote from: Fred Tomke on June 24, 2011, 11:43:39 AM
There's absolutely no difference to the installation: in both cases files are copied to the worksation. The only difference of using the MSI (or MSM :) ) is that there is only one runtime for all OpenDCL based applications.
The difference I see is that without any odcl my stuff can be copied to stations and will work. You can't just copy the Common Files\OpenDCL folder. And you can't just copy the .msi file - it need to be run.

Quote from: Fred Tomke on June 24, 2011, 11:43:39 AM
Sure, it will work as long yout app is the only OpenDCL based application on the workstations.
I'm still not seeing any problem. I just loaded OpenDCL.x64.18.arx manually (simulating what I would do), then did _OPENDCL (simulating another app doing this the standard way). No problem that I can see. Maybe I'm being dense, but it seems like you are telling me it would be a problem but not really explaining why.  ???
Title: Re: Large scale deployment
Post by: Fred Tomke on June 24, 2011, 12:05:14 PM
Quote from: kenkrupa on June 24, 2011, 11:47:31 AM
If I have a separate folder of .arx files, how would a collision occur?

Because each app will try to load its OpenDCL runtime release. Just imagine: the user is working with different apps which uses OpenDCL runtime. Each app comes with its own OpenDCL runtime files. How will you avoid that application 1 which uses OpenDCL 5 is loaded before your application will be loaded and you will need OpenDCL 6? If you give your app to the user you have no influence anymore to the time when the app is going to be loaded and whether there is any other OpenDCL runtime which was already loaded before or not. That's why the runtime should be installed to CommonFiles folder. And please note: if the runtime was installed correctly, the language is automatically selected and the correct runtime file will be automatically (demand)loaded into AutoCAD and you don't have to figure out yourself which AutoCAD on which plattform is loaded and which matching ARX has to be loaded now.

Regards, Fred
Title: Re: Large scale deployment
Post by: Fred Tomke on June 24, 2011, 12:10:07 PM
Quote from: kenkrupa on June 24, 2011, 12:04:41 PM
And you can't just copy the .msi file - it need to be run.

You're right.

Using MSI means: one runtime for all apps.

Copying runtime files by yourself means: each app will come with its runtime files and you cannot be sure when your app and the runtime files of your app will be loaded.

Hope its more clear. ;)

Fred
Title: Re: Large scale deployment
Post by: kenkrupa on June 24, 2011, 12:11:30 PM
OK - that's starting to make sense to me now. Thank you.

But now that still leaves the unanswered question of how can my app get distributed company wide without doing an install on each system? I fear that might be a deal breaker for some customers.
Title: Re: Large scale deployment
Post by: Fred Tomke on June 24, 2011, 12:32:00 PM
Quote from: kenkrupa on June 24, 2011, 12:11:30 PM
OK - that's starting to make sense to me now. Thank you.

Phooo! That was hard! :)

Quote from: kenkrupa on June 24, 2011, 12:11:30 PM
I fear that might be a deal breaker for some customers.

That sound's to me that it is not allowed for the customers to install software. Unfortunately, I know that very well: You have to send a written request to the agency of information and communication technology of the customer's company and three weeks later an administrator is strolling around and tells the customer that it couldn't be installed because there must be an internally research before if your software could be a malware. Meanwhile the customer has forgotten why he needed your app so urgently... Why do I know this so well?
Copy the needed runtime along with your vlx and keep all we said in mind.

Regards, Fred
Title: Re: Large scale deployment
Post by: kenkrupa on June 24, 2011, 02:12:35 PM
Quote from: Fred Tomke on June 24, 2011, 12:32:00 PM
That sound's to me that it is not allowed for the customers to install software.
No, that's not it. It's that the IT dept. doesn't want to go to each of dozens of machines to do the install. But if they install my app on the server, will that solve the problem? Will _OPENDCL called on other systems know what to do? I don't think so - am I wrong?   (Like I said, my knowledge in this area is very limited.)

For those who do want to copy it to each machine, I see one way that would work (with the .msi included in my stuff). I could do this if (vl-cmdf "_OPENDCL") fails:
(setq msi (kcs_prog "OpenDCL.Runtime.6.0.2.3.msi")) ; finds the file in my folder
(startapp "msiexec.exe" (strcat "/i \"" msi "\" /qn"))
Unfortunately, the above line does not work with the /qn switch - don't know why. It does work without it, but not "quietly".
(startapp "msiexec.exe" (strcat "/i \"" msi "\""))

Still hoping to find a better solution.

Title: Re: Large scale deployment
Post by: owenwengerd on June 24, 2011, 02:13:31 PM
Ken, maybe it would help settle your concern about installing software if you consider that installing software is just copying files. The MSI just packages the files nicely into a single file along with information and identifiers that allows Windows to keep track of the files, and do things like automatically repair the files, magically apply updates if, and only if, they are needed, etc. Large customers can push the MSI files to all their network machines easily, whereas manually copying files is hard work and results in orphaned installations that have to be managed manually.

Here's a news flash: if your customer is allowed to copy files, they are allowed to install your MSI. If they are not allowed to install your MSI, then they aren't allowed to copy files either. I'm not saying they wouldn't find it easier to break the rules via copying files - I'm just saying, it's not a valid excuse to claim that one is allowed, but not the other.
Title: Re: Large scale deployment
Post by: owenwengerd on June 24, 2011, 02:18:20 PM
Quote from: kenkrupa on June 24, 2011, 02:12:35 PM
But if they install my app on the server, will that solve the problem?

Ah, that is a slightly different issue, and I didn't realize that this is what you were after. You're on the right track re. automatically kicking off the MSI at runtime, and since you're already using AutoLISP, I suppose a lisp based solution is just as good as using a more common group policy or startup script approach. Sorry, I'm not sure why your '/qn' switch isn't working.
Title: Re: Large scale deployment
Post by: Fred Tomke on June 24, 2011, 03:13:47 PM
Quote from: kenkrupa on June 24, 2011, 02:12:35 PM
(startapp "msiexec.exe" (strcat "/i \"" msi "\" /qn"))
Unfortunately, the above line does not work with the /qn switch - don't know why. It does work without it, but not "quietly".

kenkrupa, just create a batch file in Temp folder with the desired line to call and startup the batch file from AutoCAD.

Fred
Title: Re: Large scale deployment
Post by: kenkrupa on June 25, 2011, 07:19:48 AM
Quote from: Fred Tomke on June 24, 2011, 03:13:47 PM
Quote from: kenkrupa on June 24, 2011, 02:12:35 PM
(startapp "msiexec.exe" (strcat "/i \"" msi "\" /qn"))
Unfortunately, the above line does not work with the /qn switch - don't know why. It does work without it, but not "quietly".

kenkrupa, just create a batch file in Temp folder with the desired line to call and startup the batch file from AutoCAD.

I don't have time to do this today, but it sounds perfect! Thank you :)

Owen - being that this is the same thing Innosetup would do, with the same .msi file, if my stuff were installed by Innosetup instead of copied to a system, would even you give your OK to this?  ;)  (I would continue to install it with the Innosetup, but only have this procedure as an alternate method for if/when my app gets copied to systems.)

Thanks
Ken
Title: Re: Large scale deployment
Post by: owenwengerd on June 25, 2011, 07:40:05 AM
Yep, the crucial step is to call msiexec so it can properly register the runtime installation in Windows. Whether that happens via your initial app installer or at runtime doesn't matter, as long as it happens. If you haven't seen it yet, check out this thread (http://www.opendcl.com/forum/index.php?topic=1142.0).
Title: Re: Large scale deployment
Post by: kenkrupa on June 25, 2011, 08:58:10 AM
Quote from: owenwengerd on June 25, 2011, 07:40:05 AM
Yep, the crucial step is to call msiexec so it can properly register the runtime installation in Windows. Whether that happens via your initial app installer or at runtime doesn't matter, as long as it happens. If you haven't seen it yet, check out this thread (http://www.opendcl.com/forum/index.php?topic=1142.0).

OK - I believe I'm all set now. Thank you Owen and Fred.   :)
Title: Re: Large scale deployment
Post by: kenkrupa on June 27, 2011, 01:05:19 PM
Quote from: kenkrupa on June 25, 2011, 08:58:10 AM
OK - I believe I'm all set now.

Well, not quite as good as hoped. The /qn doesn't work in a .bat file either - it does nothing with it included. My guess is that the UAC won't allow it. I think that when done in Innosetup the UAC has already gotten your permission to alter the system. So startapp works just as well as the .bat. To avoid timing problems, on failure to load I'll advise to run a special command that I'll provide to install it. Good enough.
Title: Re: Large scale deployment
Post by: owenwengerd on June 27, 2011, 07:11:16 PM
Hmm, I guess you could wrap this into an .exe that includes a manifest requiring Administrator/AsInvoker privileges, but I would think just startapp-ing the MSI would have the same effect.

Bottom line, I think there's room for improvement in the deployment possibilities for OpenDCL Runtime, but I'm not sure how it could be improved.
Title: Re: Large scale deployment
Post by: Fred Tomke on June 27, 2011, 11:35:30 PM
Quote from: kenkrupa on June 27, 2011, 01:05:19 PM
My guess is that the UAC won't allow it.

Hi, as far as I remember my test, I was asked by UAC to confirm the installation.
Maybe it will help to call the batch file with runas?

runas [/profile] [/env] [/netonly] /user:loginname program

Regards,
Fred