I've read every stackoverflow article on MSI installations, but I cannot find the solution to my problem:
I have a VS2010 solution with 5 projects, all targeting .NET 2.0:
DLL A, no project references
DLL B, references DLL
A Windows Forms App, references DLL B
Windows Service, references DLL B
Setup Project
DLL A and DLL B are set up as to be installed to the GAC at install time. I'd like to start the service once the installation has finished, but according to what I've read, the assemblies are not registered until the very last step. I have proven this by attempting to start the service on the AfterInstall event of my ServiceInstaller class and I get the following error:
Error 1001. Could not load file or
assembly 'DLL_B', version 1.0.0.1,
Culture=neutral,
PublicKeyToken=5e297270603814f4' or
one of its dependencies. The system
could not find the file specified.
But of course, once installation is complete, I can manually start the service and it runs fine. Also, in Windows XP, I can usually have the service started at application launch (I have a checkbox with Launch Application as the last step of the installer). But in Windows 7, permissions are no longer elevated at that time and starting the service throws an error.
How can I achieve the installation and starting of the service without forcing a reboot? To quote my client: "Its 2011 now and that shouldn't be necessary.", and I agree whole-heartedly.
Thanks ahead of time.
This is a well-known issue with the GAC. One option might be to use two separate installers and daisy-chain them. This is the way we have chosen to get around the problem of deploying Microsoft VC runtimes on Vista and later. If you use the merge modules, any services that depend on them won't start. So in effect you put your GAC-destined components in a pre-installer whose transaction will be completed and committed before you run a second install that installs and starts the services that depend on them. Ugly, I know, but better than a reboot.
A solution is to use a custom action which runs after InstallFinalize in InstallExecuteSequence table. This custom action should use the msidbCustomActionTypeAsync and msidbCustomActionTypeContinue flags so it runs in a separate process after the installation is finished.
This cannot be done with a Visual Studio setup project, but there are a lot of alternatives: Orca, WiX, a commercial setup authoring tool etc.
I worked around this issues slightly differently: I installed my assemblies not only in GAC, but also into the Application Folder. My GAC-bound assemblies were already found as dependencies, so I put those into GAC (and those indeed end up there only after all custom steps executed). I also added same assemblies as primary output to the Application Folder, where my InstallHelper DLL with custom actions also resides. This way during installation local copy from Application Folder is used.
Related
Long story short, one of my my employer's clients has an aaS platform that relies on a piece of software that's a ClickOnce app. This particular app is developed by a 3rd party software developer, and licensed to my employer's client company. It also happens to have a large number of prerequisite/dependency applications that need to be installed in order for it to function, but are not deployed as part of the ClickOnce installation. Importantly, because it's developed by a 3rd party and licensed, it's not possible to make any changes to the application itself.
Thus far, actually installing the application on endpoints has been handled by the client company by providing a pre-imaged computer, or when their client wishes to use their own hardware, giving their customer service reps a large zip file containing a bunch of .bat scripts they have to run manually on any computer that's to be used as an endpoint for their service. The batch scripts basically do the job of a bootstrapper and install the prereqs, make necessary system configuration changes and checks, and then call the ClickOnce application installer.
As expected, they don't like this solution, and would like an actual installer, so I've set about creating a bootstrapper with WiX/Burn, but I'm now stuck on how to include the ClickOnce application in my bootstrapper project. I can't seem to find documentation on this online, prompting the question:
Can I bundle a ClickOnce application into a WiX bootstrapper? How?
If it makes a difference, the ClickOnce application is published from one of the client company's servers, so I have full access to both the ClickOnce manifest and all the .deploy files.
You can't make a silk purse of a sow's ear. I think the best you can do is make a dependency installer for a certain version of the ClickOnce installer. No one should expect that a future version of the application would have the same dependencies.
(By that time, though, maybe they'll fix their ClickOnce installer by including dependencies. Or, abandon dependencies that they are having trouble putting into ClickOnce, say those needed for obsolete versions of Windows.)
Once dependencies are installed, you can have the bootstrapper launch the application, which would install or update it. (Logically, this follows the Chain.)
<Variable Name="LaunchTarget" Value="http://example.com/path/product.application"/>
Backing up a bit, you could create an MsiPackage with all of the ClickOnce files, and use a "file://" URI for the LaunchTarget. This would require you to rebuild and redeploy each new version (defeating the nature of ClickOnce), but would isolate you from untested application updates.
I'm not very experienced with deploying applications and i'm having an issue with my very small screen scrape application.
I use a project that handles all screen scrapes and i just call the functions from the dll(on dev machines at least). When i reference that dll from the directory, it works fine on my machine but installing and launching on another machine without the project crashes it immediately when it tries to access the class to instantiate the screen scrape object.
Perhaps my assumption of dll is incorrect but doesn't having the dll mean it incapsulates all the classes/references/etc in that project so it can be used elswhere without having to lug the whole project with it?
What could be going on with this dll?
The dll assembly encapsulates the project, but not its references. Anything that the project needs to reference must be available in the new environment as well, whether in the GAC (global assembly cache), the local directory, in a reference path, or wherever.
If you are using Visual Studio 2010 or earlier, you can use Setup Projects to nicely gather all necessary references and package them into an install package for you. There may still be complications that you will need to troubleshoot sometimes, but it simplifies your deployment effort. In Visual Studio 2012 and later, Setup Projects were dropped, but there are other options, like WIX and Install Shield. And that is a whole other topic with plenty of Q&A on this site.
This is Edited from the OP. This is a VB .NET 4.0 WinForms application. There is a mysql datasource involved with this project. The target CPU is set to any. Problem: When running this application on any computer that has VS 2010 installed along with the mysql connector it runs flawlessly. When installing on a virgin system(ie. No developer environment installed) but that machine does have .net framework 4.0 installed and a mysql server without the connector installed the application falls immediately. So to fix the issue I install the mysql connector MSI. This immediately fixes the issue on the client system and it runs. The problems is that as you can see below from my Installer setup that the 2 needed DLL files for MYSQL are actually included in the installation package so should not need to be installed separately. So Why is it that using that installer from the images do I need to install the mysql connector? Any Ideas? Below is a screen shot of the References the program uses and from what I believe I do not need to deploy any of those DLL files with my application other than the 2 MYSQL DLL files. So why is this failing?? Below are images showing the project references as well as the Installer Files that are being installed in the applicaiton folder. As shown in the image the 2 mysql dll files are to be put in the application folder. There is also a screen shot showing each dll's properties for in application folder.
You answered your own question.
but that machine does have .net framework 4.0 installed and a mysql server without the connector installed the application falls immediately.
You don't need to install the connector msi package, but you do need to include the two DLL files in the application's directory. Anytime you have some dependency, you need to deploy it with your application.
Edit solution quoted from my comment:
From your update it sounds like you have a version mismatch on the
assemblies, and the references are set to Specific Version = True.
Check the version number of the assemblies on your developer machine
in the output directory, and check the version you are installing on
the client system. (You can just hover over the DLL to read the
version on the ToolTip). You can try to set Specific Version to false
by right clicking your reference and selecting properties, or simply
ensure you deploy the same version of assemblies. Your program is
looking for the versions its compiled against
I've created a WiX setup project based on the article WiX 3 Tutorial: Understanding main WXS and WXI file mainly because it gives the WiX needed to do an application shutdown.
However, I'm puzzled by the outcome. Here's the situation:
We have an executable which uses a dll and create a setup which installs the executable and the dll. We execute the setup.
CASE 1: Next, we change the executable and NOT the dll and create the setup again. Then we start the installed application and make sure also the dll is loaded. If we now execute the second setup, a dialog is shown asking the user to shutdown the executable just as we expected.
CASE 2: But if we do not change the application but only the dll and then execute the setup while the application is running and the dll is loaded, no dialog is shown. At the end of the setup a dialog appears asking if we want to restart the computer.
Is this expected behaviour and how can I force the application shutdown dialog of CASE 1 also when only a dll is changed as in CASE 2? I do not want the user having to restart the computer because the application is running on a server which cannot be restarted.
This is all determined by Windows Installer during the costing process. The installer decides which files need to be installed / updated and calculates how much disk space is needed and if there are any file locks. If there are file locks, it attempts to resolve the lock to a process with a window handle. If it can do this, you'll get the dialog. If it can't, you won't. This doesn't mean a reboot won't be needed, it just can't give you useful information on how to avoid it.
A few additional points:
Make sure you are versioning your EXE and DLL. If the old DLL is 1.0.0.0 and the new DLL is 1.0.0.0 costing will say "Nothing to do here".
How does the EXE use the DLL at runtime? It might simply not have a lock on it during the entire life of the process.
Understand that MSI's reboot behavior can be altered through the use of properties such as REBOOT=ReallySuppress
Here's some good articles to read:
InstallValidate
FileInUseDialog
System Reboots
I haven't checked the code but I think what is happening is the CloseApplication action is not running because it sees that the exe hasn't changed. As far as I am aware you cannot target a DLL with CloseApplication. If you run your install with logging you should be able to see if the action is triggered. I am assuming you have RemoveExistingProducts schedule late in the install, if you were to move it after InstallValidate it would remove the exe every time and therefore trigger the action.
How do I create a Setup And Deployment project that can run any number of times on a machine without requiring an uninstall?
I've created an installer to install a WCF service to an IIS directory. It does more than just xcopy, it asks the users questions to correctly setup web.config.
The problem is when it can only be installed once per server without requesting an uninstall.
"Another version of this product is already installed...."
Typically the service will have 10-15 separate instances per server (each instance pointing most likely to a separate database, or a different security context)
I can't figure out how to set up the installer to do this.
Ok, I've got this working, I figured I'd answer it.
I downloaded the Orca windows installer editing tool (Part of the Windows SDK)
In the InstallExecuteSequence table, changed the following values to 0
RegisterUser
RegisterProduct
PublishFeatures
PublishProduct
This should allow the installer to run over and over without uninstalling.
It sounds like your program has 2 parts rolled into 1 - an installer and 1 UI based update service. Could you separate the 2 and have the installer check for being already installed and if so, fire up the UI program to run config setup.
If you want to install multiple versions of the same application you must do 3 things:
Ensure each version installs to a different folder, so subsequent installs will not overwrite previous ones.
You do this by changing the DefaultLocation property of the Application Folder in the File System panel
of the deployment project. A good policy it to use the application version as part of the location; e.g.
[ProgramFilesFolder]\[Manufacturer]\[ProductName]\[ProductVersion].
Ensure the ProductCode property of your deployment project is different, so subsequent installs
will not uninstall the previous version. The easiest way to do that is to...
Change the Version property of your deployment project. Visual Studio will ask if you want to change
the ProductCode property; you do.