Visual Studio 2015 RC
Wix v3.10.0.1726
I am creating a installer for a windows services. I've tested the service with InstallUtil and it runs fine. Unfortunately I'm having a bit of troubles with wix, here is the exact error -
"Service 'Service Name' failed to start. Verify that you have sufficient privileges to start system services."
Now I've narrowed down the issue to starting the service through WIX. If I forgo the ServiceControl tag and manually start it with services.msc it works fine.
From other questions it appears this error is a general catch error and occurs in a variety of situations. The most popular being if your service relies on assemblies installed to the GAC (Global Assembly Cache) which I am also unclear about. I never implicitly save anything to the GAC and my service simply calls a .cs file I wrote that is included in the project.
Any help would be greatly appreciated!
<Component Id="ProductComponent7">
<File Source="$(var.ServiceName.TargetPath)" KeyPath="yes" Vital="yes"/>
<ServiceInstall Id="ServiceName.exe"
Account="LocalSystem"
Arguments="-start"
Type="ownProcess"
Name="ServiceName.exe"
DisplayName="ServiceName Service"
Description="sdfg"
Start="auto"
Interactive="yes"
ErrorControl="critical" />
<ServiceControl Id="ServiceControl" Name="ServiceName" Start="install" />
</Component>
I've also tried a variety of different attributes in ServiceControl, I recently removed them all to try to make it as simple as possible.
If anyone has any insight that'd be great!
The issue appears to be that you've installed a service called ServiceName.exe and you're trying to start a serice called just ServiceName. The Name values need to match.
Correct, it's a generic error. You have to profile your service to understand why it won't start.
GAC is just one scenario. In that case it's because MSI doesn't publish assemblies to the GAC until after StartServices. A classic race condition that results in a missing dependency and error.
With the message box still up, run the EXE from the console. Do you get an errors? Do you get any errors in your application log? Find out why the service won't fix, resolve it and try again.
For me, the error was due to that Name attribute in the ServiceInstall tag was having a different name value from the one specified in the ServiceBase child class InitializeComponent() method.
Code updates:
In Product.wxs:
<ServiceInstall Id="ServiceInstaller"
Type="ownProcess"
Name="MyWindowsService"
DisplayName="$(var.ServiceDisplayName)"
Description="$(var.ServiceDiscription)"
Start="auto"
Account="LocalSystem"
ErrorControl="normal" />
In ServiceBase child class:
private void InitializeComponent()
{
components = new System.ComponentModel.Container();
this.ServiceName = "MyWindowsService";
}
Related
We are creating a UWP application which is intended for Side loading only.
At various times this application needs to reboot the PC (it's desktop only), to do this we intend to use LaunchFullTrustProcessForCurrentAppAsync() to call a simple external EXE which uses Process.Start("shutdown") to reboot the PC.
We have created the EXE called RebootPC.exe and on it's own it works fine.
We now include it in our UWP project:
First we add the desktop and rescap namespaces to our project and we also add rescap to our IgnorableNamspaces
xmlns:desktop="http://schemas.microsoft.com/appx/manifest/desktop/windows10"
xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
IgnorableNamespaces="uap mp uap5 rescap">
Then, we then modify the Extension section to include our EXE, we know we cannot put the EXE in our project root as C# compiler removes it so we have put it in a sub folder (in this case \Assets). We also set the EXE's type to 'Content' and 'Copy always' in the Solution explorer
<desktop:Extension Category="windows.fullTrustProcess" Executable="Assets\RebootPC.exe">
<desktop:FullTrustProcess>
<desktop:ParameterGroup GroupId="rebooter" Parameters=""/>
</desktop:FullTrustProcess>
</desktop:Extension>
finally in the manifest we add rescap to the Capabilities section - we know it has to be first in the list otherwise you get a manifest error when packaging
<Capabilities>
<rescap:Capability Name="runFullTrust"/>
<Capability Name="internetClient" />
<DeviceCapability Name="bluetooth" />
<DeviceCapability Name="radios" />
OK, so the manifest is changed. We now go to our C# code:
In that we perform the following:
if (ApiInformation.IsApiContractPresent("Windows.ApplicationModel.FullTrustAppContract", 1, 0))
{
try
{
await Windows.ApplicationModel.FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync();
}
catch (Exception ex)
{
Debug.WriteLine(ex.Message);
}
}
When we build and run the project in Visual Studio it seems to work fine, under the intended circumstances the PC will reboot as intended.
The problem comes when we try to package it for installation on other PCs. We use Store->Create App Packages (remember this application is for side loading only).
The creation of the package works fine and we can install it on other PCs with no problem. The problem is that when we run the Application and it comes time to run the external EXE to reboot the PC a command window opens but we get an exception saying "System can't find c:\users.......\Assets\RebootPC.exe"
So, even though the packaging is done without error and even though we have set the properties of RebootPC.exe to 'Content' and 'Copy always' it is either not being included in the package or not being installed along with the App?
So, does anyone know how we can check if it is being included in the package? and if so how we can check if and where it is being installed on the target machine? or has anyone else had this issue and found the solution?
This has had us baffled for days and is driving us crazy!!!
UPDATE: I think the issue may not be that RebootPC.exe can't be found but rather shutdown.exe - If this is the case then it's a bit of a school boy error!!!
Anyway, I will sort this and see if that fixes the issue
I will leave the rest of the question up as it might provide useful information for others
As Mentioned in the official sample the exe file has to in the Appx folder of your project
Make sure the RebootPC.exe was copied to the Appx folder -
UWP\bin\x64\Release\AppX if not rebuild the solution or copy it
manually.
https://github.com/Microsoft/DesktopBridgeToUWP-Samples/tree/master/Samples/AppServiceBridgeSample#builddeploy-and-run-the-sample
try
{
await Windows.ApplicationModel.FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync("rebooter");
}
catch (Exception ex)
{
Debug.WriteLine(ex.Message);
}
}
I am struggling with very strange situation with wix installer.
I have custom BA app which installs windows service and removes it on uninstall.
On Win XP everything is working perfectly but on Win 10 service is not stopped and not removed though uninstallation processed successfully.
In log files I cannot see any errors related to this.
Any ideas?
This is service install configuration:
<ServiceInstall
Id="MyServiceInstaller"
Type="ownProcess"
Name="MyService"
DisplayName="My Service"
Description="My Service"
Start="auto"
Account="[SERVICEACCOUNT]"
Password="[SERVICEPASSWORD]"
ErrorControl="normal" />
<ServiceControl Id="StartMyService"
Name="MyService"
Start="install"
Wait="no" />
<ServiceControl Id="StopMyService"
Name="MyService"
Stop="both"
Remove="uninstall"
Wait="yes" />
Round 2:
I jumped the gun here. As Chris says, we do need to see the log. I assumed the uninstall was hanging, which it does not seem to be at all.
ARP: I suppose you should quickly check if there are two product entries in Add / Remove Programs first of all? (don't think that is the problem either - failed major upgrade).
SharedDllRefCount: Is the SharedDllRefCount attribute set to yes for the service component? Please post the whole component markup, with all attributes specified - conditions and all. If the component was set permanent, that would explain things, but then the uninstall wouldn't work on XP. Enabling SharedDllRefCount sets the legacy ref-count here:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\SharedDLLs
Some SharedDllRefCount cleanup details here: MSI not uninstalling .dll files
Conditions Table: Are there any entries in the Condition table? (Feature conditions).
Round 1 (misunderstood the question - again - a couple of items still apply):
Debug Logging: Perhaps try to run your uninstall with verbose, debug logging to see if you can get some more information about what the problem can be:
msiexec.exe /x {ProductCode} /L*vx! C:\Your.log
Security Software: Is there anti-virus or security software on the problem box? If so, try to disable it before you run the uninstall.
Event Log: Maybe have a quick look for any clues in the event viewer? (Windows + Tap R. type eventvwr and pressOK). Check the different logs.
Custom Actions: Do you have any custom actions that run on uninstall? If so, what type of custom action? Managed code?
Service Credentials: Is the password for the service account still valid on that problem box? If worst comes to worst, can you log on with those service credentials (if that is possible) and try to start and stop the service to check for errors? Maybe even try to run the service with your own admin account? This is not ideal any of it, and should only be done to get to the bottom of this.
There have been a lot of service questions on StackOverflow lately. Here are some recent answers:
Wix - ServiceControl start takes four minutes to fail, should be 30 sec
Wix Service Installer sometimes fails to install or start
Wix installer: installed service unable to read HKLM registry entries on start
Everything was working fine and all of a sudden I started getting the following error for all my web projects and websites. One thing is for sure that this is IIS issue since the compiler is not even reach the code.
Error Message:
HTTP Error 500.0 - Internal Server Error
Tracing area "Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module,FastCGI,WebSocket,Rewrite,RequestRouting,iisnode" is not recognized
I've already tried following things one by one but no luck:
Re-install Tracing - 'Turn Windows features on or off',
Re-install IIS,
aspnet_regiis -i (also tried with -u),
Removed ISAPI .DLL
Windows Features:
I'm using Visual Studio 2013 to build a web project (asp.net C#).
I would really appreciate any help/information on this Issue.
I removed below tag from applicationhost.config file located under C:\Users\Sanket\My Documents\IISExpress\config path on windows 7 machine.
<add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module,FastCGI,WebSocket,Rewrite,RequestRouting,iisnode" verbosity="Verbose" />
See if this helps.
From Richard Marr's Blog here, following solutions are listed and second solution worked for me.
Using Programs and Features find the Extension that is missing trace areas, right click select REPAIR.
Manually add the trace areas to the Applicationhost.config file as shown below. Remember to add in the "WWW Server" xml Node.
Sanket's suggestion works, but for me what was missing was
<add name="RequestRouting" value="2048" />
a few lines above in the applicationhost.config file, where all areas are defined. Adding this fixed it.
Btw. using VS2015 also fixes the problem without editing the .config file.
Do you have all modules listed in error message installed? You can download extensions here: (link for rewrite module) http://www.iis.net/downloads/microsoft/url-rewrite
To add to Sanket's solution:
In case you are not using IIS Express, in
C:\Inetpub\Wwwroot\Web.Config
Delete the line with:
"Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module,FastCGI,WebSocket,Rewrite,RequestRouting,iisnode" verbosity="Verbose"
In my case I was getting the error in IIS (NOT IIS express). I answered this question here:
https://stackoverflow.com/a/51717759/2817987
When using TFS to build my application, it fails when I have an application with Brokered components.
Here is what I am using in my Package.appxmanifest, and it works when I build/run locally. How can I still build/deploy using TFS and keep my brokered components? Is this possible?
<Extensions>
<Extension Category="windows.activatableClass.inProcessServer">
<InProcessServer>
<Path>clrhost.dll</Path>
<ActivatableClass ActivatableClassId="BrokeredRuntimeComponent.{ClassName}" ThreadingModel="MTA">
<ActivatableClassAttribute Name="DesktopApplicationPath"
Type="string"
Value="C:\Source\{AppName}\Debug\BrokeredRuntimeComponentProxy" />
</ActivatableClass>
</InProcessServer>
</Extension>
</Extensions>
When I run the build, I get the following error. I do not have access to run the regsvr32 /s on our TFS. Is this something that needs to be done on every client or can it be done on the build server and run on every device? I think it might work if it's possible to get the build service to run as administrator. Is this even possible?
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets (1620): Failed to register output. Please try enabling Per-user Redirection or register the component from a command prompt with elevated permissions.
Please let me know if anything I've put here is unclear so I can hopefully clarify.
You need to have everything installed on your build server that your need to run a build locally. If you need certain registered components then that needs done in advance or at build time.
If at build time then the account that TF build runs under needs permission to perform that action.
These days I'm very much busy on developing an activex/com application. Some of our customers are working under heavily restricted windows environments. So i decided to make my application regfree. I found genman32.exe which can easily create manifests (also mt.exe is useful). Everything went fine but when i tried to execute my application from wsh(vbs or js) -which is obligated for my the situation because the application works on a com server-
set o = CreateObject("Application.Interface")
// No object reference
Because "CreateObject" looks to the registery and there is no registery entry :) then i searched and found the thing that is "actctx". It is very easy to implement in a dot.net environment. But i must execute my application from wsh(vbs or js) ;) so i decided to search a little then found
set o = CreateObject("Microsoft.Windows.ActCtx")
o.manifest = "L:\\Application.dll.manifest"
set app = o.CreateObject("Application.Interface")
app.Launch() // which is my executing function
Problem -
"Microsoft.Windows.ActCtx" interface is not available in Windows Xp machines even in SP3 - Microsoft never lets it easy -
Is there any solution to that problem? Do You know any other methods or windows update that creates that interface?
I figured out the problem with my manifest. I'll share it with anyone else who may have run into a similiar problem.
Please be aware that you MUST specify the progid="" property in your manifest when using this with the "Microsoft.Windows.ActCtx" interface otherwise you get ActiveX Component Can't Create Object error.
<comClass
clsid="{ED59F192-EF2E-4BCC-95EB-85A8C5C65326}"
progid="myclass.process"
threadingModel = "Apartment" />
The following manifest example should get you up and running :)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity
type="win32"
name="myclass"
version="1.0.0.0"/>
<file name = "myclass.dll">
<comClass
clsid="{ED59F192-EF2E-4BCC-95EB-85A8C5C65326}"
progid="myclass.process"
threadingModel = "Apartment" />
<typelib tlbid="{7AE20C3A-48C2-42C1-A68D-A1C3EB0A2C65}"
version="1.0" helpdir=""/>
</file>
<comInterfaceExternalProxyStub
name="_PROCESS"
iid="{187D0811-470D-44C0-B68C-C1C7F3EEFDA0}"
proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"
baseInterface="{00000000-0000-0000-C000-000000000046}"
tlbid = "{7AE20C3A-48C2-42C1-A68D-A1C3EB0A2C65}" />
</assembly>
If the Microsoft.Windows.ActCtx were redistributable, there would have to be some way for it to get onto the machine and globally registered. If you had access to register this on the machine, can't you insted simply register Application.Interface? If you're dealing with a restricted environment ... well you have to deal with what's available already.
It looks like you're using the wsh script to launch your application. Why not write a stub to launch the app in native or managed code (where you will be able to use a manifest), and call that stub instead?