We have a big WIX Installer. After the installation, there are around 2800 scripts that should be run to upgrade the database. For that purpose, a special application is created. It just goes to the SQL machine, installs prerequisites like SQL SMO and SQL Sys Clr Types, and executes scripts. This small application is run in custom actions in WIX. Logically, it should be run with elevated privileges. In this custom action, I am using c# Processes to start the app. However, I have tried everything, and the application is still not working properly. It opens the app and app tries to install prerequisites and just exits - nothing is installed. What I have tried:
1. Running process with elevated privileges (process.StartInfo.UseShellExecute = true)
2. Running process with user privileges (standardinput/output with UseShellExecute=false)
3. Running the app with a batch file.
Overall process should be as following:
Installer is run with elevated privileges -> After installation, special application is run to upgrade the database -> the app installs prerequisites -> the app executes scripts.
The interesting part is that application is working properly when I do it manually with cmd. However, when installer's custom action opens cmd.exe (c# Process) and it is still waiting, then manually opening application via cmd is not working. In other words, I have cmd (with elevated rights) opened by installer and another cmd opened by myself manually. Then, manual running the application is not working. As soon as I close the cmd opened by the installer, and run manually the application via cmd that was opened by myself, then again everything is fine, everything is working.
I need a help how can I fix this?
P.S. The installer's prerequisites cannot be extracted and installed separately. We do not have source code of upgrade database application.
After some research, I have found that Windows cannot run two MSI at the same time and therefore, second MSI was silently quitting.
Related
I'm running a .Net Core microservice on Linux (Ubuntu) and am trying to remote debug with Visual Studio over SSH. But the service is run under the user svcuser and my user is mainuser. Main user is in the same group as the service user.
In visual studio, I can see the process that the service is running under, but when I try to attach I get:
One or more errors occurred. Failed to attach to process. The .Net Debugger has insufficient privileges to debug the process. To debug this process, vsdbg must be running with root permissions.
I checked in MS documentation but for Linux all they have is this: https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging-dotnet-core-linux-with-ssh?view=vs-2019 which has no info on running the service with a different user
And the only info they have on fixing such a problem is for windows only: https://learn.microsoft.com/en-us/visualstudio/debugger/error-the-microsoft-visual-studio-remote-debugging-monitor-on-the-remote-computer-is-running-as-a-different-user?view=vs-2019
If you have sudo privileges then this is relatively easy, and can be kept secured to those users with sudo privs. Avoids needing to reconfigure users/environments, and allows you to debug any process on the machine regardless of which user account it is running as.
If you use Visual Studio to make an initial attempt to debug you will find that a ~/.vs-debugger folder has been created in the home directory of the user account you were attempting to use. This command will help you locate the vsdbg binary which was installed. You can install VsDbg manually but I find leveraging the automated process is easier. If you are using VSCode this becomes a manual process, and an exercize left for the reader, but I would still use VS2019 IDE to prep the target just to keep things consistent between tools.
find ~ | grep vsdbg
For my installation the binary is located at ~/.vs-debugger/vs2019/vsdbg and this path will most likely change over time.
First, rename the binary to something convenient:
mv ~/.vs-debugger/vs2019/vsdbg ~/.vs-debugger/vs2019/vsdbg-bin
Second, create a script to replace the binary:
touch ~/.vs-debugger/vs2019/vsdbg
chmod 770 ~/.vs-debugger/vs2019/vsdbg
nano ~/.vs-debugger/vs2019/vsdbg
The script content might look something like this, note the full path to vsdbg-bin, the use of $# ensures all command-line args passed to your script are forwarded to VsDbg.
#!/bin/bash
sudo ~/.vs-debugger/vs2019/vsdbg-bin $#
Now retry your debug session from Visual Studio, if you did things correctly you should be able to attach to any remote process on the target machine using SSH->VsDbg. "Works on my machine." ;) This was confirmed with VS2019 16.8.4, .NET 5.0, and VsDbg 16.9.20122.2 debugging an ASP.NET Core application running on Debian 5.4.8 (x64) launched by systemd under a service user account in Azure. "Sweet."
HTH!
I need to run an *.msi file from within my c# application. The install runs without a UI and must run unattended. Is there a way to avoid the UAC popup window?
In the past I've created solutions that did things like:
1) Install lays down app and a windows service running as SYSTEM.
2) Application checks webservice for new version and downloads to a temp directory.
3) Application informs service that MSI is present in temp directory.
4) Service "blesses" MSI by performing msiexec /jm foo.msi /qn (published/assigned)
5) Service informs application that the MSI is now trusted.
6) Application performs installation of MSI without UAC prompt. msiexec /i foo.msi /qn RESTARTAPP=1
This pattern requires the MSI to be fully compliant in terms of custom action scheduling / security sandboxing. It's also advised the application quits as soon as launching the MSI as to get out of the way and to have a custom action conditioned with RESTARTAPP to relaunch the application to give it a seamless user experience.
I've thought about making this a FOSS project/pattern but the security considerations to ensure it's not abused are beyond what I want to deal with.
There must be a an elevation prompt somewhere, but you could defer the UAC prompt to your C# launcher. It starts, gets UAC elevation, and if you then start the MSI install as a CreateProcess() initiation (or just call MsiInstallProduct) the MSI will also be elevated.
I have created a code, which compares XML files on the client side (in PC) with the XML file located on the FTP server; where once it detects that client is running older version of the program, it will download the latest build (so that user has always up to date program).
Here is the trick. Due to the fact, that I am overwriting files at run-time, I had to create an external console application which is being called from the main app if user wants to update. This way, first console application is executed and afterwards main app is closed, so that no files are locked by the system (application's .exe file would otherwise be locked and we could not replace it with the new one).
This process runs perfectly, if it is being installed somewhere else other than under the system folder (by that I mean e.g. C:\Program Files\ drive). If user has decided to install main application there, then suddenly my app crashes as it does not have admin privileges.
I am using Install Shield LE when disbursing this app, and users that are using this program are not administrators (which means that I go to every computer and type admin password when I/users install this program).
Is there a way, how to execute my updated console application with admin rights, or how to define via Install Shield that once this app has been executed, I always want it to be executed as admin?
Hope that my explanation has not been confusing. I am more than happy to share additional details if necessary, as I need to figure out how to solve this thing.
I imagine you don't have an AD configuration as Emmanuel suggest, because in this case you would push the updates without any problems and would not have to design an automatic updater.
I don't know if InstallShield has something like this, but Advanced Installer has the support to install a dedicated updater that runs as a service, thus it has all the permissions required to install an application under Program Files.
Of course this means you need to replace your updater with the one from Advanced Installer and also that the initial installation of the application on the end user machines will still require admin credentials. (future installs can install silently, without the user's intervention)
You'll need to add the following line to your app manifest:
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
Documentation on the msdn is here.
We have a program in WPF. In order for clients to run this program, they first need to manually install our certificate on their PCs.
Is there a way to make the program automatically prompt the user to install the certificate or approve installation of certificate ?
http://technet.microsoft.com/en-us/library/cc732061%28v=ws.10%29.aspx
Create a bat file and run this, either as a process inside your main application like a first run sort of deal or have it execute as part of your installer.
I have an application that has drag and drop functionality to import images and video's. While developing, and testing through Visual Studio this has never given any problems.
After installing through a set up project, everything in the application works fine, except the drag and drop, which seems to be doing nothing. Are there any security settings that need to be set through an installer, or something of that nature that could be preventing drag and drop after installation ?
Yes, your drag+drop will not be permitted if your program runs with elevated permissions. It is called User Interface Privilege Isolation, Vista UIPI for short. It is complementary to UAC and controlled by the uiAccess attribute in the manifest entry that you'd use to elevate your process. As well as a certificate and a proper install location.
Realistically: don't elevate your program. It is a security hole when restricted programs can get their objects dropped in your privileged program. UIPI tries to prevent that.
But debug your program first.
Build a debug version of your application, build your installer with the output. You can either include the .pdb files in the installer or copy them to the install location after you install.
Run the installed application, and then in Visual Studio, go to Debug --> Attach to Process. Select the process from the list, and click the "Attach" button. Add breakpoints, etc, and debug as normal.
If you don't run into the problem on your build machine, you can also run a remote debugging session to debug the application on a different computer, but this requires a little more setup.