I have an NT service that has some perf counters. When I deploy the service using installutil, the perf counters and the service install fine. When I deploy using my msi, that uses ServiceInstall, the service shows up, but the perf counters don't get installed.
I always just assumed that ServiceInstall ran installutil under the covers. Is there some critical difference that would prevent me from installing perf counters?
Wix segment
<ServiceInstall Id='ServiceInstall' ErrorControl='ignore' Type='ownProcess' DisplayName='Service' Description='service' Name='Service' Start='auto' Account='[SERVICEACCOUNT]' Password='[SERVICEACCOUNTPASSWORD]' />
<ServiceControl Id='Service' Remove='uninstall' Name='Service' Start='install' Stop='both' Wait='yes' />
Perf counter install
[RunInstallerAttribute(true)]
[RegistryPermissionAttribute(SecurityAction.LinkDemand, Unrestricted = true)]
[EnvironmentPermissionAttribute(SecurityAction.InheritanceDemand, Unrestricted = true)]
public sealed class CountersInstaller : Installer
{
public CountersInstaller()
{
Installers.AddRange(Counters.Instance.PerformanceCounterInstallers());
}
}
No, your assumption is not correct. The ServiceInstall does not call InstallUtil under the hood for installing performance counters. Using InstallUtil is generally treated as a bad practice.
Instead, take a look at PerformanceCategory and PerformanceCounter elements. Of course, this will require some coding to transform what you do now with C# into declarative XML form.
Related
I have created a simple, stripped down project to try to get this to work: ASP.NET Core 6 WebAPI project, hosted as a Windows Service, just trying to get it up and running with the sample WeatherForecast controller. I have added NuGet package for Microsoft.Extensions.Hosting (6.0.1) and Microsoft.Extensions.Hosting.WindowsServices (6.0.0). My program.cs looks like:
using IRDSPrototype.Configuration;
using IRDSPrototype.Services;
using Microsoft.Extensions.Hosting.WindowsServices;
var webApplicationOptions = new WebApplicationOptions
{
Args = args,
ContentRootPath = WindowsServiceHelpers.IsWindowsService() ? AppContext.BaseDirectory : default
};
var builder = WebApplication.CreateBuilder(webApplicationOptions);
builder.Services.AddHostedService<IRDSHostingService>();
builder.Host.UseWindowsService();
builder.WebHost.UseUrls(UriServices.GetBaseUri().AbsoluteUri);
// Add services to the container.
builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
var app = builder.Build();
// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
app.UseSwagger();
app.UseSwaggerUI();
}
app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();
await app.RunAsync();
I created a background service as well:
public class IRDSHostingService : BackgroundService
{
public ILogger Logger { get; }
public IRDSHostingService(ILoggerFactory loggerFactory)
{
Logger = loggerFactory.CreateLogger<IRDSHostingService>();
}
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
Logger.LogInformation("IRDS Hosting Service is starting.");
stoppingToken.Register(() => Logger.LogInformation("IRDS Hosting Service is stopping."));
while (!stoppingToken.IsCancellationRequested)
{
await Task.Delay(TimeSpan.FromSeconds(5), stoppingToken);
}
Logger.LogInformation("IRDS Hosting Service has stopped.");
}
}
I also created a service installer via Wix. When I run the installer it gets to the point of "Starting services" and fails with a message 'Verify that you have sufficient privileges to start system services'. When I check Windows Application Log, I see that error and a also see an error for:
Application: IRDSPrototype.exe
CoreCLR Version: 6.0.822.36306
.NET Version: 6.0.8
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException: Could not load file or assembly 'System.ServiceProcess.ServiceController, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
File name: 'System.ServiceProcess.ServiceController, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
My publish directory and Wix manifest do include the System.ServiceProcess.ServiceController.dll.
I installed the service via sc.exe and the install succeeded, but starting the service gives an Error 5: Access Denied message. Unlike with the installer, though, this didn't generate any messages in the Windows log. I checked permissions on the folder containing the executable, giving full permissions to NETWORK SERVICE and LOCAL SERVICE. That didn't help. So I'm kind of stuck on what to do now. All my internet searches basically guided me to the setup I have now and it still doesn't work. So I'm at a loss. Anyone have any suggestions of what I'm missing here?
Thanks,
Dennis
Edit: So I'm whittling down the problem. It turns out I needed the version of System.ServiceProcess.ServiceController.dll that was published to my 'runtimes' folder under the .Net 6.0.0 runtime. So that error no longer shows up in the Event Viewer. The only erro that shows in the Event Viewer now is:
Error 1920. Service 'IRDS Prototype' (IRDSPrototype) failed to start. Verify that you have sufficient privileges to start system services
I have it installing as a Local Service and I believe I've given Local Service full permissions on the proper folders but I will check that. Still looking for suggestions though.
Edit #2: Getting closer. The problem I had when installing through sc.exe was that my binPath was wrong. I wasn't including the exe file in the binPath. Now I can install my service through sc.exe and it starts and works properly. The service still won't start when installed via my Wix installer though. So now I'm down to a Wix issue. Anyone with experience installing Windows services via Wix?
OK, it turns out what I needed to do was publish as a single executable:
Notice the "Deployment Mode: Self-contained" choice and "Produce single file" checked. After publishing that way, I only had to add the executable (no other files) to my Wix manifest and the generated installer worked fine. I'm guessing I was missing a dependency somewhere that I didn't know about. But it's weird that I was able to install and start the service from the same publish directory as I was trying previously with Wix via sc.exe. Anyway, it works now. Thanks to Md Farid Uddin Kiron for redirecting me back to the official page, which I read a little more carefully this time and found the little blurb about this being recommended.
I have a service component installed twice in one of my previous releases.
<Component Id="MyServiceWin7" Guid="{GUID_WIN7}">
<File Id="mysvc_Win7"
Name="mysvc.exe"
Source=mysvc.exe"
KeyPath = "yes"/>
<ServiceControl Id="MYSVC_Win7"
Name="MYSVC"
Remove="uninstall"
Start="install"
Stop="both"
Wait="no" />
<ServiceInstall Id="My_Svc_Win7"
Name="MYSVC"
DisplayName="MYSVC"
Type="ownProcess"
Start="auto"
ErrorControl="normal"
LoadOrderGroup=""
Description="My service">
</component>
<Component Id="MyServiceWin8" Guid="{GUID_WIN8}">
<File Id="mysvc_Win8"
Name="mysvc.exe"
Source=mysvc.exe"
KeyPath = "yes"/>
<ServiceControl Id="MYSVC_Win8"
Name="MYSVC"
Remove="uninstall"
Start="install"
Stop="both"
Wait="no" />
<ServiceInstall Id="My_Svc_Win8"
Name="MYSVC"
DisplayName="MYSVC"
Type="ownProcess"
Start="auto"
ErrorControl="normal"
LoadOrderGroup=""
Description="My service">
</component>
So there will be two instances of the MYSVC component. Both are mapping to MYSVC.exe.
I missed the OS version condition check in the previous release.
It runs successfully.
I am thinking to delete the dummy additional COMPONENT (GUID_Win7 or GUID_WIN8) in the next update.
How I can delete it, do I need to write a custom action?
Any help would be appreciated.
EDIT::
Please find answers,
mysvc is having some third party lib dependancy os specific Win7 and Win8, it works means it installed successfully if we check sc qc mysvc I get service created and mysvc.exe is mapped to service binpath
yes these two service components targets same destinationand there is only one component when I do sc query mysvc
No there only one entry of service. mysvc.exe is win8 version on disk.
Thanks for suggestions, that breaking link.
Currently I have %ProgramFiles%\MyApp\mysvc.exe common path for both win 7 and win8.
So my question if create new common path to break previous link.
ProgramFiles%\MyApp\mysvc\mysvc.exe [[NEW_GUID1]] for win7
ProgramFiles%\MyApp\mysvc\mysvc.exe [[NEW_GUID2]] for win8
Components with [[OLD_GUID1]] , [[OLD_GUID2]] will be on system forever
until my product is uninstalled, so cant we just delete components with [[OLD_GUID1]], [[OLD_GUID2]] to clean stale(non functional) components
Thanks
Some Questions:
First of all, can we ask why you decided to install the service in two flavors? Does this mean that the service has different binaries for Win7 and Win8? If so, then it is unclear why you say it works as it stands.
Do these service components target two different installation locations so they both run side-by-side, or do you target the same target destination with both components? (so there is only one instance of the file after installation).
Are there two entries in the list of services on the box after installation? If you target the same location with both components, what file version of mysvc.exe made it onto the disk? (if they are different).
I wrote the below before the above questions. Please update your question with the answers to the questions. The below might be irrellevant - we need more information.
Sins of The Past: If you have installed the same file twice with two different component GUIDs in the previous version then this is wrong and I would recommend you "break the link" to the sins of the past by setting two new component GUIDs for the new release and crucially: set a new absolute installation location for each component (do not target the same absolute key path with two different GUIDs! - conditions or not).
The idea is to de-couple the old and new versions so that you start with a clean(er) slate.
Something like:
Comp 1: {77777777-7777-7777-7777-777777777777}, [ProgramFilesFolder]My App\Win7\mysvc.exe
Comp 2: {42424242-4242-4242-4242-424242424242}, [ProgramFilesFolder]My App\Win8\mysvc.exe
Personally I would avoid the Windows version number and maybe use something else. How about a year?
Comp 1: {77777777-7777-7777-7777-777777777777}, [ProgramFilesFolder]My App\2007\mysvc.exe
Comp 2: {42424242-4242-4242-4242-424242424242}, [ProgramFilesFolder]My App\2014\mysvc.exe
Just to not hard code a misleading value if the Win8 version runs on Win10 for example.
N.B!: Note that the above, sample GUIDs are well-known and dysfunctional GUIDs and
should not be copied and used! This is of high cruciality :-).
My first question is about the error below :
Module [Path/Name of dll].dll failed to register. HRESULT -2147024769. Contact your support personnel.
I can continue the installation but i want to get rid of this error if possible.
The second question is about the following error :
Error 1001. Exception occured when initializing the installation.
System.IO.FileNotFoundException: could not load file or assembly 'file:///C:\Windows\SysWOW64\files' or one of it's dependencies. The system cannot find the file specified.
I saw in different site and thread that the cause was the custom Action (in the value : /target=”[TARGETDIR]” -> /target=”[TARGETDIR]\”) but I can't found where is the error in my custom action. Here are the custom action realized using Designer for Wix Toolset :
<CustomAction Id="DIRCA_TARGETDIR" Property="TARGETDIR" Value="[ProgramFilesFolder][Manufacturer]\[ProductName]" Execute="firstSequence" />
<CustomAction Id="_FB3FF635_EF79_4863_91BD_70A0A11955B2.Uninstall" Execute="deferred" BinaryKey="InstallUtil" DllEntry="ManagedInstall" adx:VSName="Primary Output from Project" />
<CustomAction Id="_FB3FF635_EF79_4863_91BD_70A0A11955B2.Uninstall.SetProperty" Property="_FB3FF635_EF79_4863_91BD_70A0A11955B2.Uninstall" Value="/installtype=notransaction /action=uninstall /LogFile= /targ="[TARGETDIR]\" /usr=[ALLUSERS] /usr2=[MSIINSTALLPERUSER] /CommonProjAppData="[PROJCOMMONDATA]\" "[#_F521D169_ECD0_42B5_87F7_C2D8B6F9CA54]" "[VSDFxConfigFile]"" adx:VSName="Primary Output from Project" />
<CustomAction Id="_BE73DAD9_3524_4376_B45C_148B5871465B.Install" Execute="deferred" BinaryKey="InstallUtil" DllEntry="ManagedInstall" adx:VSName="Primary Output from Project" />
<CustomAction Id="_BE73DAD9_3524_4376_B45C_148B5871465B.Install.SetProperty" Property="_BE73DAD9_3524_4376_B45C_148B5871465B.Install" Value="/installtype=notransaction /action=install /LogFile= /targ="[TARGETDIR]\" /usr=[ALLUSERS] /usr2=[MSIINSTALLPERUSER] /CommonProjAppData="[PROJCOMMONDATA]\" "[#_F521D169_ECD0_42B5_87F7_C2D8B6F9CA54]" "[VSDFxConfigFile]"" adx:VSName="Primary Output from Project" />
<CustomAction Id="CA_CreateConfig" BinaryKey="ADXDPCADLL" DllEntry="GetConfig" />
Thanks for helping.
You're basically going in the wrong direction. You've converted a Visual Studio setup to WiX but you're trying to carry that VS custom action framework into WiX. The VS framework that calls managed code custom actions involves calling a C++ binary that then tries to load a NET runtime then use reflection to get into your assembly, instantiate classes and call methods. Apart from the fact that the InstallUtil Dll is transparent, undocumented and architecture dependent (you need either the 64-bit version or the 32-bit version) and therefore impossible to debug in cases like this, nobody actually bothers to propagate all this stuff into the WiX world because there are much better alternatives. For example if you're using installer classes to install services you don't need them at all. See ServiceInstall and ServiceControl. For generic custom action calls into managed code use the DTF managed code custom action framework.
I try to use Azure Table Storage for the persistence of timeout data and I experience an error on environments other than my local development machine.
My local machine is creating the timeout tables on Azure and is able to poll timeout data successfully. But, if I host the same software on premise on another server it failed to fetch the timeouts. I receive the following error:
2015-02-12 09:43:50,638 [10] WARN NServiceBus.Timeout.Hosting.Windows.TimeoutPersisterReceiver - Failed to fetch timeouts from the timeout storage
System.NullReferenceException: Object reference not set to an instance of an object.
at NServiceBus.Timeout.Hosting.Windows.TimeoutPersisterReceiver.Poll(Object obj) in c:\BuildAgent\work\1b05a2fea6e4cd32\src\NServiceBus.Core\Timeout\Hosting\Windows\TimeoutPersisterReceiver.cs:line 88
at System.Threading.Tasks.Task.Execute()
It seems that the TimeoutPersister is null at the point it wants to fetch data from it.
I host NServiceBus using the NServiceBus.Host. My endpoint configuration looks like this:
public class EndpointConfig : IConfigureThisEndpoint, AsA_Server
{
public void Customize(BusConfiguration configuration)
{
configuration.UsePersistence<AzureStoragePersistence>();
configuration.EndpointName("MyEndpoint");
configuration.UseTransport<RabbitMQTransport>()
.DisableCallbackReceiver();
configuration.DisableFeature<Sagas>();
configuration.ScaleOut().UseSingleBrokerQueue();();
}
}
And my app.config contains:
<connectionStrings>
<add name="NServiceBus/Transport" connectionString="host=myrabbitmqserver;virtualhost=myhost;username=me;password=secret" />
</connectionStrings>
<AzureTimeoutPersisterConfig ConnectionString="DefaultEndpointsProtocol=https;AccountName=myaccount;AccountKey=myaccouuntkey;" TimeoutManagerDataTableName="TimeoutManager" TimeoutDataTableName="TimeoutData" />
Does anyone have any idea what I am doing wrong or can anyone point me in the right direction investigating what the problem can be?
Update 1
It seems that the NServiceBus.Azure assembly is not loaded on the other machines. So azure persistence features are not initialized resulting in NullReferenceException when using the TimeoutPersister.
Update 2 After some NServiceBus debugging I noticed that an exception was thrown when extracting the types from the NServiceBus.Azure.dll assembly. It is unable to load the referenced assembly Miscrosoft.Data.Services.Client.dll 5.6.0.0. This assembly is indeed not in the bin folder. The present version is 5.6.3.0. The NServiceBus.Azure NuGet package supports versions >= 5.6.0.0 < 6.0.0.0, but somehow it's still expecting version 5.6.0.0. It still feels weird that it is working on my development machine? Maybe there are some old versions of the Microsoft.Data.Services.Client.dll installed on my machine as part of the Azure SDK, which are found during the assembly loading.
Update 3
I indeed had somewhere at my system the older 5.6.0 version available. Downgrading the Microsoft.Data.xxx packages to version 5.6.0 solved the issue for now. Does anyone have the same issues using 5.6.3 versions and found a solution for that?
Update 4
Since 2015-02-13 a new version of NServiceBus.Azure is released and now it requires Microsoft.Data.Services.Client version 5.6.2.0. I am still not able to use the 5.6.3 version. Adding a assembly binding redirect will not help either.
The binding redirect must be added to the NServiceBus.Host.exe.config instead of the app.config. Pretty annoying because visual studio automatically updates the app.config.
Information from Yves Goeleven:
The reason is that default load behavior of the CLR is at the process level, which includes the host config, once the host is loaded we actively switch over to the appdomain level (using topshelf) from then on it uses the endpoint's config...
But if the CLR needs to resolve the reference prior to the switch to the appdomain, you will have to put the redirect at the host level (and at the endpoint level I guess)
It should work with 5.6.3 version. Try adding assembly bindingRedirect in the following way:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.Services.Client" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.6.0.0" newVersion="5.6.0.0" />
</dependentAssembly>
I am trying to install windows services using WIX. The windows services are installing fine and if I check inside Service Manager I am able to see that my services are installed and are trying to start as shown below:
After 3 to 4 minutes I am getting error sufficient privileges required. Please see the image for the error message:
If I run my windows services setup manually then it's installing fine without any problem in starting up. What I am doing wrong can anyone help?
Following is the code that I am using:
public ProjectInstaller()
{this.ServiceProcessInstaller = new System.ServiceProcess.ServiceProcessInstaller();
this.ServiceInstaller = new System.ServiceProcess.ServiceInstaller();
//
// ServiceProcessInstaller
//
this.ServiceProcessInstaller.Account = System.ServiceProcess.ServiceAccount.LocalService;
this.ServiceProcessInstaller.Password = null;
this.ServiceProcessInstaller.Username = null;
//
// ServiceInstaller
//
this.ServiceInstaller.ServiceName = "Service";
this.ServiceInstaller.StartType = System.ServiceProcess.ServiceStartMode.Automatic;
}
Following is my WIX code:
<File Id='SetupService' Name='SetupService' DiskId='1' Source='setup.exe' KeyPath='yes'/>
<ServiceInstall Id="ServiceInstaller" Type="ownProcess" Name="SetupService" DisplayName="DataLogsetup" Description="Service" Start="auto" Account="[SERVICEACCOUNT]" Password="[SERVICEPASSWORD]" ErrorControl="normal"/>
<ServiceControl Id="StartService" Start="install" Stop="both" Remove="uninstall" Name="SetupService" Wait="yes" />
I have also tried to pass in [LocalService] in the Account, but still I am getting the same error. Is there anyway I can install my service using WIX?
I see several reasons which may lead to failure here:
You are not calling
Installers.Add(this.ServiceInstaller);
Installers.Add(this.ServiceProcessInstaller);
at the end of your method. The Installers.Add(..) line should actually add the service to service table. See the example at the end of this page
As far as I know, Installer classes are not supported in WIX, Custom Actions are used instead. How do you call your code from WIX?
WIX has a <ServiceInstall> element for installing services. Although not allmighty, this element is very powerful and the preferred method to install Windows Services. See Installing and starting a Windows Service using WiX