Jump to content
Developer Wiki and Function Reference Links ×

Encryption of .px includes with VW2019


JoelS

Recommended Posts

I am having a problem with encrypting our plug-ins under VW2019 which did not occur with previous releases, in that the encrypted plug-in still looks for the include as if it were a .vss and not a .px, as all of ours are. Thus we cannot ship any of our plug-ins.

 

I have looked at the encrypted plug-ins with BBEdit and they are clearly encrypted but not large enough to have incorporated the include data.

 

What may have changed in the encryption process or is this a bug with 19?

 

macOS 10.14.6 (Mojave)

Vectorworks 2019 SP4

 

TIA

Joel.

Link to comment

What is your previous version?

 

Nothing should change the way encrypted files work from 2018 to 2019, though there were some api changes, so you should make sure everything runs correctly unencrypted. This includes updating the file path separator on the Mac, which could cause an included file not to include.

 

A few versions ago, script files needed to change their encoding to UTF8. 

Link to comment

Hi JBenghiat,

 

Mainly was using 2015 with some 2017/18.

 

All the necessary changes were made:

All files UTF8, deprecated functions handled, all scripts compile and run normally unencrypted, no errors or warnings, so all paths OK.

After encryption, everything still works perfectly but the includes have still to be present.

 

Hi Nicolas,

 

The BatchEncryption Plugin definitely not present in any of my Vectorworks user or application folders going back to 2012. Not part of the standard install?

Is it documented somewhere?

 

Thanks both.

Link to comment
15 hours ago, JoelS said:

Hi Nicolas,

 

The BatchEncryption Plugin definitely not present in any of my Vectorworks user or application folders going back to 2012. Not part of the standard install?

Is it documented somewhere?

 

Thanks both.

 

It was the first idea I had when I have seen this thread. However I am not sure if it is need or not, if you do not encrypt per script (unlike we do). (That is why I have answered with such a delay.)

 

As for documentation, see http://developer.vectorworks.net/index.php/VS:EncryptPlugin

Link to comment

Nicolas,

 

Thanks for the link. We are not using the SDK, hence no plug-in.

 

We are encrypting on an individual script basis and anyway this does not explain the behaviour of VW2019 in relation to the includes.

 

I will do some more experiments with earlier versions of Vectorworks to see if anything emerges and report back.

Link to comment

OK, that leaves not many options left for you to have a quick workaround.

 

I can only think of two possible ways you could try:

- a Mac running an older macOS

- a Mac running macOS 10.14 but on another filesystem (HFS versus APFS, of course case-insensitive, as VW does not work on case-sensitive file systems)

 

Also, you might try to encrypt a brand-new VS. Does it work?

Link to comment

@Nicolas Goutte What’s your thinking that this is Mac OS related?

 

@JoelS

- Are you getting error messages when you try to run the encrypted script without the included? Can you post one of the error messages?

 

- Do your include paths still use colon file path separators? The compiler is fairly liberal about the file paths, but the encryption code requires a POSIX style path. 

 

- BatchEncrypt does not require the SDK. You used to need to install from the SDK zip, but the library should now be standard in VW. You run the encryption via a script, and I can verify that this works in 2019. 

 

Encrypting via script has the added benefit that the plug-in does not need to be in your plug-ins folder, so you can encrypt a duplicate and not worry about accidentally locking yourself out of your work 

 

 

Link to comment
1 hour ago, JBenghiat said:

@Nicolas Goutte What’s your thinking that this is Mac OS related?

 

Well, personally I did encrypt on Windows on VW 2019. (Yes, sure by VS call, not by VW directly)

 

As for HFS/APFS difference, I have just thought of it because we were bitten by some differences just last week (on something else in VW's world, not encryption)

 

 

Quote

 

@JoelS

- Are you getting error messages when you try to run the encrypted script without the included? Can you post one of the error messages?

 

Good question, indeed, to double-check if there would be still any error or warning

 

Edited by Nicolas Goutte
Link to comment

I think I have found it.

 

When all the script and include files were updated for VW2019 (280) one include remained as a .vss because it alone was previously in a different location and had to be moved due to the changes wrought in VW2017/18. Of course, this file is referenced in virtually every script, which why they all had a problem.


A quick edit and recompile/encrypt show it to still function when includes are removed in VW2019, which is promising. Moving that same plug-in to VW2018 is also working.

 

We have to test on a client installation next week and see of that one script remains functional but it looks like having to edit and re-encrypt the whole suite…

 

I'll do some more tests and report back in a few days.

 

We never saw any errors of course except at run time. I have not seen any issues here with the change from HFS+ to APFS. All our path names are clean.

Link to comment
  • 2 weeks later...

We encountered another problem when trying to roll out our scripts in that .vss includes were causing scripts not to function at all, i.e. when chosen from the menu, nothing happens, no errors, nothing. It was historically useful to have some includes not compiled into the solution  to handle users with different versions of VW but instead of trying to debug yet another issue we made the decision to make these .px and updated all the scripts to reference these files. This allows them all to work on our client sites.

 

Testing is complex because the environments are. For licensing reasons, scripts are document specific and sites have different configurations, so recreating those environments exactly is not so easy. Our client base is fantastic so we can test on their installations to guarantee good results.

 

In all, the changes since VW2015 have caused a lot of disruption and we have come to the end of the road with this approach. We have already been working on alternative ways to deliver the same or better functionality in our solutions without using Vectorworks and these are well advanced.

 

Thanks all for your contributions.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...