Is there a tool I can use to monitor registry changes that are made during installation of some software package?
I need to create an InstallShield installer including Crystal Reports runtime, and my prerequisite that works on Vista/Win7 doesn't work for XP. So I would like to have this tool running while running the Crystal Installer, and it tell me what registry changes occurred during installation.
regshot is capable of creating a registry snapshot before and after installation and compare them, showing only differences. Of course, identifying the related changes is kind of work...
http://sourceforge.net/projects/regshot/
Related
I have created a Windows Installer for a windows service with VS 2017. The windows service has a project installer and service installer class inside it. When I cancel the uninstallation process midway, the process removes the windows service but does not update data, so the next time I run the setup , I get the option to Repair or Uninstall the windows service. Attempting to uninstall the windows service now gives an error that "the specified service does not exist", and hence the uninstall process rolls back. Now the system is in a state where the service can neither be installed nor uninstalled. To be able to remove the service completely, it must be installed once again from the command line, so that it can be properly uninstalled. Is there a way around this issue? I thought of using the service install table to make sure that the service is properly removed even on cancel, but then I get the error that service is already installed when trying to install the service [The Project Installer/Service Installer classes do this installation, I think]
First make sure that you've done all the custom action service installer nodes, in particular have the Commit and Rollback node custom actions populated. These custom actions all work together, so if you have missed one of them that could cause the problem. In theory, canceling the uninstall should have noted that the service is no longer installed, and it should be re-installed.
If that's not the issue, then it's probably a bug. The most useful thing you can do to fix it is to override base.Uninstall() in the installer class and add some code to check the service is actually installed before calling base.Uninstall().
Visual Studio setup projects are the only ones that use code to install services, and they are custom actions to call installer class methods. Everyone else uses the ServiceInstall and ServiceControl tables supplied by Windows Installer.
Some of the options you can use if you don't want to completely switch to another tool such as WiX are:
The ServiceControl and ServiceInstall tables aren't too complicated if you know something about services. If you scroll down from here to the paragraph about Visual Studio and installing services there's an article and a program to help with that:
http://www.installsite.org/pages/en/msi/tips.htm
You could dive into WiX enough to create a merge module that will install the services, together with any start/stop actions required. Then merge that merge module into your Visual Studio setup. No custom actions are required (and install classes are custom actions so you don't need them).
MSVS Installers & Custom Actions: You are using the Microsoft Visual Studio 2017 Installer Projects? They are very limited. The use of custom actions for service installation is one symptom of this. The use of custom actions in general is a very error prone approach (might be an over the top write-up), and for service installation it is almost never the right approach. Get rid of custom actions whenever you can and your deployment failure rate will drop.
Built-In Service Installation Features: You should use the built-in service installation features of Windows Installer (ServiceInstall and ServiceControl tables - which you seem familiar with), and there are a number of tools that can help you do this. Here are some alternative tools (free and commercial) that you can use. WiX does the job nicely, but does have a learning curve.
Service State: I would reboot in your case, to get rid of the service's current error state. It might be in some odd state pending deletion that could cause weird test results. I never take the time to investigate such issues properly, instead prefering to try and eliminate them by a simple reboot to get rid of the error state. Then do the deployment right with built-in features and that error state should never occur. A problem removed is ten problems solved? ( wishful thinking :-) ).
Visual Studio Publish Project Into One Simple Installer
What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc
I developed a program in VB 6.0 and used Package & Deployment Wizard to build an Setup exe file installer, but my software contained some dependency folder and the VB Package & Deployment only allows files, not folders.
Does anyone know any other types of Packages & Deployment or setup generator that I can use?
You're asking the right question. :) The PDW was never a stable enough solution to risk using it in a production environment. It never fully solved the "DLL Hell" problems that come up with it.
One of the main problems was that after the PDW was released, OS service packs started disallowing replacement of numerous DLL files that were used by the OS. This was the only way that they could solve the ubiquitous version problems that were plaguing server installations everywhere. They never did anything with the PDW to address this change. So, if your installation package includes a DLL file that the OS doesn't allow you to replace, the OS won't register it. Then, when you reboot as part of the installation process, the PDW errors out and tries to reboot again, and you get caught in an endless loop of reboots. Very very bad. If you should be interested, I wrote this up in detail here back in '03.
There are plenty of solutions for what you're trying to do, and some of the other answers give some of them. Microsoft's own solution is the Visual Studio Installer, which you can read up on here. This is the one that builds those .msi files that you see all the time; msi = Microsoft Installer.
Try using iexpress.exe, it's built in with windows for creating windows installation packages, it's fairly simple to use and i know it works for windows7, 10, and probably others too! You can search in the start menu to find it or use the run dialog box, or command prompt, just type in iexpress.exe and there you go, i make a few vb6 setup programs this way.
Windows installer is replacing some files while starting the application. This is because these files versions are old as I replace them manually after installation. It's a configuration files.
I googled this issue and found that there's a feature in windows installer "Replacing Existing Files" that do this job based on file version.
Do anyone know how to disable this feature?
Repair is a normal feature of Windows Installer and you can't disable it. Windows keeps a record of the file versions that were actually installed and if it finds that they are wrong, then there are triggers that will cause their replacement. That includes right-clicking the MSI file and choosing repair, or doing a repair from Programs/Features, as well as some automatic entry points. The official way to replace just some files is with a Windows Installer mechanism such as a patch or an update/upgrade of some kind.
You don't say which tool you're using to build your MSI files, but the supported way to tell Windows you don't want it to manage your installed files is to use a null component id:
https://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
and see the ComponentId description. That means you'll also need to remove them manually at uninstall time. Either you manage them or Windows Installer manages them. Or use a non-MSI setup to completely avoid the issue.
I have created a windows based application in C# using visual studio 2008 which basically scans for the registry and then fixes the resulting errors. Now using the msi installer i have made a setup and it works fine. However i have met with a new requirement.
Usually after providing the setup to the user/client has to install the setup and when installed, in the installed folder there are lots of .dlls that i had used to create the project. But my requirememt is to create a single standalone .exe using which i wouldnt have to provide my users with the setup file. All i need to do is that using this single .exe file my whole project should execute and perform the same process of scanning and fixing the registry.
I also tried "ClickOnce Deployment in .NET Framework 2.0" and got the error "ClickOnce does not support the request execution level 'requireAdministrator'". and also have gone through the link
"ClickOnce does not support the request execution level 'requireAdministrator.'"
But still i feel that i would be comfortable if i can get a single standalone exe which can execute my windows forms application.
Is there any way to do it?
Any hint with this thing will be really helpful to me.
Thanks in advance
~Viknesh
I am wondering about the need for an install wizard for my little Windows Forms application. No database access, just file access on a shared network drive.
I have seen times when an executable is sent in an email, copied to a desktop and used.
Other times when an 'install wizard' seems to be used to set up the application.
What dictates the need for this or not?
And if I want to use one - what needs to be added to my windows form app?
If your application is truly just an .exe file, it's probably okay to distribute it as-is without an installer. This might be preferable for more advanced users, because they won't have to worry about cleaning up a broken/unwanted install - they can just delete the file and be done with it.
On the other hand, most Windows users are used to working with installers, and having shortcuts automatically created on the desktop or Start->Programs. This is where an .msi can really help. Also, using an installer will usually put your application in the "Add or Remove Programs" control panel, which most people know how to use. Also, if your application is more than just a single .exe file (e.g. multiple .dlls and resource files), you'll probably want to use an .msi.
Creating an installer is easy, look at "Setup Projects" in Visual Studio.
An installer is almost always a good idea, because it can work out what dependencies your application has - which you may not even be aware of.
It also looks more professional and users will have more confidence in it.
There's an open source installer called NSIS that's pretty good, if you find the Visual Studio setup wizard too clunky, as I sometimes have.
Sometimes simply copying a file just isn't sufficient, this is when you need a setup program.
Checking if the correct version of .NET is installed
Installing C++ runtime dependencies
Creating a desktop shortcut
Setting up "default" configuration data
Adding exceptions to the Windows Firewall
Preventing installation on unsupported systems such as Windows 95/98/ME
etc, etc.
If your program is a stand-alone application with no dependencies and can run on a stock-standard install of Windows 95... then you don't need to worry about setup ;) But if your app has any external dependencies then you want to spend some time on setup.