There is no discussion here about "Autoloader", so I want to ask if it will work: "Autoloader" for runtime?
Who has experience? Good ones or bad ones?
(I know that the best way is the "installation", but the admin of the client only accepts Autoloader-bundles and has locked all setups.)
Hi, there was a discussion in the past about loading the arx manually - but not with .bundles. As far as I know, using apps from Autodesk Exchange need to start installers, too.
How do you store your files without setup? Just copy? Then copy the arx-files and the runtime.res of the desired language along with your lsp-files.
Make sure that you arxload the correct arx file manually depending of the loaded AutoCAD-release.
I made something like this in the past:
(defun load_opendcl (/ strArx )
(or (and dcl-project-load (= (type dcl-project-load) 'EXRXSUBR))
(and (setq strARX (findfile (strcat "OpenDCL" (if (not (= (getenv "PROCESSOR_ARCHITECTURE") "x86")) ".x64." ".") (substr (getvar "ACADVER") 1 2) ".arx")))
(arxload strARX (strcat "\nIch konnte die Datei " strFile " nicht laden!\n"))
(and dcl-project-load (= (type dcl-project-load) 'EXRXSUBR))))
); load_opendcl
Regards, Fred
Quote from: Fred Tomke on May 18, 2015, 09:46:19 PM
... As far as I know, using apps from Autodesk Exchange need to start installers, too....
Yes, they have an installer, but I'm not sure what it really does. I suppose - and I saw it with a "handcrafted" CMD in a big system - that the main Installer-function is the extraction of the .bundle from the installer and a simple copy to the folder. More complex feature (registry, environment...) should be done with the .bundle-features.
This is what I tried: to use a package with vlx+arx+... inside a bundle, without additional lisp-configurations or loads. The first trial failed: it only activated the VLX, the ARX are ignored.
Any hints are appreciated.
I'm still fiddling about this topic ...
Why?
The "Autoloader" offers a way to "install" something (incl. command-registration, env.-variables ...) without an "Installer". Some companies have locked all setups and installers to their (AutoCAD-)Users.
Of course the Autoloader (from Autodesk app-store) itself comes with an installer, but this is a simple "copy from source to c:\" and could be replaced with a manual copy.
The code to register Opendcl:
<Components Description="OpenDCL für R20 x64 (2015-2016)">
<RuntimeRequirements OS="Win64" SeriesMin="R20.0" SeriesMax="R20.1"/>
<ComponentEntry AppName="OpenDCL.x64.20.arx" Version="8.0.0.14" ModuleName="./Program/OpenDCL.x64.20.arx" AppDescription="OpenDCL - Runtime für Dialogfenster" LoadOnAppearance="False" LoadOnAutoCADStartup="False" LoadOnCommandInvocation="True">
<Commands GroupName="PEGL_BASETOOLS">
<Command Local="OpenDCL" Global="OpenDCL"/>
</Commands>
It would work, but if OpenDCL is already installed (which can not be determined by this solution) I get a double-registration: see attachment.
The next idea - to make the muddle perfect - is to use a renamed ARX: OpenDCL_X.arx loads with command "OpenDCL_X"
<Components Description="OpenDCL_X für R20 x64 (2015-2016)">
<RuntimeRequirements OS="Win64" SeriesMin="R20.0" SeriesMax="R20.1"/>
<ComponentEntry AppName="OpenDCL_X.x64.20.arx" Version="8.0.0.14" ModuleName="./Program/OpenDCL_X.x64.20.arx" AppDescription="OpenDCL_X - Runtime für Dialogfenster" LoadOnAppearance="False" LoadOnAutoCADStartup="False" LoadOnCommandInvocation="True">
<Commands GroupName="PEGL_BASETOOLS">
<Command Local="OpenDCL_X" Global="OpenDCL_X"/>
</Commands>
Result:
My lisp would always use the "_X" version, no matter if the full version is installed or not. If my lisp is "deinstalled" (removed), also the "_X" version will be removed.
Question:
Genius or insanity?
I highly recommend against loading a renamed OpenDCL ARX module for a non-internal plugin application, as it defines shared functions that may be used by other applications as well. If your application presumes to control that module, soon others will do the same (because maybe they need a more recent version, for example), and an arms race will ensue.
I see this kind of discussion often, but I still don't understand really why there is so much resistance to using the installer. Can you identify a problem that restricted user privileges creates when installing normally? Maybe it would be more useful to address such problems in the installer rather than trying to duplicate its work manually.
Hi Owen
it is not my personal passion to avoid the installer. I mentioned the problem some time ago - there are companies where the CAD-department is small and depends absolutely on the IT-department (Mordac). They need an Admin to run a MSI or Innosetup, and sometimes it takes two weeks to talk to the IT which started to discuss "What is it? Do we need it? Is it clean? It is a lot of work because we don't have ..." and after 4 weeks nothing is done. So I'm looking for a way - smooth and clear. But I don't want to create something wrong.
I wonder if modifying the runtime MSI file to support Single Package Authoring (https://msdn.microsoft.com/en-us/library/windows/desktop/dd408068(v=vs.85).aspx) would solve this problem with permissions. It seems to be available only in Windows 7 and later. Alternatively, maybe a special .mst file could be produced to transform the existing MSI into one that installs runtime files to user folders.
I've never made a MSI/MS*, so I'm sorry that I can not contribute to this special question.
I played around and tried to make an "OpenDCL.bundle" for AutoCAD 2012-2016 (not for Mac, not for ZWcad and Bricscad and of course not for Acad < 2012).
I deinstalled OpenDCL - Runtime and Studio and made a quick test with the bundle in %appdata%, and it was "loaded on demand" in 2012 - 2016 and I got the German messages ("DEU")
Find attached the "PackageContents.xml" in the current draft; maybe someone want to check and test it in his environment and language. If it works, maybe this could be an additional option to offer the software to users.
BTW - "language": The subfolder "ESM" contains the Spanish files, but Spanish is "ESP". What is ESM?
Quote from: Peter2 on June 21, 2015, 03:09:28 PM
...Find attached the "PackageContents.xml" in the current draft; maybe someone want to check and test it ...
No remarks? No comments?
Quote from: Peter2 on June 21, 2015, 03:09:28 PM
BTW - "language": The subfolder "ESM" contains the Spanish files, but Spanish is "ESP". What is ESM?
Bump up..
ESM = Spanish (Mexico), which I suppose is similar bot not the same as ESP.
But "Autoloader" only supports ESP. It is possible to load ESM-folder under ESP-definition, but that's (very little) inconsistent.