This question already has answers here:
How can I make my product as a trial version for 30 days?
(11 answers)
Closed 9 years ago.
I am curious as to how some applications know if my trial period is over. Even if I uninstall the software, and reinstall it, how can the software know if my trial period is over ? Simple tricks like changing the date and time are futile.
The question is simple. What are the possible ways for an application to know that ?
Thanks in advance.
There are registry values written in the windows registry Including the dates for installation and other details. Am not sure what you want to do but mostly this is what they do. Even after you uninstall the software, the registry values for the application are left in the registry.
So to answer your question: The Application uses the registry entries to know that your trial period has expired even after you remove the software and try ti re-install.
Related
This question already has answers here:
MSI register dll - Self-Registration considered harmful
(4 answers)
Closed 7 years ago.
I am building an installer and use heat.exe to harvest all the required files. however I need to register some DLL and OCX files, I looked around how to do it bud there seems te be some debate aboud how to implement registering those files, on stackoverflow as well as on other websites and forums.
I would like to use the following: SelfRegCost="1" since it looks like the most simple way to register files. bud people dont like it because it could give problems when repairing or uninstalling the program.
what is your opinion regarding this method and what would you suggest me?
a example of the code implementation recommended would be highly appreciated.
thanks in advance.
Simply put, any form of self registration (COM being one of them) is an antipattern. There are various reasons a few of which are:
1) They add fragility to the install
2) They can halt a silent install when they fail.
3) They don't log any information on why they failed.
4) They are out of process; the installer isn't aware of them (no repair)
5) They break the transactional nature of Windows Installer (no rollback)
6) They slow the install down
7) They hide implementation details and can't be observed or transformed
I'd go so far to say this isn't a matter of opinion but rather a matter of best practice facts. But I suppose at the end of the day best practices are just opinions also. Still, I've authored thousands of installers over the last 20 years and I can say without a doubt that self registration should be skipped whenever possible. Instead use Heat to "harvest" the COM meta data and author it into your wxs code so MSI can handle this natively for you. There are other tricks that can be employed if Heat is unable to get all the details.
Finally, don't use COM whenever possible. For example you could consider using a RegFree COM manifest instead to simulate the registration of the component.
See: Do not use the SelfReg and TypeLib tables.
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 8 years ago.
Improve this question
I'm writing a front end application in MS Access 2010 saved as a standard accdb which users will only be able to use Access runtime to open. Our IT department has kindly installed the 2013 runtime rather than the 2010 runtime on a test machine for me to check my development on.
I'm having some issues getting anything to show in Runtime on this machine, yet when I use the /runtime switch in a shortcut on MY machine, everything works as expected. What is happening on the test machine is a dialogue warning of "A potential security concern has been identified" comes up with OK and Cancel. If I click on OK, the database opens as far as I can tell, and code that's in the form_open event of the startup form runs (checks to see the location of the file isn't a network drive to ensure that users copy the front end to their desktop) and a version control query to match the client with the latest version of backend. However the form never appears, and I get no errors/crashes or other unexpected events.
What could I have done wrong, or is it connected with the security warning? My gut says that's a red herring as the location check and version checking code does run, ie if I run it from the network drive then it gives the msgbox it was meant to.
Many thanks, this is my first time using runtime.
After several days of searching, I've finally solved the problem.
I had been developing on a laptop with a second screen connected. For some inane reason, Access remembered this, and decided to display the form on the second screen. Unfortunately, my users don't have a 2nd screen.......
Selecting Auto Center=Yes in the form properties solved the problem entirely.
One of my duties at my job is to enhance and maintain a mature VB.Net windows application used internally by my company. We run 8 computers at the small company that each runs the app with no problems.
Recently we replaced one of the computers with a pretty standard notebook running Win 7 Professional with SP1 and for some reason, it won't display message boxes displayed using the normal MessageBox.Show("Message") method.
The vendor who sold us the computer says it must be the program, and I kind of sympathize with that view, but the fact is we have 8 other computers that all display their message boxes just fine.
Thought I'd post the issue here to see if anyone else has run into this and, if so, did they find a resolution?
I'm going to paint outside the lines a little bit and answer my own question with sort of a non-answer.
We battled that computer for about a week and a half and finally gave up and reinstalled the OS. Problem solved. Not really an answer because we still don't know what was going on or why reinstalling the OS fixed it.
Reinstalling was really an act of frustration/desperation as much as anything else. In the end we were just thankful the problem went away and we could move on. Figured I'd get this off of the unanswered questions list since I'm not really waiting for or expecting an answer at this point.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Microsoft is moving away from the Visual Studio built-in MSI setup projects. WiX seems to be one alternative. But the tutorials I've found for WiX are all about five years old. For example, WiX: Hints for New Users (Part 1 of 3) is one from 2007.
Are there newer/better tutorials for WiX?
That article and others mention Votive as a way to create and edit WiX files.
Is Votive still an active project?
WixEdit claims to be the only active project for a WiX editor, but it isn't integrated into Visual Studio.
Should I use WixEdit or Votive?
Here's an answer I've posted before here. I'm not going to update it except to add Joy of Setup (from bob-arnson) and all the links in his blog sidebar will also be of use, less so in learning from scratch but very useful in knowing more once you get up to speed.
I dove into WiX about 4-5 years ago and it took me a good 6+ months before I felt I knew what I was doing and 12+ months to feel confident. There is a LOT that could be done to make it easier to get started from scratch - but the problem that most people don't realise is that if first you learn Windows Installer/MSI, then WiX is damn simple.
Go pick up a copy of The Definitive Guide to Windows Installer. I've lost count of how many times I've recommended it to people who are getting stuck on the concepts and are struggling to understand how Windows Installer works. Make sure you grab the Windows Installer SDK as well.
Getting to grasp with Windows Installer is the first stage of your learning, once that's sunk in you'll understand how InstallShield works (or doesn't work as the case may be..). Wise, InstallShield, etc try to shield you from the underlying concepts and have their own trickery/hacks to get around the limitations of Windows Installer.
Stage two (if you're serious about understanding Windows Installer) is learning WiX (The WiX Tutorial isn't too bad, although it's a bit out of date and targeted at WiX 2.0 rather than 3.0) and joining the wix-users mailing list. Don't join the users list until you've finished the book mentioned above, you'll be well in over your head. Questions from those who don't understand the Windows Installer concepts largely go ignored, however questions from people who have done their homework will find it a great resource.
What's not covered in the book is Vista, Robert Flamings blog entries on Understanding UAC and Vista (written when Vista was in it's beta stage) are the best information you'll find on the topic.
One thing that both the Windows Installer and WiX teams is really good at is keeping the documentation (Help files) up to date. Whenever I'm working on setups I'll generally have Wix.chm and Msi45.chm open on one monitor ;)
Along with the documentation, blogs from people on the WiX and Windows Installer teams are great for learning new tricks, etc. Far too many to list here, but once you know the terminology you'll find most of them popping up in google results.
If this all seems too much, then check out NSIS. Great for simple "I just need to copy files" type installations, not so great for enterprise deployments. If you're torn between the two then maybe go take a look at Rob Mensching's old blog when setup isn't just xcopy. Articles there are probably what convinced me that diving in and learning the underlying Windows Installer concepts would pay off in the long run. And it has :)
Update - since my original post, WiX: A Developers Guide to Windows Installer XML has been released and is also a good resource for beginners. (I didn't find it that great myself though.) I still suggest reading The Definitive Guide to Windows Installer as a starting point. Windows Installer and WiX isn't something you just pick up in a few days, it'll take a few months.
Download WiX and look at the tutorials in the manual (which is also installed as a .chm). When you install WiX, it will install the necessary files and templates so that it integrates nicely with Visual Studio.
Note: Every tool in WiX begins with a letter that helps signify its use. Votive is just the piece that integrates with Visual Studio.
Examples:
Votive = Visual Studio
Burn = Bootstrapper / Bundle
Candle = Compiler
Light = Linker
I used the book WiX: A Developer's Guide to Windows Installer XML to get up to speed with WiX.
You can get Visual Studio integration from the WiX home at CodePlex.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Is there an actual TideSDK tutorial that is not a remnant of the old Titanium Desktop? I can't seem to locate any clear tutorial that outlines coding to testing to building on TideSDK. Most of the things I've seen are intended to be used for the late Titanium Desktop. If anyone can outline the app creation process of TideSDK, it would be more than welcome. (E.g. Code, compile test? / Code, test, compile?)
Downloads from the TideSDK.org site currently provide Titanium Desktop 1.2.0.RC4 in the interim while the TideSDK Team continues to prepare for the upcoming 1.3.0-beta release (that is expected quite soon). Therefore, the legacy documentation from Appcelerator can still be used for getting you started on your desktop projects today. If you run into any issues there are friendly people on our mailing list to help. The only change in the API for 1.3.0 will be the change in the namespace from 'Titanium' to 'Ti'. Please consider joining the TideSDK mailing list https://groups.google.com/forum/#!forum/tidesdk for assistance or follow us on Twitter http://twitter.com/tidesdk to keep up to date on TideSDK news and announcements.
Keep in mind we've been working through a transition with the legacy code and materials. It is a significant effort to assemble a capable and dedicated team, work through the complex code base, set up continuous integration infrastructure and organize the efforts the team is currently engaged in. Our repository on Github has grown from a couple of repositories to 48 over the past few months. The team is continuing to clean and organize the code that we inherited from Appcelerator so that it is possible to build upon it for the future. We are also striving to become a non profit organization as funding to support the team of 16 programmers, developers and UI designers and for the infrastructure we need for such the project. This is an important key to our success for the future.
The TideSDK team has been putting substantial effort into high quality documentation under the direction of Christian Engel, our Developer Education Lead, in anticipation of the upcoming release. TideSDK's documentation consists of API docs together with a series of Guides. A Guide is focused on a particular topic. In some cases, Guides serve as focused tutorials. To view the documentation under development, visit the brand new tidesdk.org site (launched at the end of August 2012) and click on the docs button. In the short term, the effort has been on API docs and code examples. This effort will shift to Guides quite soon.
No new features will be added for the 1.3.0-beta release but it will provide updates to the underlying libraries. This will enable the SDK to compile and be used on OSX Lion, OSX Mountain Lion, Ubuntu 12.04 and Windows 7 and 8. Scripting language versions are being brought up to date also. Perhaps the most significant thing it will upgrade the WebKit to the lastest available. This will mean the most current HTML5 support available.
TideSDK-1.3.1-beta is available. Please use this the most recent version of TideSDK found here
http://tidesdk.org
and refer to the Getting Started Guide located at:
http://tidesdk.multipart.net/docs/user-dev/generated/#!/guide/getting_started