I'm thinking of writing some complex macros that I plan to sell as a bundle. What's the best way for a tool geek like me, who is not a trained programmer, to produce code that can run against ER/Studio Data Architect, that cannot be easily copied and shared with friends? Can basic macros be 'compiled'? Is that even a word these days?
Someone has suggested I use Visual Studio to create a c# (whatever that is) or VB project, so I've installed the Community edition. Any things I should definitely do or not do in Visual Studio?
We have an editor (WinWrap) in ER/Studio that comes with many code samples and tutorials. I'd suggest to first review the documentation on this via our docwiki: Using the Macro Editor
As well, since our macros are COM based, you can create macros outside of ER/Studio with a tool like Visual Studio.
Thanks - Any things I should definitely do or not do in Visual Studio?
Not sure if this is better late than never but someday it may be of use.
The WinWrap Basic language says it supports "encrypted" routines. Given this works (I've never tried) it only makes them hard to read, not hard to copy. Nevertheless, like writing a dll (which only makes it hard to read, not hard to copy) you can make use of this feature to make copying difficult. The difficulty comes by the fact that, unless the code can be read, a user can't see what to do to make the software work (like see what encryption keys you use) nor can they modify the code to remove your protection scheme.
The biggest problem with any copy protection is how do you determine copy status? What, in the current environment, can be examined. For example you can store an encrypted version of the machine name in some location and then refuse to run unless that location contains the same value you get when encrypting the current machine name.
The next problem is how do you put the encrypted value into the correct location in a way that someone copying the software can't just repeat to set themselves up? Now-a-days most vendors set up a server that their software must contact to validate that the machine being set up belongs to a user who paid but has not run the set-up yet. A similar way is for the vendor to email the file that activates the software. In this case the vendor encrypts the machine name or perhaps the current time, then the user has x days to run the macro that creates the key used to verify the software can run. After that number of days the setup macro refuses to run. There are lots of ways. It's pretty much up to your imagination. The key is that unless the user can decrypt the macro they can't change the code to circumvent your security.
Beyond using macro encryption and saving some identifying value like 'environ("COMPUTERNAME")' with the Encrypt64 function it's useful to know that there are GetSetting and SaveSetting functions. These give you a place to red/write the verification values. On most machines these functions write to a private location in the registry. Even if users try to muck with the entries they can't activate your software without decrypting your macros to discover what entry modifications might work.
In the long run, copy protection is FAR from simple. Coding your functionality in a dll does nothing to protect from copying unless you also do something like I've described above. There is a big difference between not easily being able to read the code and not being able to copy it.
The functions MacroRunThis and ModuleLoadThis might also come in handy if you want to encrypt your code and decrypt it on the fly. Perhaps only if the machine is recognized etc. Imagination is the limit!
Felt like the only non trained programmer here. Glad that there are others :)
I've created VBA macros within excel. I had a similar fear as well since even though people may not realize where to go to copy the formulas for our particular instance, they could easily just copy the excel file itself with the macros and essentially repurpose it for themselves.
- Solar Installer
Thanks for the solidarity .
I'm not a fan of embedding macros in Excel files - that was something I really disliked when I used Erwin. I much prefer commonly-used scripts to be added to menus in the tool; if that's not feasible, the next best thing is to run them from script files or some other external file. Embedding macros in Excel makes them very difficult to find - how do know which version you should be using?
Powered by IDERA