Enhancing the Add-In

Further to this thread

http://www.experts-exchange.com/Software/Office_Productivity/Office_Suites/MS_Office/Excel/Q_26829378.html

Suggestions are welcome for enhancing the Add-In and making it more robust.

Dave, David, Mark, rspahitz: Looking for more valuable comments.

Sid
LVL 30
SiddharthRoutAsked:
Who is Participating?
 
aikimarkConnect With a Mentor Commented:
1. use a GUID as the password for each Add-in you distribute.  If one is cracked, the password can't be distributed as a world-wide unlock code.

2. automate the creation of the Add-in with data that will only match the target system profile.

3. have some limitation of the Demo version that goes beyond the Nag screens.  For instance, limit the amount of time that your Demo will function to 20 minutes; maybe increase the post-nag sleep time; maybe limit the number of executions per day.

4. be wary of using system calls for license-related data.  Such calls are subject to man-in-the-middle (MITM) attacks.  You might be passing sensitive data as a parameter.

5. If you want better performance for your number crunching routines, consider creating an ActiveX DLL with VB6/Delphi/C++.  If you do this, please look at post-compilation obfuscator utilities, such as Themida from Oreans Software.

6. Send the user an encrypted license file that includes both the company name and the customer name.  Display that company name and customer name on your forms and any output, such as reports and emails.

7. See if you can leave some small bit of data in the workbooks/worksheets where your Add-in has done work.

8. Make it easy to upgrade from Demo to production Add-in.

====
Do Add-ins have to be registered?  I thought I only had to place the Add-in in the correct directory.
0
 
dev00790Commented:
Please attach the add-in, and I will have a look.
0
 
SiddharthRoutAuthor Commented:
dev00790: With enhancing the Add-In, I meant general suggestions. If you see the other thread, then you will understand what I mean.

Sid
0
Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

 
patrickabCommented:
Sid,

I realise it's stating the obvious but make sure it's been thoroughly tested by potential users before you release it.

Patrick
0
 
SiddharthRoutAuthor Commented:
Aiki

Thanks for the suggestions.

1) As discussed in the previous thread, currently a common activation ID can not be used globally since the Installation ID will always be different.

2) I couldn't understand point 2. Could you please elaborate on this?

3) Hmm, I have already thought of that. Right now the Nag screens can really make you crazy since it is getting activated at every single click in the menu. Would you still recommend more stringent options like above?

4) If you are referring to the encrypted data being passed on to the registry then like I mentioned in the previous thread, till the time you hack the VBA password, it is almost virtually impossible to decode the encrypted data.

5) I have used Custom UI Editor and Excel VBA to create the Addin. So this option is not at hand at the moment but yes, I can use that for the 2003 version.

6) The Add-in already does that from the registry. If the user messes with the registry then the user has to activate the Add-In again.

7) I couldn't understand point 7. Could you please elaborate on this?

8) Aiki, it is not a demo version like I mentioned earlier. It is a fully functional Add-In with Nag screens. The activation simply removes the Nag Screens.

>>Do Add-ins have to be registered?  I thought I only had to place the Add-in in the correct directory.

Only if you convert it to a dll. Else you have activate the addin.

Sid
0
 
SiddharthRoutAuthor Commented:
Patrick: Definitely. My client has a team who would be testing it independently plus David(dlmille) has been kind enough to volunteer to test it.

Sid
0
 
patrickabCommented:
Sid,

I'll help test it if you think it might help.

Patrick
0
 
SiddharthRoutAuthor Commented:
Definitely. :)

Sid
0
 
aikimarkConnect With a Mentor Commented:
@Sid

1. Each user will have their own activation code as well as a unique password.  The use of the GUID is just an indicator of the necessary length to discourage brute force hacks/cracks.

2. The user sends you some profile data.  You use that to generate an Add-in that contains data (in some form) that will only work on their system.  There is no need to store data in the registry.  The user replaces their Demo version with their very own version.  This is an imbeded license configuration.  Again, user-specific information (company name, customer name) should be included in the customization and displayed.

3. it depends on how easy it is to hack.  It also depends on the nag vs. cost point.  If a user can use all the functions of the Add-in in Demo mode, then the nag screens are just a minor inconvenience.  However, if the Demo mode becomes slower or loses functionality during each session or has limits, then the user will have some incentive to actually purchase the Add-in.

4. each production copy will have a unique password that should be the approximate complexity of a GUID.

7. If you place some bit of data, not normally visible to the user in the workbook, then you can further restrict the actions of the Demo version.  You could tell if the user back-dated their system.  You could limit the number of times the Demo Add-in could be used on a single workbook.  You could slow down the Add-in with each successive use of the Demo on a workbook.

8. I'm recommending that you have a separate version of the Add-in that has limits and (nag) behavior that can not be removed by an unlock mechanism.  When their payment is received, you send them a new Add-in, perhaps with a license file.

0
 
rspahitzCommented:
So is this add-in something you are selling to a client who will manage all parts of the activation, or will you be the one managing the activation?
Also, just curious if you thought of using a DotNet solution as a wrapper around the spreadsheet, which could give you a lot more power over various aspects of the project.
0
 
SiddharthRoutAuthor Commented:
@Aiki: Fair enough, let me discuss this with the client again. Initially we had just that option of restricting features and then mailing the final addin after the payment but the client doesn't want to tread that road.

@rspahitz: Client will be managing the activation. I will only be there to amend the code if there are any bugs. When I started off, I was thinking of using VSTO but the simplicity of the custom UI Editor really won me over.

Sid
0
 
aikimarkCommented:
A Demo version should always show what it can do, but always leave the user wanting the production version.

A Demo version should never be hackable to an extent that users felt they had an option to not buy the production version.  If they manage to execute past the evaluation period, the user should see the same (or more) restricted capability as they saw during the evaluation period.

Are you thinking about network licensing for your corporate customers?
0
 
dlmilleCommented:
Sid - I'm up finally - you should see an invitation.
0
 
SiddharthRoutAuthor Commented:
Thanks Aiki.

All set and rolling.

Sid
0
 
aikimarkCommented:
@Sid

What is your final configuration?
Were you able to generate the Add-in automatically?
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.