this may very well be a stupid question, but when i was asked something much simplier then this, i didn't have much of an answer...
why are most programs installed via some several step process of adding and changing and whatnot? we have programs that can be ran straight from a self contained executable, but a large portion of programs cannot. why is this? is it due to the programs growing exponentially by needing to include everything within itself? if that is the case, it is so difficult to design an OS from the ground up to be completely modular... ie. having an OS with a standard set of modules, that can be accessed and used from any 'standalone program' that doesn't require a lengthy install.
thanks
David Kirsch.
It's really a question of how complicated your program is. Many windows programs have dependencies on Visual Studio C++, .Net, Java etc. runtimes that are not delivered by the substrate OS. This means that for your programs to work those components must already be on the system.
If those prerequisites are missing, then your program won't even load, so you can't even get your program to check for them and tell the user to go and get them. This is where an installer comes in, as it generally doesn't have any prerequisites, but is able to sniff out the ones your progam needs and can either tell you to go and get them, or try to install them for you.
Also many programs need some logical, as well as physical, installation work to be done as part of deployment. This might mean registry changes (such as COM registration), changes to IIS (setting up a web application and virtual directory), or changes to the Service Control manager (setting up Windows Services).
In short, unless your program is extremely self-contained and has no external dependencies, an installer is the only way to get your application on the desktop.
Related
Does Windows 10 support running older Win32 (MFC, ATL, Visual Basic 6) applications on ARM processors? Does it require some form of emulation or conversion?
There's no x86 Win32 emulation at all. You need to use a toolset designed for the platform.
As with 7/8.1 Windows has leaned further and further into the Net way of doing things. So many of the commandline functions are done through net calls.
Also note that Win10 is pretty much Win NT, it is basically what Win98 should have been, to save us the disasterous influx of virus's on what was an OS with a swing door and no form of protection.
That NT side of things will affect all programmers in time, particularly over the following,
The rights of your users. This is a good thing because we have all been frustrated at our users leaving the doors open for virus and hacking. NT at least helps elliminate a lot of that.
File handling. Win10 is a big step closer to an OS on demand (Which is Microsoft's current target), so we can not assume items that our software makes use of will always be locally present, so we must go through the .NET route ready for when ondemand comes in properly so that the OS will handle the demands for us. Though it does worry me that we currently have no real clues as to how that will be handled if the request can not be full filled.
But also we can not be lazy with file access rights. For example we tend to make assumptions in the user's area about access rights, then get bitten in the bum when we do a scan or search of all directories, only to find DirectoryInfo.GetDirectories is unuseable unless we make sure special folders will not stop it part way through.
Since all directories will in time be special folders, we need to be handling the access rights on the work we do now. More easily done in C++ than C# im my opinion.
So, if you have done it in 'Managed' code then it ought to go anywhere that C# and VB go, call my synical if you like, but I can not help but have doubts about that, I can not really see MS finding it desirable to have on-demand applications and OS on NET but also providing Win32 wrapped in MFC running as an alternative. You may find your code is trapped in a shrinking box.
I am supporting a vb6 application. I am trying to transfer the executable and DLL to a new server and I am prompted with component not registered errors. I have got round this by manually registering the components on the new server.
I have found two files with file extensions of 000 and 001 that have registry commands in them (registering components) Can anyone explain how these files are generated? I have experience creating installation files in vb.net to a certain extent.
Repackaging and redeployment is not a developer issue and really doesn't belong here. Such issues are more appropriate for someplace like ServerFault.
It is one thing to have lost all of the source code of an application, but even worse in some ways to have lost the deployment package. Sadly some shops fail to archive either of these.
However it was also common enough for shops to see RAD tools like VB6, Delphi, PowerBuilder, etc. as things to shove off on the worst of the worst of their developers. These poor slobs seldom got official Microsoft training that should have emphasized the importance of creating proper installers. For that matter even those courses tended to marginalize the topic. It doesn't help that the Web is full of "Mort teaching Mort" half-baked development even today, or that the pioneers who wrote many of the early serious VB programming books tended to be loose cannons and contrarians who didn't really believe deployment was a serious concern.
The end result is that lots of shops have machines with VB6 programs shoehorned onto them in a half-baked way. Often when deadlines loomed they let Old Mort install VB6 right onto the production server and let him hack away right there! So it's no wonder people get into trouble once a server needs to be replaced or its OS updated.
Those REG files with .000, .001, etc. extensions aren't anything normal that I'm aware of. For all I know they've fallen out of REGMON runs or some 3rd party packaging tool. Manual registry exports created using REGEDIT would normally have .REG extensions.
If you are actually "supporting" this application it implies that you have the source code, VB6 compiler, developer install packages for any 3rd party controls, and a writeup describing any special packaging and installation requirements (target machine DCOM/COM+ configuration, system requirements such as IIS or MSMQ or 3rd party DBMS Providers and Drivers, special folder requirements, software firewall rules, etc.).
From those it ought to be possible to compile a clean new copy of the EXE, DLLs, etc. and create a clean deployment package - even if some configuration still needs to be done manually before and after running the installer.
Without those you are a computer janitor and your question belongs over at ServerFault. It is no fun, I know. I've had to take part in such janitorial services myself all too often.
I am trying to make an application as easy to deploy as possible for Windows and I am trying to choose between packaging the application as a .exe or using an installer. I was wondering if anyone had opinions on the relative merits of either way? My preference would be to use a .exe as it would be just click and run for a user.
You should only need an installer if you have lots of components that need to be installed in specific places, or components that need to be registered for them to work (eg COM components that need to be added to the registry). An installer can obviously also add shortcuts to your app in the start menu etc.
If your app can exist as a single .exe file that can be run from anywhere in the file system, then that would be a much simpler and cleaner solution for a lot of people.
Keep in mind though, that less technical users might expect an installer and won't understand that there are no links in the start menu.
I just prefer dealing with a standalone exe, much less hassle, if you can get away with it (i.e.: you don't depend on a lot of other stuff).
It's more portable than an installer application. You can copy it from one machine to another machine, or to another folder, easily.
If you reinstall the OS, it doesn't break the application.
You can have the application itself check for existence of a desktop and/or start-menu shortcut and create them if desired (perhaps according to a preference). E.g.: Textpad does this.
I've only been doing Windows development a short time, but one issue you might run into is dependencies. If you depend on .NET 3.5, for example, what do you do if a user does not have .NET 3.5 installed on his box? In that case, an installer might work better.
In general, standalone executables are much easier to work with. They are easy to move, delete, run from a portable drive, etc due to a lack of external dependencies. If your app does not need registry settings or does not require certain libraries or helper utilities to be placed in system folders, then a standalone .exe will fit your problem.
If you do need to modify the registry, install files in different locations, create subfolders, etc, then you will need an installer of some sort. If you provide an installer, make sure you provide an un-installer as well (and make sure that the uninstaller doesn't leave behind orphan registry entries or temporary files).
To solve your problem both ways, you can have a single-file executable that is installed via an installer. That way, you get the benefits of both approaches (not to mention that the installer would be very easy to write in this case). I have also seen some apps that are available for download either as an installer or as a bare executable (let the user choose their preferred delivery option).
If you don't have any dependencies, don't have to add/change data in the registry, don't have to clean after your application removal/update, then using just an .exe seems quite reasonable.
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
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.
Heavy emphasis on simple. I've never made an installer and I'd rather not have to learn much. A system that I could hand a pile of files to and it would make some smart guesses about where to put them would be ideal.
Go ahead and answer the general question.
However In my cases I'm stuck with some extra constraints. The program to be installed is written in VB6 (or is it 5?) and a few previous versions of VB, so it's not going to be updated any time soon. I have a running install and will have a Clean VM to play with So I'll be doing a loop of: run the install, find where it's broken, fix it, add that to the installer, revert the VM, try again. If anyone has a better approach I'm open to suggestions.
I MUST get it working on XP and I'd really like to also have something that will work on newer versions of Windows as well.
InnoSetup or NSIS, whichever seems easier to you. ISTool is a nice GUI tool for InnoSetup which makes creating setup scripts even easier.
I've used InnoSetup several years ago, before Vista, and was very happy with it then. I only had a few files to install and a Start menu icon. It worked great, and was easy to learn.
Dependency Walker is super useful for finding out which dll is missing from the installer. Once you know the dll, you can find what merge module it is in using the Merge Module Finder.
I have worked with NSIS and getting past some of its minor complexities its a fantastic system. its free, offers tons of plugin ability and managed to do everything I needed to do.
Creating a full setup package for a program is almost a subject area in itself. There are many factors to consider and most of us aren't running Windows 95 anymore. The world is not as simple as it once was.
There are a lot of things that need to be addressed, and some of these "setup" issues mean changing the program too. For example the "protected folders" concept that seemed to be new to people when Vista UAC came on the scene. I guess they were all running as admin or something? In its simplest form it means you don't put writeable files next to the EXE in Programs (aka "Program Files") anymore.
Another factor is that the way the registry is used has changed. I'm not talking about registry virtualization, though that's part of it as well. But COM registration can be done both per-machine and per-user and even turning UAC off can muck this up. See Per-User COM Registrations and Elevated Processes with UAC on Windows Vista SP1. The result is that a setup package shouldn't be running regsvr32 (or otherwise calling the self-reg entrypoint of a COM library). See "Remarks" at SelfReg Table.
Windows Installer is the way to go forward in most cases. VB6 programmers have Visual Studio Installer 6.0 version 1.1 available as a free download for creating MSI packages. See "COM Servers" at the VFP article Using Microsoft Visual Studio Installer for Distributing Visual FoxPro 6.0 Applications for some valuable information.
This isn't the easiest option but there is a VB Setup Wizard in VSI 1.1 to help get the basics right. Doing advanced things like creating a [CommonAppData] subfolder and setting Everyone rights on it has to be done in a post-build step outside the IDE. That's where 3rd party tools can be useful to give you more control without resorting to Orca or post-build Installer scripts.
Those guys making scripted "legacy" installers try to keep up, but the scripting gets more and more complicated. The results are sometimes iffy. Windows 7 introduces a few new wrinkles of its own.
While ClickOnce isn't really the best option for VB6, nothing says you can't use reg-free COM for XCopy installs of many programs. Reg-free COM can even be a good option for use in an Installer package for that matter.
So in the end the "simplest" way to deploy VB6 programs is probably going to be reg-free COM XCopy packages wrapped in a self-extracting EXE that will fire off a script to create a Start Menu shortcut. If you can live without the shortcut this is even easier: just unzip the package where it needs to go!
See Make My Manifest or alternative tools for reg-free COM packaging.
This requires that the target systems be running XP (preferably SP2) or later. The only possible glitch here is that XP did not include the VB6 SP6 runtimes until XP SP3, so you'll want to test your program against the VB6 SP5 runtimes first. Well one more glitch: you can't use ActiveX EXEs this way, they still require registration.
My advice is this. Try to keep the installer as simple as possible. Windows Installer is a very complicated piece of software and when things don't work right it can be hard to figure out what's going on. I'm sure we have all experienced the endless loop of Windows Installer trying to repair a file that you no longer have the source .msi file for.
Most of the time using Windows Installer is like using a sledge hammer to crack a nut.
I use InnoSetup for my own stuff and InstallShield at work (against my will). Start with a simple script based installer and only use Windows Installer if you have a good reason to.
Note that support for installing assemblies to the GAC may be missing for some non Windows Installer setup tools (such as InnoSetup).
I used to LOVE Inno Setup. Emphasis on "used to".
When you run the single file installer (what you'd typically do), it unpacks the real setup program into a folder under the temp folder and then tries to execute it. The problem is... some anti-virus programs don't allow this.
The author is aware of this and refuses to do anything about it. The folder name is random, so cannot be added to any exemption list your anti-virus program may use.
Again. The author is aware of this and suggests that I tell my users to turn off their anti-virus programs during installation. (Like that's going to happen)