Large scale deployment

[kenkrupa]

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?

[Fred Tomke]

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

[jbuzbee]

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.

[owenwengerd]

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.

[kenkrupa]

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.

[Fred Tomke]

... 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

[Fred Tomke]

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.

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.

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

[kenkrupa]

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?

[kenkrupa]

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.

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.  ???

[Fred Tomke]

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

[Fred Tomke]

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

[kenkrupa]

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.

[Fred Tomke]

OK - that's starting to make sense to me now. Thank you.

Phooo! That was hard! :)

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

[kenkrupa]

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.

[owenwengerd]

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.