I am a newbie and not familiar with the setup environments and stuck at some point. I am developing a very simple database application using visual studio 2010. I want to release a demo program and want the demo setup to be executed just one time for a specific computer hardware. For example when one user downloads the demo and installs the setup, the demo setup content, a simple configuration file embedded in the setup or "what so ever I do not know" should be changed, so that setup (when coppied to another computer) could not be used in other computer hardwares.
The sollutions or design ideas for this specific problem should not include any online services checking that the user executes that install or not. All the problem should be solved locally if possible :) and be as generic as possible.
Any design ideas or a starting point
will be very appreciated.
Thanks in advance
This is not possible of course. Whatever breadcrumb you leave to record that the program was ran has to be left on the same machine. Leaving any user with sufficient skills or good enough tools (like SysInternals' ProcMon) to find out where you dropped it and remove it again. Assuming they care enough about making the effort.
The simple solution is to intentionally cripple your demo so that an important feature is missing that would make it useful. Like File + Save. Not just disabled, completely missing in the code as well so hacking the demo program doesn't work either. Easy to do with an #if directive in your source code.
Related
i have made a windows application with a build in button with using visual studio as my application maker and virtual basic as my language.
i need help making the button change a registry folder in the hive due to one of our program that we got has a bug and the folder is miss named..
[Hkey_local_user\software\microsoft\(ERX). It needs to be ETRX
i know how to change it manually but cant be doing this to all 68 computers ,that is a big no-no and will take a long time.
can someone make me a blueprint on how i need to make this am not much of a programmer type plus no link helps me.
Don't want to sound lazy or unhelpful, but this link will explain it clearer and faster!:)
http://social.msdn.microsoft.com/Forums/vstudio/en-US/5b22e94c-37a9-4be5-ad55-3d9229220194/how-to-use-add-read-change-delete-registry-keys-with-vbnet?forum=vbgeneral
A small ma and pa shop came to me recently with a request to update a vb6 program one of their former part time employees made for them while home from college. On the cd the student provided is both the source code and a installer for the program, which extremely helps. I would like to just give them a new cd with a new installer and the updated source code. My question is, how do I go about creating or if easier updating a installer for a language that entered "Non Supported Stage" back in 2008?
Update:
Just to answer some of the questions, the updates they are asking for are just changing the wording of some labels and changing one control from a textbox to a combobox. They are a ma and pa shop and don't want to pay the cost to have the app re-written to a newer language, even though it has been recommended.
You're going to need a copy of Visual Basic 6 (or Visual Studio 6) which is difficult. If you have an MSDN subscription, I'm quite sure you can download it from their archive, but if not, you might need to buy a copy. Check EBay. Have the ma and pa shop purchase it at their own expense, and they should own it in case they want to make future changes. You can use it on their behalf to do work for them, if you're the only one using it, and just uninstall it when you're done.
Also, if you have a copy of Visual Studio 2005, technically you can "downgrade" to VS6 but you have to call Microsoft and have them send you the install program, and you're not allowed to use VS2005 concurrently with VS6. Yeah, I know...
Ok, so if you've got that far, get the source on your computer and get it under source control. I suggest Mercurial (specifically the TortoiseHg client). I've had lots of luck with it on a VB6 project, and it's free. (Don't use SourceSafe, even if it comes free with VS6!) The distributed nature of the Mercurial repository means you can hand them back a CD with the entire repository on it, and the next poor sap who has to make changes will at least be able to do a diff and know what you did.
As someone else here said, VB6 has a built-in utility for making install programs, but I think you had to have the Enterprise version for that. It's worth finding that out before you get a copy.
Now go ahead and make changes, but be very careful. Remember that you probably don't have any unit tests, so you're likely to break stuff. If you want to be professional about it, there are unit testing frameworks out there for VB6. For instance, vbUnit. Again, I suggest having the customer buy a copy (about $99 for a single developer seat, I think). If the change was anything more than changing the company logo on the splash screen, then this is something I'd invest in. Write tests that cover every module or feature you're going to change. If all the logic is in event handlers in the form itself, carefully remove the code you need to change out into modules that you can write unit tests for. Write the tests to verify the current functionality first.
Then go ahead and make your changes. If you've gone to the trouble of setting up a testing framework, then you might as well use some TDD and write your tests first. Write a test, make sure it fails, write enough code to make it pass, and repeat.
All of this still requires you to have a solid manual test plan to check the functionality at the end. That means you need a solid grasp of what it does. You can pretty much assume that no matter how careful you are, you'll break something you didn't understand. Make sure to give yourself enough time to fix other problems that pop up after you deliver it.
I recommend against re-writing it in .NET unless it's a really simple program with only one form. The effort likely isn't worth it.
Caveat: beware of 3rd party components the original programmer might have used, but not included on the CD. If they used some ActiveX or COM stuff that they purchased from a 3rd party, but they didn't license it to your customer, you might have to end up purchasing it again just to get it to compile.
EDIT:
Based on your extra information, if you're really just changing a couple of controls and wording, then I think you can get away without a unit testing framework. I would definitely use some source control though.
I do remember using the Package and Deployment Wizard, and I agree it sucked. I actually used a 3rd party installer, now that I think about it. However, if the changes are small and the original application used the PDW, I'd probably stick with that.
You Can Convert VB6 projects to .NET.
If you have Visual Studio 2005 or higher...
Or the worse case is re write the code using VB.NET.
Go to this Link.
Convert VB6 - .NET
If I recall correctly, Visual Studio 6 came with a rudimentary wizard for creating an installation program for a VB6 application. So, assuming that you have Visual Studio 6 installed for VB6, there should be an installer wizard that you can use. However, it may have problems deploying the VB6 runtimes on Vista or Win 7 machines. Perhaps another SO guru will have the answer to that one.
You can also use the freeware Inno Setup to create an installer for a VB6 application. More information can be found here. However, it requires more manual effort than what came with Visual Studio.
Microsoft's "Windows Installer CleanUp Utility" could be used to help fix broken installations of MSI-installer based products. When the installer failed in some strange way and left corrupt data behind, so bad that even Add/Remove Programs couldn't help, you could often fix things by running this utility and then running the application's installer again.
I just discovered that Microsoft announced a couple weeks ago that they were discontinuing this utility. They didn't merely say "we're not supporting it anymore"; they seemingly removed it from their site entirely.
I have to support a Windows program for a whole bunch of users. Given the number of users, every so often something will go wrong, and this program has been invaluable for me, as a last-ditch line of defense.
I know I could point customers to some third party site that has a cached copy of it, but this seems dangerous (malware potential and such).
So, are there any replacement products? Or, if not, how can I myself do whatever it is that this program did?
To be clear, I'm not asking for help like "how do I programatically modify the registry". I can do that fine. But I need to know what in the registry needs to be modified.
Thanks in advance.
Windows Installer CleanUp utility was never intended to be used in the wild. It was only meant to be used by software developers. If you occasionally have end users needing to use WCU you have some serious installer quality issues that should be addressed.
WCU only removes the Windows Instaleller meta data and doesn't actually uninstall any software. This leaves the machine in a very dirty state. These days with test labs becoming virtualized there's no reason to have this tool anymore. You just roll back to a prior snapshot and keep on working.
I've seen all kinds of online forums full of users who think they know what they are doing ( and don't ) suggest using WCU to solve various problems so in the end Microsoft decided to try to get the horse back in the barn.
I have old copies of WCU archived in my CM system so if you'd like me to generate checksums to help you determine if you are getting a good copy just let me know.
The cleanup utility was a wrapper around the command line utility msizap.exe, described here:
http://msdn.microsoft.com/en-us/library/aa370523%28VS.85%29.aspx#1
We've got a desktop product, made up of a Win32 service, a notification icon application and associated DLL files.
I've been tasked to look at making it auto-update. We could write our own updater, but before we do that, I'd like to see what else is out there. Are there any commercial systems (similar to Windows Update, I guess) that we could use? I'm sure that InstallShield used to offer something like this, but I can't find it now, and it's possible that my memory's failing me.
It's a Win32 application (and a service), so ClickOnce is out (or is it?).
Have a look at Google's Omaha project.
I once looked into using it. But I eventually realized it would be easier to re-invent the wheel than to learn everything that goes into making Omaha work. Unfortunately I have yet to find a generic solution. Most project's I've looked into tend to build their own updater.
Which is bad, because everyone tends to make the same mistakes over and over again. Doing secure updates isn't trivial. Read this:
Auto update: Is this secure?
I also find it rather annoying how every auto updater thinks it needs to be running 24/7 in my system notification area.
I would venture to say that one of the main advantages of of the app store model is that developers don't have to worry about building an update system.
I highly recommend GUP: https://wingup.org/
It's the automatic updater developed by Notepad++ author and it's completely opensource.
You might want to use this solution. Source code (c++) included.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I recently had to struggle with one installation project (which uses most popular product for creating installations: InstallShield) to make it work for product upgrades (migrating from one version to another). In the end it turned out that I needed to use one long package code but was using some other. It wasted my 8 hours (testing and debugging installers is a pain).
Now if I think about it, once you are done all the hard part of coding, all you want to is that correct applications, libraries are copied to target computer and user just runs it. Period. This apparently simple task normally turns out to be a tricky one and "being closed to finish date" makes in even harder.
Don't you think deploying a product is made damn difficult on windows which should have been simpler? (or installer really deserves that much attention and I am just being crazy about it?)
Have you ever used simpler deployment schemes such as "copy the folder to wherever you like and run the exe. When you want to remove it, just delete the folder!"? Was it effective and made things simpler?
Painful as it is you need to wrestle with the windows installer for the benefit of your customers. Otherwise you will need to do a lot more work to
Handle situations where for some reason an error occurs during the installation. What do you do next?
Handle issues like security. What if the installing user does not have rights to particular folders/registry keys?
Correctly cleanup after installation
Patching and patch management
Performing additional tasks -- registering COM objects, creating databases, creating shortcuts, creating an un-installation shotcut and so on
Installing prerequisites
Letting users choose which features to install
Your own custom scripts to solve all these problems eventually become a bigger problem than the installation itself!
I recommend that you check out Wix. It's not exactly child's play but it gets the job done. If you install Votive as a visual studio add in you get intellisense to help you strucutre the tags correctly. With the help file you can create pretty functional flexible installations
I don't think you'll see too many disagreements here, especially regarding MSI. I think one thing to keep in mind is to watch the way many programs are using MSI files these days. Displaying UI dialogs and making complex configuration choices with an MSI is very weak simply due to the way Windows Installer was designed, so I've noticed a lot of programs being split into a bunch of baby MSIs that are installed with the minimal UI by a parent setup program. The SQL Server 2008 setup wizard does this. UPS WorldShip does this. And Paint.NET does this, too--the wizard you see is a Windows Forms app, and it launches msiexec itself (you can see the minimal UI of the Windows Installer pop up on top of the white wizard window), passing any configuration parameters as property arguments to msiexec.
A common scenario where this comes up is where someone is tasked with building an installer for an application that has both server and client counterparts. If the user chooses the server option, then they may or may not want a new database to be installed, which means installing SQL Server. But you can't just install SQL Server while you're in the middle of your own installation because Windows Installer won't let you do that. So a frequent solution is to write an app that displays a wizard that allows the user to configure all of the setup options, and then your app launches the MSI files as needed for SQL Server, your server application, and your client application in the minimal UI mode; basically, eschewing the "features" aspect of Windows Installer entirely and moving it up to the MSI level. 4.5's multiple-package installations seems to be a step further in this direction. This format is also especially useful if you also need to loop in non-MSI installers from third parties as part of your installation process, like installing a printer driver for some bizarre point of sale printer.
I'll also agree that Windows Installer lacks built-in support for common deployment scenarios. It's meant for when setup isn't XCOPY, but they seem to miss the fact that setup usually isn't just "files + shortcuts + registry keys," either. There are no built-in actions for setting up IIS Web sites, registering certificates, creating and updating databases, adding assemblies to the GAC, and so on. I guess they take the opinion that some of this should happen on first run rather than being a transactional part of the install. The freely available tooling and documentation has been awful--flat out awful--for the better part of a decade. Both of these issues are largely addressed by the WiX project and DTF (which lets you finally use managed code custom actions), which is why we're all so grateful to Rob Mensching and others' work on that project.
I've had the same experience. Installation can quickly suck up your time as you go down the rabbit hole of "Oh God, I guess I have to become an expert in this too." I second the idea that's it's best to address it early on in your project and keep it maintained as part of your build process. This way, you can help avoid that scenario of having developed a practically uninstallable product. (Trac was an example of this for a while, requiring to track down specific versions of weird Python libraries.)
(I could go on about how Windows Installer sometimes decides to use my slow, external USB hard drive as a place to decompress its files, how it seems to sit there doing nothing for minutes on end on computers that have had lots of MSI installs on them, and how that progress bar resetting itself a bazillion times during a single install is the most idiotic thing I have ever seen, but I'll save those rants for another day. =)
My two cents; please note that I really just know enough about Windows Installer to do damage, but this is my assessment coming from a small business developer just trying to use it. Good luck!
Well, its a lot easier if you build your installer first, make it part of your build system, and let it grow with your project.
I agree, the windows installer drives me insane. But there are a lot of situations that xcopy just doesn't solve. Sometimes you want to install for multiple users, not just the current user. Sometimes you have to register COM objects. Sometimes you have to make a whole bunch of changes to the system, such as registering services to run at startup, connecting to network servers, etc. Sometimes you have users that can't use a command prompt. And you always want to be able to role the whole thing back when something fails halfway through.
Was the whole MSI database approach the best way of doing it? I'm not sure. Would I rather pound nails into my head than write another line of WiX code? Probably. But you have to admit, it does a good job of doing everything you could ever possibly want. And when it doesn't there is always the CustomAction option.
Really, what I would like to see, is better documentation (really, what is a type 50 action? How about giving it a name?) and a lot more easy-to-usurp templates.
And the WiX users group alias does a good job of answering questions.
You should read RobMen's blog. He does a good job explaining why things are the way they are. He has done a lot of thinking (more than any human should) about the problems of setup.
Have you looked at NSIS: http://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System ?
And 1: Yes, 2: No
Personally, I mostly agree with #Conrad and #John Saunders. I wrote about this topic a long time ago on my old blog. I think #jeffamaphone has a point about the Windows Installer complexity (and my over attention to setup, in general ) but I believe the Windows Installer is still the best all round option for installation on Windows.
"Once you have done all the hard part of coding", you haven't done a thing if all your hard work doesn't install. Installers need to be built and tested on every nightly build, every night, almost from day one. You need to test that the installer can be built and run, and you need to verify the installation.
Otherwise, who cares how much hard work you've done coding - nobody will ever see your work if it doesn't install!
Note that this also applies to XCOPY.
Another thing: what is your QA testing if they're not testing what your installer installs? You have to test what the customer will get!
For exactly the reasons you state, we've done internal releases, handled by the dev team by copying the required files, and then done the rest of the setup using scripts and our own utilities.
However, for end users you have to have some kind of hand holding wizard, I've used the MS installer from within VS and found it confusing and clunky. After that experience I've avoided the pain by getting others to do the installation step. Can anyone recommend a good .Net installer?
I use Installshield and if you are not trying to do anything too fancy (I why would you) then it's pretty straighforward - set initial setting, select files, set up shortcuts and create setup.exe.
All future updates I handle inside my code - much more convinient to the user