Restrict Excel Add-in Distribution -

I have an Excel add-in that we want to deploy customers. Currently it is a .xml file. I know that Excel Add-Ins is probably not the best way to distribute the software, but I have found it. My question is how do I use this add-in compared to the desired customer in other computers?

I considered the following:

1. Add-in checks exist in a vague location, if a file exists, then go to step 6 If the file does not exist, then generate the file with some random classifications of characters. And display it as a registration information to the user.
2. Then the user contacts us to get an activation code.
3. We make an activation code using some salty hash algorithm and send it back to the user.
4. The user enters this activation code in a prompt; the macro verifies and then the active code is .xlam . Stores in a protected sheet.
5. The macro then checks that the activation code in the safe sheet is valid for the code in the file if it does not prompt for activation.
6. If file and activation matches, allow access to the functionality in the add-in.

   I have the following problem idea:

   1. Where the file should be stored and the current user has not given permission to create a file at that location What should be about the machines?
   2. Would it be easy for the user to find the existence of these files? If the file is copied to another computer, the add-in will validate it and will work without any problems.
   3. If we upgrade the add-in, then this will lose the activation code. It can really be corrected easily if we use another file instead of a protected sheet to keep it safe. It is easy to install the XLA / XLAM installer, which requires installation passwords (Setup Factory, InstallShield, etc.).
      But the big problem with XLLA / XLAM is that they are easy to hack, so there is no license code safe to control embedded activation in XLLA / XLAM. It may or may be based on your target audience.
      The robust security for licensing systems will actually have to be coded into a more secure language, preferably completely compiled DLL or possibly an obscure .NET assembly. There is a wide variety of pre-built solutions available on the Net which do this.