Following the advice of Henk, I've created a Setup Project in VS10 with the aim of adding a custom action. This custom action will hopefully add an EventLog whilst running as admin (ie during installation) rather than having my app throw an exception on OSes with UAC.
Unfortunately, I don't ordinarily have access to an OS that uses UAC. The next time I do, I hope the installation will go smoothly.
With that in mind, is there anything in the below code which is obviously wrong?
using System;
using System.Diagnostics;
namespace EventLogCreator
{
class Program
{
static void Main(string[] args)
{
switch (args[0])
{
case "-i":
if (!EventLog.Exists("SSD Log"))
{
Console.WriteLine("Log not found, creating.");
EventLog.CreateEventSource("setup", "SSD Log");
}
break;
case "-u":
if (EventLog.Exists("SSD Log"))
{
Console.WriteLine("Log found, removing.");
EventLog.Delete("SSD Log");
}
break;
}
}
}
}
The output of this project is sucked into the setup project. I then have two custom actions:
On install with "-i" as an argument
On uninstall with "-u" as an argument
I'm not expecting a free code review, but I'm venturing into the unknown here, so I'd appreciate a heads up if I'm humping the wrong bit of trash.
PS I'm particularly concerned that I'm specifying the actual log name, but not an actual source. Will this matter?
You will probably be better off using the "EventLogInstaller" found in the "System.Diagnostics" assembly.
You can see a implementation of this when you create a custom component, then adding a event log component to the design surface, fill in the properties for the component, then click on the "Add Installer" link/command in property window. This will add a project installer component, which will contain a event log installer component.
The event log installer component is what you are looking for, basically it is a windows installer action that can be run when you create a windows installer package (MSI). All you have to do is specify the installer action in the "Custom Actions Editor" of your visual studio deployment project. There is quite a bit of information regarding custom actions in the MSDN library.
Also have a look at the following:
EventLogInstaller Class
Installer Tool (Installutil.exe) - msdn.microsoft.com/en-us/library/50614e95(VS.80).aspx
I can't remember or access the details right now but somewheren in that (horrible) UI for setup-projects there should be alist of 'standard' actions for, amongst others, creating an EventLog. That would be the safest way.
But you should be OK testing this w/o UAC. If it works, it works. A setup.exe runs as Admin
Related
Sorry for a long question but I have to put as many details as I can to help you understand this issue better.
I'm using an msi installer created by InstallShield 2012, it runs properly on most computers but on some I get the generic 1001 error and upon clicking OK on that error everything rolled back. To troubleshoot, I ran the following code to generate the debug log from the installation
Setup.exe /v"/l*v \"C:\log.dat\""
The debug log shows error 2769 with a custom action xxxx.install did not close 1 MSIHANDLES.
While googling about this issue, I see a lot of people having this exact same error and most of the suggestions come down to check what your custom action is doing because it is the one that generates this error.
Here are what I've done to troubleshoot and isolate this problem so far:
Open up the InstallShield project and look at the MSI deubbger, I noticed the custom action names in the log is part of the custom action InstallShield uses to install a Window Service as part of the installation.
I look at how this service is installed, it turns out to be a C# executable that InstallShield invokes as a .NET Installer Class to install the service under the component's setting.
As per what is .NET installer class? you can look at the note below from InstallShield.
Fearing something is not right with my custom action code, i put in some debug logging and run the whole installation again, I still receive the same error but I do not see any exception being logged. The service actually created successfully and i can even run it as long as I don't click OK on the 1001 error which will trigger the roll back and uninstall this service.
public ProjectInstaller()
{
try
{
using (StreamWriter w = File.AppendText("c:\\log.txt"))
{
Log("start installing", w);
}
InitializeComponent();
using (StreamWriter w = File.AppendText("c:\\log.txt"))
{
Log("End Install", w);
}
}
catch (Exception ex)
{
using (StreamWriter w = File.AppendText("c:\\log.txt"))
{
Log(ex.Message, w);
Log(ex.StackTrace, w);
}
}
}
private void InitializeComponent()
{
this.serviceProcessInstaller1 = new System.ServiceProcess.ServiceProcessInstaller();
this.serviceInstaller1 = new System.ServiceProcess.ServiceInstaller();
//
// serviceProcessInstaller1
//
this.serviceProcessInstaller1.Account = System.ServiceProcess.ServiceAccount.LocalSystem;
this.serviceProcessInstaller1.Password = null;
this.serviceProcessInstaller1.Username = null;
//
// serviceInstaller1
//
this.serviceInstaller1.Description = "Healthcare Platform Service";
this.serviceInstaller1.ServiceName = "psService";
this.serviceInstaller1.StartType = System.ServiceProcess.ServiceStartMode.Automatic;
//
// ProjectInstaller
//
this.Installers.AddRange(new System.Configuration.Install.Installer[] {
this.serviceProcessInstaller1,
this.serviceInstaller1});
}
Based on my troubleshooting so far, I don't think the error is within the custom action code. However, that really leave me hanging because I don't really know what cause the custom action to fails; it looks like something did not close out the msi handles but this is really a black box to me.....
So any idea what this might be?
How can I further delve down to figure out what the heck went wrong with this customer action _502E509F9B6F6675DFF9C310662BC1B5.install ?
Below are the custom actions sequence.
*EDIT:
I found the link that talks about the similar error I have... however I verified my custom action doesn't have any parameter and that based on my verbose debug log I see all the path are properly resolved.
**EDIT: Add custom action sequence screenshots.
The error is a generic one resulting from the infrastructure of installer classes not working. This is mostly a black box developed for Visual Studio setup projects. It uses a C++ Dll call to ManagedInstall which then loads a framework version, locates your assembly, instantiates your class with reflection and then calls the Install method. InstallUtilLib is architecture specific, and a mismatch between it and your managed code and the framework version will cause errors. If this happens only on one machine it might be this mismatch, or maybe that machine is broken in some way regarding that service.
That's just information that may help. However, if you have an actual InstallShield 2012 then you don't need installer classes at all. They were created for Visual Studio setups, and are not needed for practically every other MSI building tool that exists because they have built-in support for the MSI ServiceInstall and ServiceControl tables.
To quote Jerry MaGuire... Stop, you had me at 1001. InstallUtil managed custom actions must be avoided at all cost. The first action is to eliminate the need for the custom action by using native windows installer capabilities. If the custom action is still needed the second action is to refactor using Windows Installer XML (Wix) Deployment Tools Foundation (DTF). Is a far better pattern for integrating managed code with MSI. It works very well with InstallShield.
IMO, InstallShield should have never made it so easy to wire up an InstallUtil custom action. They undoubtedly did so to satisfy customer requests and to ease migration to InstallShield but at the huge sacrifice of quality standards.
I really need to see where this is sequenced. If this is deferred and before install initialize or after install finalize, that could be an issue.
Hmm,
This is rather interesting... I found a Microsoft link that talks about the Event Source
By default, if I uninstall my software the event source will get removed as well. For some reason that is not the case I see, i think it isn't removed because the file to which EventMessageFile points to was being used/uninstall?
So reading the article above I went and remove out the registry manually found under
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\MyProgramName
The installation no longer gives me 1001 error after I remove the above registry. It looks like InstallShield tries to install a window service but upon looking at this registry it deems the services already exists (even though it isn't).
I trigger an c# application by an custom action:
On failing condition, my application tells Install Shield to abort the installation process using an exit code:
static void Main(string[] args)
{
if(false)
{
Environment.ExitCode = 1;
}
}
Using this approach, Install shield´s setup displays an error message like expected:
How can I overwrite that error message by a custom text?
Reading between the lines here, it appears your custom action launches an EXE. If that is so, there is no way to do what you ask. You could show a message from your EXE before returning a non-zero exit code, but then Windows Installer would still show the Error 1722 message.
If you can instead run a function from a DLL, you have more options. Instead of returning errors, you'd be able to set properties (assuming this is an immediate mode action), and could use those properties to do further things, such as show another dialog, or exit the installation without the Error 1722 message. I don't think all the necessary configuration options are available in the limited edition - you certainly cannot edit dialogs in LE - so to do all of that, you would have to change to a more capable tool (including the Professional edition, or options from other vendors).
I have an MSI installer that installs my Windows Service and in my custom actions I need to write some values into the Registry in the HKEY_LOCAL_MACHINE/SOFTWARE/MYSoftware key.
I am trying to do this and it's not working, but from my Windows Service it's working fine. Can anybody tell me where I am going wrong?
string registryLocaltion = AgentProperties.TMAGENT_REGISTRY_LOCATION
+ #"\" +AgentProperties.TMAgentVersion;
tmKeyMain = Registry.LocalMachine.OpenSubKey(registryLocaltion, true);
if (tmKeyMain == null)
{
log.Error("Unable to open registry key " + registryLocaltion);
}
tmKeyMain.SetValue("UseProxySettings", settings.UseProxySettings);
if (settings.UseProxySettings)
{
tmKeyMain.SetValue("ProxyHost", settings.ProxyHost);
tmKeyMain.SetValue("ProxyPort", settings.ProxyPort);
tmKeyMain.SetValue("ProxyUsername",
GenericHelper.ConvertToBase64Encoding(settings.ProxyUsername));
tmKeyMain.SetValue("ProxyPassword",
GenericHelper.ConvertToBase64Encoding(settings.ProxyPassword));
tmKeyMain.SetValue("ProxyExclusion", settings.ProxyExclusion);
tmKeyMain.SetValue("BypassProxy", settings.BypassProxy);
}
This code is working fine in my Windows Service, but if I do some thing very similar in my custom action in the MSI installer it doesn't work.
Can anybody tell me where I am going wrong?
You are up against a couple problems. The most obvious problem is that Visual Studio Deployment projects incorrectly schedule custom actions to impersonate the client context. This means in a UAC scenario you won't have permissions. The quick work around is to run the MSI from an already elevated command prompt context.
The second problem is that Visual Studio Deployment Projects abstract / hide the underlying MSI too much. For Custom Actions, it only gives you the options of "install, uninstall, rollback, commit" without exposing any additional settings. It hides the ServiceInstall and ServiceControl tables. This causes you to write a custom action that reinvents the wheel.
See, all your custom action should be doing is performing the business logic and setting properties. Then you should be using the Registry table to set the data based on the properties. This way you leverage as much of Windows Installer as possible and all of it's free transactional / rollback capabilities.
This problem repeats over and over and is why Microsoft killed of the setup project types in VS2012.
If it was my install, I'd be refactoring the design to use AppSearch/Reglocator to read in the data, have a minimalist custom action to do the processing and then use the Registry table to apply the data.
That will require you at a minimum to look at Windows Installer XML to create a merge module that has all of this logic and gets merged into your existing setup project. That takes awhile to learn though.
I'm creating a setup program for an application that will require the user to choose between three setup options. I would like to take the result of the user input and write to the registry, so that the application can read this value at run-time. From what I've read so far I've been able to create the custom dialog with radio buttons, but what I haven't been able to find is how to take the result of the user's selection and then run a custom action which will write the result to the registry. I assume I can write a small script or executable which I can launch from the custom action by adding this script or exe by adding it to the application folder, but how do I get the value selected to be passed to this script or exe?
Thanks for any advice.
Maybe those links will help you:
RadioButtons User Interface Dialog Box
How to: Set Conditional Installation Based on User Choices
creating setup c#
My two cents: I think you may consider using another suite to create your installation, like Installshield. The VS 2010 setup program is, IMHO, not a good setup program.
How do I configure a C# program to run when the operating system is first started?
If you want to run the program when the user logs on, then the "Startup" folder or Run registry key methods both work.
If you want the program to run when the computer is turned on (ie Windows starts), without waiting for the user to log on, you will need to install it as a service, and configure it to start automatically.
Just add the program to the Startup folder in the Start Menu.
add to registry
private void AddToRegistry()
{
RegistryKey regKey = Registry.CurrentUser.OpenSubKey(#"Software\Microsoft\Windows\CurrentVersion\Run", true);
regKey.SetValue(Application.ProductName, Application.ExecutablePath);
}
I believe you are going to have to convert this C# application into a Windows service and set its startup type to Automatic. That seems to be the approach most people use.
The easiest answer would be to add it to the Startup folder in your Start Menu. As far as I know simply dropping it in there should be enough (since it is just a little exe).
For a simple C# app, putting the app's .exe or a shortcut to it, in the start folder is the easiest approach.
To build it in a little bit more, you could add it to the registry, under "Software\Microsoft\Windows\CurrentVersion\" then the subkey that you require. For more info on the registry approach read this - http://support.microsoft.com/kb/179365
For a more complex approach which may/maynot be needed depending on your application you can create it as a service, and have it set to run automatically. For a simple app this isn't needed so I won't expand further on this point.
You can develop this program as a Windows service. Then you can configure it to re-start after a failure or subsequent failures which increases robustness. Just an idea...
I'm using Inno Setup for my installer and adding the following line will accomplish this:
Name: "{commonstartup}\YourFolder"; Filename: "{app}\YourApp.exe"; IconFilename: "{app}\YourApp.ico"
Also add this to your [setup] section
PrivilegesRequired=admin
Documentation http://www.jrsoftware.org/iskb.php?startup