This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Setting up Try and Buy Installation
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 12, 2007
09:22 AM
Setting up Try and Buy Installation
Sometimes I would like a set up application to state the steps to set up a functionality.
1. You want to do trialware, here are the steps.
2. You want to do trialware, but have more than one edition of software and each exe is only installed based on a licence key entered by the user. Okay, here are the steps for that.
I know I should not be yelling on this, but I am wee bit frustrated with this right now and for the life of me cannot get this to work.
So this is what I have
I have four flavours of our application, and each flavour has the same exe file name, so I have set up a component for each of those files to distinguish between each edition. So far that has worked out very well for me, and now I need to add in try/buy to the mix.
1. I was in the trialware section and added in a new trialware file for each edition exe.
2. Tried to build it and it gives me a 7102 error code, and says it occured while wrapping myfile.exe3 which corresponds to my enterprise edition of our software.
No offense, but the error codes and messages that go with them are pretty cryptic sometimes and this one is no different. Hence that is why it would be great to have steps for different scenarios. 🙂
Anyways, less of that, can any one put me out of misery and give me a basic example of setting up try/buy on a installshield2008 project.
🙂
1. You want to do trialware, here are the steps.
2. You want to do trialware, but have more than one edition of software and each exe is only installed based on a licence key entered by the user. Okay, here are the steps for that.
I know I should not be yelling on this, but I am wee bit frustrated with this right now and for the life of me cannot get this to work.
So this is what I have
I have four flavours of our application, and each flavour has the same exe file name, so I have set up a component for each of those files to distinguish between each edition. So far that has worked out very well for me, and now I need to add in try/buy to the mix.
1. I was in the trialware section and added in a new trialware file for each edition exe.
2. Tried to build it and it gives me a 7102 error code, and says it occured while wrapping myfile.exe3 which corresponds to my enterprise edition of our software.
No offense, but the error codes and messages that go with them are pretty cryptic sometimes and this one is no different. Hence that is why it would be great to have steps for different scenarios. 🙂
Anyways, less of that, can any one put me out of misery and give me a basic example of setting up try/buy on a installshield2008 project.
🙂
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 12, 2007
04:34 PM
Just as a sanity check, does the name of the file that you are trying to wrap really have a "3" after the .exe part (myfile.exe3)? The trialware functionality supports only .exe, .dll, .ocx, and .scr files.
Also, the "Build Errors and Warnings" help topic does have some troubleshooting tips for this error:
I hope that helps.
Debbie Landers
Macrovision Corporation
Also, the "Build Errors and Warnings" help topic does have some troubleshooting tips for this error:
InstallShield cannot wrap .NET or Java files for the Try and Buy/Product Activation or Try and Die types of trialware. In addition, InstallShield cannot wrap files that were created with applications such as PowerBuilder, which uses interpretive languages. Also, InstallShield cannot wrap NT services.
To work around this issue, you can create a traditional Windows-based .dll file:
With this workaround, when an end user tries to launch the executable file, the executable file calls the protected .dll file, which triggers the trialware technology.
To work around this issue, you can create a traditional Windows-based .dll file:
- The .dll file should contain a function that is called by your product’s executable file.
- Wrap the .dll file with the trialware protection in InstallShield.
- Obfuscate the function call to make it difficult for unscrupulous users to create their own versions of the unwrapped .dll file in an attempt to work around the trialware protection and use your application or NT service without having to activate it.
With this workaround, when an end user tries to launch the executable file, the executable file calls the protected .dll file, which triggers the trialware technology.
I hope that helps.
Debbie Landers
Macrovision Corporation
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 12, 2007
04:46 PM
DebbieL wrote:
Just as a sanity check, does the name of the file that you are trying to wrap really have a "3" after the .exe part (myfile.exe3)? The trialware functionality supports only .exe, .dll, .ocx, and .scr files.
Also, the "Build Errors and Warnings" help topic does have some troubleshooting tips for this error:InstallShield cannot wrap .NET or Java files for the Try and Buy/Product Activation or Try and Die types of trialware. In addition, InstallShield cannot wrap files that were created with applications such as PowerBuilder, which uses interpretive languages. Also, InstallShield cannot wrap NT services.
To work around this issue, you can create a traditional Windows-based .dll file:
- The .dll file should contain a function that is called by your product’s executable file.
- Wrap the .dll file with the trialware protection in InstallShield.
- Obfuscate the function call to make it difficult for unscrupulous users to create their own versions of the unwrapped .dll file in an attempt to work around the trialware protection and use your application or NT service without having to activate it.
With this workaround, when an end user tries to launch the executable file, the executable file calls the protected .dll file, which triggers the trialware technology.
I hope that helps.
Debbie Landers
Macrovision Corporation
Debbie,
That is the key of how it is id in installshield, really it is .exe, I am tracking down to see how the exe was built. I don't believe it is a .net application (I did not build the app, was done by an outside vendor). Funny thing, I compiled a .exe using vb6 and that kind of work.
Kind of work in that it prompted for the key to activate it, but either I am doing something wrong with some other settings, but it never expired on me like the way I thought it would.
I set the type of trial limit to uses
Trial Limit Qty was set to 5
and expiration date was set to 12/13
Although compliing the vb6 exe was just a test, it is not the actual application, and therefore for whatever reason I can wrap the trialware around my app .exe.
I don't know what it was built with, but from what I understand it is an old app, supposedly still 16 bit. So would that have anything to do with it?
I did read about the .net issue, and tried setting it to a dll that is in the application, but that didn't do anything.
I will still plug away with it.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 12, 2007
05:08 PM
Hmm. So you set the trial limit to 5 uses and added an expiration date. Then you built the trialware and installed it. Now every time that you try to start your application, you see one of the trialware run-time dialogs that asks you if you want to activate. Each time, you specify that you don't want to activate, you just want to evaluate. Is it correct that you never enter a serial number, that you are always "evaluating"?
What happens when you try to start the product for the sixth time? Do you get another trialware run-time dialog that asks you if you want to activate?
What happens when you try to start the product for the sixth time? Do you get another trialware run-time dialog that asks you if you want to activate?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 12, 2007
06:16 PM
DebbieL wrote:
Hmm. So you set the trial limit to 5 uses and added an expiration date. Then you built the trialware and installed it. Now every time that you try to start your application, you see one of the trialware run-time dialogs that asks you if you want to activate. Each time, you specify that you don't want to activate, you just want to evaluate. Is it correct that you never enter a serial number, that you are always "evaluating"?
What happens when you try to start the product for the sixth time? Do you get another trialware run-time dialog that asks you if you want to activate?
I figured that part out, tis call reading the screen when it comes up the first time, ratherthan doing the obivious which was enter in the licence code to activate the app. So in that respect, it worked correctly for the temp exe that I created. :).
That aside, I find out that the actually application was written in MFC C++, so would that mean that the trialware would have trouble with the exe that it is trying to wrap itself around? If so, then I am assuming the only solution then is the .net solution that you called out in one of your previous posts.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 13, 2007
01:52 PM
jjb8297 wrote:
I figured that part out, tis call reading the screen when it comes up the first time, ratherthan doing the obivious which was enter in the licence code to activate the app. So in that respect, it worked correctly for the temp exe that I created. :).
That aside, I find out that the actually application was written in MFC C++, so would that mean that the trialware would have trouble with the exe that it is trying to wrap itself around? If so, then I am assuming the only solution then is the .net solution that you called out in one of your previous posts.
Just found out, guess I was wrong on it being MFC C++, but it is C++ and is .NET c++ so it falls under the fix that you called out above. Thanks again for your help.:)