I have created an application with WPF and code is used C# but it gives a problem that whenever setup is silently installed with cmd command e.g.
setup.exe /s /v/qn
it works perfectly to extract all the items containing in it after above given lines. But once setup is completed we try to run this application, it executes but shows below given image
Setup is created in installshield and it has the option not extract msi cache in local computer. Please help me to find why this problem is occuring.
That has to do with the auto-repair features of Windows Installer.
I guess you are using advertised shortcuts. Every time a user uses this special kind of shortcut to run a application, the Windows Installer performs an integrity check of it. If there are any detected problems, the installer performs an "Repair" before the launch of your application. This seems to be the case.
You can detect advertised shortcuts in the property-dialog of the start-menu. The target-field will be disabled and does not contain a path to a executable.
A possible workaround is to use regular shortcuts but this will not solve the real problem which causes the dialog to appear.
You could try to investigate further with ProcMon (https://technet.microsoft.com/en-us/library/bb896645.aspx) and see if there are any problems during the startup. Another option you have is to force logging (https://support.microsoft.com/en-us/kb/2545723) and see if there are any information that will help you finding the cause of this error.
Another entry-point for the self-repair is the creation of COM-objects which come with your installer-package.
Related
I am a bit confused. I have a C # WPF application. This works as I wish when I run the EXE file.
Now I have set up an installer (Visual Studio Installer project). This installer installs the application as desired and creates a desktop shortcut.
If I start the application now via the desktop icon, then installer is executed again and it is asked for the admin access data. After entering the data, the application starts directly. And that happens every time I click on the desktop icon.
I use in the application project the costura.fody package to bind one executable.
Have someone ideas whats wrong?
I've read the desktop icon from Visual-Studio-Installer-Project check always the application state. I think this is why the installer start every time I click the app icon on the desktop.
Short Answer: This is an MSI self-repair problem.
Work out what component triggers the self-repair. Details below.
Correct the situation by making changes to the setup eliminating the conflict situation.
Self-Repair: This is self-repair, or self-healing or "resiliency" depending on who you ask. I have a description here: Why does the MSI installer reconfigure if I delete a file? Towards the bottom there are three links. I would go for the one saying "how to avoid in your own package".
Understanding: There is a longer explanation of self-repair here. Section "The Primary Causes of Self-Repair" explains 3 main causes, yours being the first one.
Culprit: You should check the event log for clues as to what file / component is triggering the self-repair:
Stefan Kruger's debugging procedure
My own version here (longer) (section "Finding the trigger or culprit for the self-repair").
Once you have worked out what component triggers the repair there are a variety of fixes. But first maybe check the list of common mistakes in your own package.
Previous Answer: Come to think of it there are several previous answers:
Window's pop-up constantly appears when installed application is launched (seems better than the above)
Visual Studio 2015 msi build initiates another installation
Seems like a simple question but I am facing some weird problems.
I am using Visual Studio 2015, Enterprise Edition and Install Shield to create setup of my software, this is my first time making a general purpose software. Everything goes according to plan but I get these 2 problems.
Problems are:
Shortcuts don't work
Application doesn't launch until I run from root directory as admin
Problem 1:
I create the setup and do everything asked, I put the primary output into setup, which by the way contains 2 files. the .exe file and a .config file and I choose the primary output in "add" button to create a shortcut but when I install that setup, the Desktop shortcut doesn't work, in no way.
Problem 2:When I simply double click on the software's main .exe file, it doesn't run. No response but when I run it as Admin, it responses and opens. The problem is weird cause this doesn't happen in debug or the release files of the software.
Is there something I am doing wrong? maybe the way I insert the primary output?
This doesn't appear to be an installation problem. Your statement "..when I run it as Admin, it responses and opens" means that your program requires admin privilegs to run correctly, and running it from a shortcut does not automatically run it as administrator. The usual way to say that a program needs elevation when it runs is to give it an elevation manifest as here:
https://msdn.microsoft.com/en-us/library/bb756929.aspx
with requireAdministrator. The program will then show the standard dialog requesting elevation.
The most likely reason for your program doing nothing when it fails is that it silently crashes and goes away, and that's probably because your code isn't explicitly making sure that everything you do is actually working. For example, if you try to create/modify a file in Program Files (and you're not elevated) it will fail, and your code should check that access was denied.
I have a problem regarding the Visual Studio Setup Project and uninstalling an application.
This is a very basic installer, installing an ApplicationLauncher.exe C# .NET 4.0 console application and an Application.Common.dll (a dependency of the application ApplicationLauncher.exe).
The installation is a success, copying both the exe and DLL into the program files folder C:\Program Files (x86)\Company\ApplicationLauncher\.
My problem comes when uninstalling the application (through the MSI) - the uninstall seems successful, however it leaves Application.Common.dll behind, and doesn't remove it as I would expect.
I've used ProcessExplorer to make sure nothing else is using the DLL, no explorer windows are open during the uninstall.
Is this the expected functionality and do I have to create a custom action to remove this DLL? Or have I done something wrong? :S
It seems I was able to fix this issue by renaming the solution and product name of the application, I'm not sure how this fixed it, but it did.
My only thoughts here is this traversed through to the installer, where the application installed into a different folder, thus not applying the same permissions to the DLL..
It's not expected, no. It will happen if you ever done any of the following with your setup and installed it:
Marked the file Permanent.
Marked the file SharedLegacyFile true.
These are project settings, but if you set either of them and do the install it will stay behind. You can unset them in the setup project but that's too late - you've marked that component permanent or sharedlegacy on the system. If you use a brand new system, like a fresh virtual machine, reset these values if they are set and rebuild the MSI and do the install/uninstall does it still happen?
I had the same problem. Then I have tried to install and unistall my app on Windows XP and that had worked.
Renaming the ProductCode is treating the symptoms not the cause. The problem occurs when the uninstaller doesn't remove the dll. The next install will use the dll again and can't remove it on an uninstall event because it's still used by the other program.
These steps hopefully solve the problem:
Install your Software
Open CMD (with admin privileges) and run:
msiexec /x {ProductCode} /L*V "C:\CustomPath\FileName.log"
The ProductCode can be found when hitting F4 on the Setup Project
Open the log file and search for the lines that look something like this:
Disallowing uninstallation of component: {6CEC09F6-9108-7062-A692-2BCBACEE3BD8} since another client exists
Disallowing uninstallation of component: {A0A0FA84-CC0D-C5C4-1F57-169788C4482D} since another client exists
Disallowing uninstallation of component: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} since another client exists
All these components have to be removed from the registry by hand. To do this the GUID (e.g. {6CEC09F6-9108-7062-A692-2BCBACEE3BD8}) first has to be converted into a packed/compressed GUID (e.g. 6F90CEC6801926076A29B2BCCAEEB38D). I found a Website where one can run a script to do this. Find the following code on the website and replace the right side with the GUID from the log.
string inStrGUID = "{6CEC09F6-9108-7062-A692-2BCBACEE3BD8}";
Open the registry (as an administrater) and search (Edit -> Find...) for the compressed GUID (uasually it's somewhere in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\)
Delete the folder that is equal to the compressed GUID. The values inside the folder should be a path to the dll.
Once deleted select the parent folder (...\S-1-5-18\components) and hit Edit -> Find...
Repeat these steps (4-7) for all components from the log file.
It's also a good idea to delete all files still present in the original folder that weren't uninstalled.
Can one prevent this from happening?
I don't know. This really isn't that easy to reproduce. Some other post on SO have suspected the install/uninstall option in Visual Studio to be the cause of the problem but I have a different theory:
This bug might be the result of RemoveExistingProducts in InstallExecuteSequence in the Setup being executed too late and therefore not removing dlls at the right time. This bug is known for years and can be fixed by doing this. If you need help with Orca this explains how to install it.
I have a C# application, and a Visual Studio (2010) Setup Project with it. In my Setup Project, I am using InstallAllUsers = True. Additionally, my application needs to launch at Startup, so a shortcut is being added to the User's Startup Folder.
So I install my application as user Bob (from a share), and then I log off and log on as user Alice. Alice gets a dialogue that says:
The feature you are trying to use is on a network resource that is unavailable.
It provides the network path from which the MSI was installed. So, basically, it's looking for the MSI on a share that Alice doesn't have access to. This is repeatedly reproducible if Alice tries to manually launch the Startup link. However, Alice can directly launch the exe from the installation location, which works fine.
I don't fully understand why it is looking for an MSI, but I guess it makes sense that an application can not be completely installed by one user for another user, so the MSI is needed to complete the installation.
But if that is the case, then I don't understand why the MSI only seems to be required when launching from the Startup link, and not from the exe directly.
My question has several parts:
Is what I am experiencing expected behaviour for the InstallAllUsers option?
If so, how can I ensure that my application is fully installed for all users?
Is it necessary to copy the msi locally, and ensure that it does not get deleted before each user has had a chance to log on?
This is happening because the shortcuts are "advertised shortcuts" hence the greyed out target box.
More info here...
http://www.advancedinstaller.com/user-guide/advertised-shortcuts.html
When an advertised shortcut is launched it validates the checks
associated with the key resources. If any is missing it will fix it by
running the installation package and installing again all information
from the .msi file.
This is why its trying to run the msi.
You can turn off advertised shortcuts by reading this article...
DISABLEADVTSHORTCUTS=1 disables all shortcuts
If its an all users install, then the shortcut will probably want to reside in the all users start menu. Win 7: C:\ProgramData\Microsoft\Windows\Start Menu.
Eric, I would recommend taking a look at the shortcut file contents. You can do this by using Powershell, and there is a SO link to help you on your way:
Editing shortcut (.lnk) properties with Powershell
I've been working on a simple project that uses some common .NET classes, isolated storage, some resources and no external libraries.
Somehow the EXE generated (either in debug or release mode) no longer runs (stops working as soon as it's opened) without giving any details or displaying any exceptions.
It runs normally in visual studio, and there's a .application in the same folder that when clicked starts in install process.
I'm not interested in installation files, I just want it to be the way it was: running an EXE (it's easier to get testers when all you have to do is running it).
I have previous versions of the program, and all of them run normally through the EXE's.
I don't recall changing anything regarding framework, deployment or build. I revised it and there's nothing changed apart from using new objects from the .NET framework.
--[Update]--
Just checked the event viewer. Event data "not available" and answer "not available".
This is a classic example of when a personal version control system would have helped. It would have automatically kept every version of your code including the one right before you made the change that messed up your exe.
Anyway to fix your issue comment out the majority of the code untill it atleast runs. Add a simple output statement just to make sure it is doing something. Then slowly add back in more code.
I suggest you to run your exe file in a consol (cmd.exe) to see if your application displays errors or exceptions in it.
Check the <YourAppName>.Exe.Config file.
Probably it is not well-formed Xml.
I'd start with removing the setup project from the solution, rebuilding then run it in debug mode.