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
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.
Iam using visual studio setup project (msi installer) for my winforms application. How to remove write permission to c drive programefiles? How to implement file permission step by step in msi installer?
I tried cacls to remove file permission. But it is not works.
The Program Files folder can be written to only with administrator privilege. That means you are asking how to prevent code that is running elevated (with admin privilege) from writing to files in the Program Files folder. It's not clear to me what access restrictions you need that to prevent elevated code from doing what elevated code is supposed to do because that's a security related issue, not an installer question.
The short answer to the design issue is that you should try to run your app with limited user privilege instead of administrator privilege, because limited users cannot write to files in the Program Files folder. However you haven't described the underlying problem you're trying to solve, you've just asked how to implement your proposed solution.
If cacls didn't work, it's impossible to say if it will never work (because you are doing a Just me install, as an example) or if you had an implementation error (because you wrote some kind of custom action to do it and your code is incorrect). The general answer to all these types of question is "write a custom action", but without details of exactly what you tried it's impossible to know why it didn't work, but that's the answer, and if a custom action doesn't work then it's a design or coding problem that requires showing the code and saying if it's an Everyone or Just me install.
I'm trying to figure out how to publish an application I wrote. We didn't get to publishing in class, and my programming teacher is having some health issues and isn't available right now.
I found the "Publish" option, and can get it to create a folder with an install program... but I open it, and it just opens the program, and spams me infinitely, complaining that my Access database (located in the bin > debug in the build stage) can't be accessed (from some weird path I don't recognize). I tried using WiX, but it gave me an error when I tried to install, saying it doesn't have access to the install folder (running as admin). I've been googling for a few hours, poking at it, exploring, and I'm not getting too far. Can anyone ELI5?
When you use the "publish" option for desktop apps, VS creates a click-once installer that will place all the files it knows about in the appropriate locations.
Unfortunately, it can't guess which other files your application needs so you need to tell it explicitly.
If you right-click the Project->Properties, go to the Publish tab and click the "Application Files" button, you'll see all files that will be added to the installer.
Next, click "Show all files" at the bottom. Find your database, and change the Publish Status to "Data File".
Note that I've only ever used the Click Once installer to install static files (like images/documentation) that are never modified, only replaced in later releases. I'm not sure whether your (modified) db will be preserved during an update but I suspect not.
If the Click Once install process is too simple for your needs, VS2010 has "Setup Projects" which create more complex installers that support logic/code. For VS2012, the commonly suggested option is Wix. Unfortunately, it's got a steep learning curve but it can do pretty much anything you need.
I believe VS2013 and later have setup projects again through an extension but I haven't tried it myself.
Edit:
The easiest way around this is likely to set the connection string programatically based on where the application is executing from.
Note that as per this answer clickonce apps are usually executed from deep inside the user profile directory (also read the answer below about data directories). It's a side-effect of how ClickOnce works (it wants to install somewhere the user is guaranteed to have write access).
Check if there really is an .mdb in that folder. If not, you need to tweak the installer or the properties for the .mdb. Assuming it's in the same location as the executable, you can tell your application where to find it...
string dbPath = IO.Path.Combine(
AppDomain.CurrentDomain.BaseDirectory,
"access.mdb");
string connectionString = String.Format(
"Provider=Microsoft.Jet.OLEDB.4.0; Data Source={0}",
dbPath);
I'm not sure why you think the database file added by the installer is in a directory directly under C:\. It's possible you're not looking at the file created by the installer.
To avoid confusion, try changing the name from access.mdb to something else (temp.mdb?), build the installer, rename back to access.mdb. Now, when you've installed the application, make sure the file you're looking at is now called temp.mdb. If not, you're looking at the wrong file.
This Link Has Full demonstration of Database Connectivity And Publish a C# application with database. The application is also running on another machines.
How to Publish C# Application with access database
I have a project in c# which requires auto update functionality, since it has quite a lot of dependencies and runs a Windows service, ClickOnce installer is not suitable for this work. So I created a setup project for this application. Now I want to include an auto update feature.
My auto-update strategy is:
From the main application, check for updates every morning.
If an update is found, get the msi link
Application passes control to the msiexec and quits
Ex.
msiexec /i http://www.example.com/share/package.msi /L*V "C:\log\example.log"
Since my application is running on administrator account UAC prompt will not occur.
Are there any pitfalls that I haven't seen? Or there any superior way to do auto update gracefully?
Note: The setup project of the application is marked with the property RemoveAllPreviousVersion = True so it will take care of the uninstallation of previous versions.
A couple of comments/answers:
"Note: The setup project of the application is marked with the property RemoveAllPreviousVersion = True so it will take care of the uninstallation of previous versions."
But only if you increment the Version property of the setup project, accept the change in ProductCode, keep the UpgradeCode the same, ensure that the value of EveryOne or Just me is the same in the older product and the upgrade, and increase the file versions of files you need to update.
It's also not obvious to me that you won't get a UAC prompt because "running on an administrator account" does not mean the same as "running with administrator privilege". If the running process is not running elevated a prompt will occur, because UAC means that even administrators are running limited unless explicitly elevated. Even if you are elevated, calling msiexec as an external shell call will not result in msiexec being elevated. A shell execute does not transfer privilege to the offspring process. The other thing to consider is whether it's the current interactive user that is effectively doing this update, because there may be an issue trying to show UI if another user owns the desktop.
Anyway in general it's ok to do that, it's quite common, and signing the MSI would be more secure. Also, Windows Installer will sometimes prompt a repair, so that install URL needs to remain valid. A better approach would be for you to download the MSI to a location on the client system that you own and prompt the user to run it, or you run it - it's more friendly to offer that than pull the rug out and just do it.