AutoCAD 2014

[andrew]

leaving secureload at 2 will not let odcl load (for me)
i have to change it to 0 first, close acad, install the runtime then
relaunch acad and after verifying that odcl directory is added to the trusted path, i then can reset the secureload.


this is how it works for me, maybe this will come in handy for someone else that might have this issue

[owenwengerd]

Sorry, I meant leave it set to the default value of 1, not 2.

[macuma]

Wasn't sure whether to start a new thread but I have the same problem but only on a machine running Windows XP.

OpenDCL loads and runs fine on Windows 7 and Windows 8. When run on XP using (command "opendcl") I get a return of nil.

I'm running XP 64 bit and Windows Update is telling me that I am up to date.

I've loaded OpenDCL using Appload and I get a return of "OpenDCL Runtime [7.0.0.12] loaded OpenDCL.x64.19.arx successfully loaded." When I type (command "opendcl") I'm still getting nil when I should be getting OpenDCL Runtime [7.0.0.12] loaded.

[owenwengerd]

When I type (command "opendcl") I'm still getting nil when I should be getting OpenDCL Runtime [7.0.0.12] loaded.

Strange. What happens if you just enter the OPENDCL command directly without calling the (command) function?

[macuma]

A blank command line is returned.

[owenwengerd]

I suggest you start a new thread. It's difficult to tell from what you've posted whether your problem is related to the new SECURELOAD system in AutoCAD 2014.

[velasquez]

Does anyone have any idea how to override this message?
The first load the application it will appear 2 times.

Thanks velasquez

[Danner]

I got around it by having my app automatically adding the "...Common Files//OpenDCL//" folder to AutoCAD 2014's "TrustedPaths" variable prior to the first load of the Opendcl runtime module.

[velasquez]

I got around it by having my app automatically adding the "...Common Files//OpenDCL//" folder to AutoCAD 2014's "TrustedPaths" variable prior to the first load of the Opendcl runtime module.

Have you ever thought of working with AutoLoader and an xml file from Autodesk?

[owenwengerd]

For the record, I don't recommend adding the OpenDCL runtime directory to the support path without the user's permission. I think it's better to do that *after* the user has consented to loading rather than before, which is how OpenDCL Runtime is designed to work.

[Danner]

Have you ever thought of working with AutoLoader and an xml file from Autodesk?

I'm more of a Bricscad man really.  I use a single installer in conjunction with Owen's "LspLoader" for my deployments across all platforms of AutoCAD/BricsCAD.

For the record, I don't recommend adding the OpenDCL runtime directory to the support path without the user's permission. I think it's better to do that *after* the user has consented to loading rather than before, which is how OpenDCL Runtime is designed to work.

Fair point.  (For what its worth - I should say my app is installed via a digitally signed installer).

[Danner]

Owen,

Would you consider digitally signing the opendcl.19.arx modules instead of adding Opendcl to the "TrustedPaths" in AutoCAD 2014?

This would be a more legitimate way to allow us to obtain a silent first install than the method I suggested.

[velasquez]

Owen,

Would you consider digitally signing the opendcl.19.arx modules instead of adding Opendcl to the "TrustedPaths" in AutoCAD 2014?

This would be a more legitimate way to allow us to obtain a silent first install than the method I suggested.

Hello Danner,

See the link below'm studying the same method.
Maybe this is the way.
http://adndevblog.typepad.com/autocad/Downloads/CP2080_PAL.pdf


vleasquez

[owenwengerd]

Would you consider digitally signing the opendcl.19.arx modules instead of adding Opendcl to the "TrustedPaths" in AutoCAD 2014?

That was considered and ruled out. The problem is that (in order to not violate the open source principle) the signing key would need to be made public by including it in the source code repository. However, doing so would make it easy for malicious users to sign their code with our key.

There is also a philosophical case to be made that third party developers should not insulate Autodesk from the problems it created. IOW, if users don't want the security warnings, let them hold Autodesk to the fire. If we as developers try to fix it once, we'll "own" it forever.

[Danner]

Hello Danner,

See the link below'm studying the same method.
Maybe this is the way.
http://adndevblog.typepad.com/autocad/Downloads/CP2080_PAL.pdf


vleasquez

Hi Velasquez,

Thanks for the link.  That is indeed an excellent method.  For once Autodesk have simplified things. So much easier to install your ".bundle" into a static "ApplicationPlugins" folder and edit a PackageContents.xml file.  No need to touch the Windows Registry, Acaddoc.lsp etc.  There are no horrible messages when your app is loaded for the first time from the  "ApplicationPlugins".

From my perspective, because I support older AutoCAD platforms and Bricscad  - I may as well continue with the traditional installer approach (which makes the necessary registry entries within Bricscad/Autocad to allow useage of Lsploader). 

Now that AutoCAD 2014 has created TrustedPaths.  My app now loads the relevant LspLoader files for AutoCAD 2014 into a new ".bundle" folder in the "ApplicationPlugins" folder.  So for me, paradoxically things have actually got slightly more complicated deployment wise but has the advantage that I can use the same installer for deployments across all CAD platforms.

That was considered and ruled out. The problem is that (in order to not violate the open source principle) the signing key would need to be made public by including it in the source code repository. However, doing so would make it easy for malicious users to sign their code with our key.

There is also a philosophical case to be made that third party developers should not insulate Autodesk from the problems it created. IOW, if users don't want the security warnings, let them hold Autodesk to the fire. If we as developers try to fix it once, we'll "own" it forever.

Thanks Owen,

I had a feeling it was something to do with being open source.

I get your point I think that the security warnings are between Autodesk and their users and we developers shouldn't try and take ownership of this issue by finding ways to circumnavigate them. (I realize that is in direct contradiction of my previous reply).