I created a Windows service in C# (4.0) and am trying to install it using installutil tool in command line. However I get an exception. I managed to find out what part of my code is causing the exception - using some crappy logging but whatever - but now I want to understand why. So what I want to do is debugging the installation of my Windows Service.
I know how to debug the service itself, but here, I want to debug the content of my Installer.Install(IDictionary stateSaver) method in the service.
I tried to attach the debugger to the cmd.exe process but it obviously doesn't work. I was thinking also to attach the debugger to the installutil process but I have no clue how to do this.
I had a look to this post: How do you debug a windows service that is being installed? and several others but in this case, for some reason, this guy seem to have his service already in the services.msc which is not my case.
How can I achieve this?
You can put a Debugger.Break(); statement in the installer code, and it should launch the debugger for you.
If the above does not work, I have found this process works too. Basically, you compile in debug mode and install the service (I used installutil.exe through the command line). In code you pop-up a message box with the process ID. Startup a second instance of studio, attach it to that process and debug. The message box pauses it to allow setup. The process ID isn't important, its named InstallUtil.exe. I usually put a Debug.Break() in after the message box to guarantee it enters the code.
using System.Windows.Forms;
using System.Diagnostics;
...
#if DEBUG
int processId = Process.GetCurrentProcess().Id;
string message = string.Format("Please attach the debugger (elevated on Vista or Win 7) to process [{0}].", processId);
MessageBox.Show(message, "Debug");
#endif
....
How to debug the installation of a custom windows service
Related
I have an installer written in WIX, that has a WPF Bootstrapper. Recently we added a silent installation mode, and we need to use return codes in order to specify what kind of error occurred during silent installation, for instance: invalid username or password, incorrect server address, unsupported Windows version, etc.
We use the Engine.Quit() method from Bootstrapper class to exit the installer with an exit code. This exit code can be seen in the installer log:
[5490:4F84][2018-09-14T14:31:03]i007: Exit code: 0x101, restarting: No
However, when I check the %errorlevel% environment variable, it remains unchanged. Using Environment.Exit() did not help either.
I suspected, that MSI might be responsible for such behavior by overwriting what WIX tried to set, but even forcing ActionResult.Failure in one of the actions of installer does not help. The MSI exit code is in the MSI log, but %errorlevel% remains unchanged:
MSI (c) (AC:9C) [14:30:59:133]: MainEngineThread is returning 1603
=== Verbose logging stopped: 2018-09-14 14:30:59 ===
Is it possibe to make WIX set the %errorlevel% to a custom value, and if yes, how can it be done?
The %ERROPRLEVEL% value is a feature that you get in batch file environments (the Windows cmd BAT shell, and also PowerShell, I believe) so you're not going to see that value outside of a scripting batch environment. It's not clear from your post if your silent install is a batch script or not.
Having said that, an MSI install process returns standard Windows error results that are documented here:
https://learn.microsoft.com/en-us/windows/desktop/Msi/error-codes
so they can't be customized. The particular errors you mentioned (such as invalid user name or invalid server address) appear to be errors from your custom action code in the MSI. People generally deal with error diagnostics in custom actions by using the logging features of Windows Installer to add your messages to the standard log file. This uses MsiProcessMessage() or equivalent as here:
https://social.msdn.microsoft.com/Forums/windows/en-US/5698aaee-11e5-4a8c-b307-f96b9eb1884f/writing-custom-messages-to-log-file-of-msi-using-msiprocessmessage?forum=winformssetup
https://learn.microsoft.com/en-us/windows/desktop/msi/sending-messages-to-windows-installer-using-msiprocessmessage
So you're not going to get errors specific to your custom actions unless you arrange to record the details in the log, as above, or put them somewhere that your silent install can see them (registry?).
I have a simple asp.net application. I want to write in the output console of visual studio in debug mode. I've been using this code for a long time System.Diagnostics.Debug.WriteLine("Hello");.
When I run my web application with IIS Express, it works perfectly well.
When I run it with IIS, nothing appears.
How can I write in the output console with IIS ?
Edit : trying to use Trace which is better, here is the code i put in the Application_Start method of my Global.asax, but still not working :
System.Diagnostics.Trace.Listeners.Add(new ConsoleTraceListener());
System.Diagnostics.Trace.WriteLine("Hello");
You can use the Trace class. It provides a versatile interface to log the execution of your application.
You have to register a listener when your app starts (this can be in various places, depending on your application):
using System.Diagnostics;
...
Trace.Listeners.Add(new ConsoleTraceListener());
Then you can use Trace.WriteLine("Logging to output window"); to log.
I have a process 'a.exe' which I can debug it without any problem.
mono --debug --debugger-agent=transport=dt_socket,server=y,address=127.0.0.1:55555 a.exe
The problem occurs when I want to debug a new process ('b.exe') started by 'a.exe' instead of 'a.exe' itself. Here is the code.
var startUpInfo = new ProcessStartInfo('b.exe', argumentsOfB);
Process.Start(startUpInfo);
I have to pass the same options as above to mono to be able to debug 'b.exe' and use VSCode to attach to the url and port specfied.
The problem is Process.Start() only receives arguments for my exe, not mono.
Is it possible to do this? Or there is another way to solve this?
My Environment
OSX 10.9.5
Mono 4.0
VSCode 0.1.0
Just passing 'mono' to the ProcessStartInfo and adding all the arguments (mono's debug args, your *.exe, and your program's args) should do the trick. Make sure to use a different port if you want to be able to debug the a.exe and the b.exe.
Hi I'm developing a windows phone app and I use
System.Diagnostics.Debug.WriteLine()
function to write some debug info and when I run the program in debug mode while my phone is connected to my computer and visual studio there is no problem. but when I run the program without debugger - while installed in each of release and debug mode - those lines of debug info cause the app to encounter an exception!
can anybody explain what's going in there?
You can try to check if debugger is attached, then execute codes specific for debugging purpose only if IsAttached value is true :
if(System.Diagnostics.Debugger.IsAttached)
{
System.Diagnostics.Debug.WriteLine();
}
I have a visual studio installer project which installs a C# app, I have a custom action and code to run the process after install is complete.
Let's say the logged in user on windows machine is "john". Now when john runs the msi installer, I check the process in the taskmanager and it shows that msiexec.exe is the process name for installer and it is running as user "john"
The installer completes and runs the install app's process myapp.exe now when I check this process in taskmanager of windows it shows that myapp.exe is running as SYSTEM (which I do know what account is that and why its not running as john)
Problem
When myapp.exe runs as SYSTEM user it can not create com component instance of a component (iTunes in my case) which was already running as user john. If the component was not running then creating isntance of the iTunes is sucessful, otherwise it fails.
Question
So is it possible to make sure when installer runs as john, when it finishes it starts process myapp.exe as john and not as SYSTEM user ? Note that I do not asks user for password during installer.
Code that I run when installer completes
// Event handler for 'Committed' event.
private void MyInstaller_Committed(object sender, InstallEventArgs e)
{
try
{
Directory.SetCurrentDirectory(Path.GetDirectoryName
(Assembly.GetExecutingAssembly().Location));
Process.Start(Path.GetDirectoryName(
Assembly.GetExecutingAssembly().Location) + "\\MyApp.exe");
}
catch
{
// Do nothing...
}
}
This most likely happens because you are running your custom action as deferred. i.e. it is running by default under the SYSTEM user account.
A solution is to make sure you launch it immediate, for example you can launch it using a published event on the "Finish" button from the last dialog of the installation. I don't know exactly how to add a published event in VS setup projects, or if it is possible, but you can easily add one in packages built with specialized setup authoring tools.
In the Form_Load event write like this:
string lUserName=Environment.GetEnvironmentVariable("USERNAME");
Then instead of getting system user account you will get windows login user name at the time of installing MSI.
Personally I did manage to resolve this by running explorer.exe parameterized with the path to my app's executable:
Process.Start(
new ProcessStartInfo
{
FileName = "explorer.exe",
Arguments = Context.Parameters["target"],
UseShellExecute = true
});