I'm working on moving a set of installers from VS2010 to WIX and have encountered an error with our NT Service applications.
After creating and installing the NT Service using the WIX installer, the service is not looking for the app.config named as you would expect (ApplicationName.exe.config). Our application name is akin to XXX.YYYYYYYY and when injecting the debugger into the service during start up, i can see that it is looking for XXX.config instead of XXX.YYYYYYY.exe.config.
I've tried running the application via the console and when I do, it looks for the correct app.config file name. Using the VS2010 installer also has the service looking for the correct app.config file name.
Is there some setting in wxi3.8 that I am missing, or putting the incorrect value into, that would cause this? Here is the segment of the wxs that controls the service:
<Component Id="Service" Guid="DCE18608-D25F-4DC0-9E1B-C2E3575D0BFE">
<File Id="ServiceComponentMain" Name="$(var.XXX.YYYYYYY.TargetName)" Source="$(var.HHG.SpecOrderLoadSync.TargetPath)"
DiskId="1" Vital="yes" KeyPath="yes"/>
<ServiceInstall Id="Service" Name="$(var.XXX.YYYYYYY.TargetName)" Type="ownProcess" DisplayName="$(var.XXX.YYYYYYY.TargetName)"
Description="$(var.XXX.YYYYYYY.TargetName)" Start="auto" Account="NT AUTHORITY\LocalService" ErrorControl="normal">
<util:PermissionEx User="Everyone" ServicePauseContinue="yes" ServiceQueryStatus="yes"
ServiceStart="no" ServiceStop="yes" ServiceUserDefinedControl="yes"/>
</ServiceInstall>
<ServiceControl Id="Service" Stop="both" Remove="both" Name="$(var.XXX.YYYYYYY.TargetName)" Wait="no"/>
Finally figured this out after digging around the registery. It appears that with my current wsx file it isn't registering the full path to the executable including ".exe" at the end. This is what is causing the config file name to be confused. Why in the world this makes a difference is beyond me, but just another thing to annoy me about windows i guess...
To fix, changing the Name on the File element in the segment above to be $(var.XXX.YYYYYYY.TargetName).exe instead of just $(var.XXX.YYYYYYY.TargetName) seems to work.
Related
I am trying to register my COM Add-in using the RegAsm command using the WIX Setup. But am unable to do it. It is showing blank against the WixNetFxExtension's NETFRAMEWORK40FULLINSTALLROOTDIR or even NETFRAMEWORK40CLIENTINSTALLROOTDIR.
Here is the code for the custom action:
<CustomAction Id="RegisterUsingRegAsm" Directory="PROOFIX_ADDIN" Execute="deferred" Impersonate="no" Return="check"
ExeCommand='"[NETFRAMEWORK40FULLINSTALLROOTDIR]regasm.exe" "[PROOFIX_ADDIN]Proofix.View.dll" /codebase' />
When I try to hardcode the path C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe. It works fine...
and Here is the Sequence information:
<InstallExecuteSequence>
<Custom Action="RegisterUsingRegAsm" Before="InstallFinalize" />
</InstallExecuteSequence>
Here is the log generated for the installer:
Action: RegisterUsingRegAsm, location:
C:\Users\naveed.butt\AppData\Local\Optimentor\Proofix\, command:
"regasm.exe"
"C:\Users\naveed.butt\AppData\Local\Optimentor\Proofix\Proofix.View.dll"
/codebase
First of all you are missing a PropertyRef
Like this:
<PropertyRef Id="NETFRAMEWORK40CLIENTINSTALLROOTDIR"/>
Second issue if you are on a 64 bit windows you should use the 64 bit variable:
NETFRAMEWORK40CLIENTINSTALLROOTDIR64
However you can handle 32/64 bit Windows OS with conditions. You can get inspiration from this answer: https://stackoverflow.com/a/12514596/600559
Recently I had to "pre-select" an feature inside an WiX product. If the target machine is an Terminal-Server, the Feature should be selected for install.
To check, if the machine realy is used as Terminal-Server or not isn't required, since the installing user can still deselect the feature later.
One way to check for Terminal-Server (and not just an machine with RDP enabled) is to use GetVersionEx-API to check the wSuiteMask.
How to check that in WiX?
First we had to link WixUtilExtension.dll (Project-References->Add Reference)
Then use INSTALLLEVEL (as per mrnx's advice) to switch between different Features. We default it to "2" (All below 2 will be selected in feature-selection-screen, all above 2 will be de-selected):
<!--Default Features: All with levl 1-->
<Property Id="INSTALLLEVEL" Value="2" />
Use feature-selection-UI-template (Maybe you have to reference WixUiExtension.dll)
<UI>
<UIRef Id="WixUI_FeatureTree" />
</UI>
Now reference the properties, which we want to know:
<!--Terminal-Server?-->
<PropertyRef Id="WIX_SUITE_TERMINAL" />
<!--On Terminal-Server this property will be null, if multiple RDP-sessions are allowed-->
<PropertyRef Id="WIX_SUITE_SINGLEUSERTS" />
And finally in our Feature-list we have to use the properties inside a condition. The Feature should be de-selected per default, so we set it to one Level higher than the default "2" --> "3".
<Feature Id="TerminalServerServiceFeature" Level="3"
Title="(Feature-Title, i.E.)Terminal-Server-Service"
AllowAdvertise='no'
InstallDefault='local'
Absent='allow'
Description="Some description for the user, when he clicks on the feature" Display="expand"
ConfigurableDirectory='APPLICATIONFOLDER'
>
<!--Reference to the component (or componentgroup) we want to install-->
<ComponentRef Id="TerminalServerServiceComponent" />
<!--This sets this feature to installlevel 1, if the condition evals to true-->
<Condition Level="1">(WIX_SUITE_TERMINAL="1") AND NOT (WIX_SUITE_SINGLEUSERTS)</Condition>
</Feature>
Testing:
To check, why the condition fails, you have to check the installer log (msiexec /i YourMsi.msi /l*v "log.log").
Something along the lines
MSI (c) (8C!98) [11:18:27:663]: PROPERTY CHANGE: Adding
WIX_SUITE_SINGLEUSERTS property. Its value is '1'.
for a machine with RDP but without multi-rdp-session-support and
MSI (c) (4C!E0) [11:26:15:422]: PROPERTY CHANGE: Adding
WIX_SUITE_TERMINAL property. Its value is '1'.
for a machine with RDP and multi-rdp-session-support.
I understand this is an often asked question, however after days of research I've not found an answer to this particular problem.
I have a new ASP.NET 5 (Core 1.0) MVC template that I'm trying to add a package to however each and every time I get in the Package Manager output:
Response status code does not indicate success: 407 (Proxy Authentication Required).
and the following at the top of solution explorer:
my settings look fine and I am able to browse packages in the 'Manage Packages for Solution' screen.
I understand I'm being requested to supply credentials so where do I enter them? On the other hand all other applications on my machine have validated internet access, so why should I?
Any ideas / pointers are very welcome.
Visual Studio 2015 - 14.0.24720.00 Update 1
NuGet Package Manager for Visual Studio 2015 - 3.3.0.167
Top section of Package Manager output:
Installing NuGet package AutoMapper.4.2.1.
Successfully installed 'AutoMapper 4.2.1' to CustomerPortal
========== Finished ==========
PATH=.\node_modules.bin;%PATH%;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\External;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\External\git
C:\Users\medmondson.dnx\runtimes\dnx-clr-win-x86.1.0.0-rc1-update1\bin\dnx.exe "C:\Users\medmondson.dnx\runtimes\dnx-clr-win-x86.1.0.0-rc1-update1\bin\lib\Microsoft.Dnx.Tooling\Microsoft.Dnx.Tooling.dll" restore "M:\visual studio 2015\Projects\CustomerPortal\src\CustomerPortal" -f "C:\Program Files (x86)\Microsoft Web Tools\DNU"
Microsoft .NET Development Utility Clr-x86-1.0.0-rc1-16231
GET https://www.nuget.org/api/v2/
GET http://packages.nuget.org/v1/FeedService.svc/
GET https://www.postsharp.net/nuget/packages/
Restoring packages for M:\visual studio 2015\Projects\CustomerPortal\src\CustomerPortal\project.json
GET https://www.nuget.org/api/v2/FindPackagesById()?id='AutoMapper'
GET http://packages.nuget.org/v1/FeedService.svc/FindPackagesById()?id='AutoMapper'
GET https://www.postsharp.net/nuget/packages/FindPackagesById()?id='AutoMapper'
Warning: FindPackagesById: AutoMapper
An error occurred while sending the request.
GET https://www.nuget.org/api/v2/FindPackagesById()?id='AutoMapper'
GET https://www.nuget.org/api/v2/FindPackagesById()?id='System.Collections.Immutable'
GET http://packages.nuget.org/v1/FeedService.svc/FindPackagesById()?id='System.Collections.Immutable'
GET https://www.postsharp.net/nuget/packages/FindPackagesById()?id='System.Collections.Immutable'
Warning: FindPackagesById: AutoMapper
An error occurred while sending the request.
GET https://www.postsharp.net/nuget/packages/FindPackagesById()?id='AutoMapper'
Warning: FindPackagesById: AutoMapper
Response status code does not indicate success: 407 (Proxy Authentication Required).
Update
I've managed to capture a non-working request (returning 407) and a working request with the only difference being the content of the Proxy-Authorization header which is longer. This would suggest the proxy authentication does exist but it's using a different protocol.
I had the same problem a few weeks ago. For me it has helped to put in the the following in the machine.config (Windows/Microsoft.NET/Framework64/v4.0.30319/Config)
<system.net>
<settings>
<ipv6 enabled="True"/>
</settings>
<defaultProxy useDefaultCredentials="True" enabled="True">
<proxy proxyaddress="http://your.proxyserver.ip:port"/>
</defaultProxy>
</system.net>
I had to modify the 32 bit machine.config (assumption being VS runs in 32 bit) to add the <system.net> section but omitting anything within the <defaultProxy> tag:
<system.net>
<defaultProxy useDefaultCredentials="True" enabled="True" />
</system.net>
According to MSDN:
If the defaultProxy element is empty, the proxy settings from Internet Explorer will be used.
This is perfect for me as every other application on my machine works - including IE.
manchine.config location (Win 7): %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
Note
I resolved this thanks to #user3063127 pointing me in the right direction (you have an upvote). As far as I can tell this only affects package restore on DNX projects and may well be fixed when RC2 is released.
Updated to latest nuget.exe 1st
nuget update self
Added proxy details to the config file:
nuget config -Set http_proxy=http://username:password#proxyserver.company.com:port
You need to modify file 2 .config files:
for Visual Studio 2015
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\vsn.exe.config
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe.config
for Visual Studio 2017
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\vsn.exe.config
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.exe.config
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy usesystemdefault="True" bypassonlocal="True" proxyaddress="http://yourproxy:proxyport" />
<bypasslist>
<add address="(.*\.)?anyotherdomain\.com?(.*)" />
<add address="(.*\.)?nuget\.org?(.*)" />
<add address="192\.168\.\d{1,3}\.\d{1,3}" />
</bypasslist>
</defaultProxy>
<settings>
<ipv6 enabled="false"/>
<servicePointManager expect100Continue="false"/>
</settings>
</system.net>
The bypass for nuget.org will work if, without the proxy, you still can get it's IP from DNS server and nothing else is blocking it.
Also need this to install nuget
Open the file C:\Users\[YOUR_USER_NAME]\AppData\Roaming\NuGet\NuGet.Config and add inside the <configuration> <\configuration> tag the following:
<config>
<add key="http_proxy" value="http://yourproxy:proxyport" />
</config>
Taken from Marco Mengoli's Blog
If you have Fiddler installed, tick the option 'Automatically Authenticate' under the Rules option, should fix the above issue.
Selecting the Automatically Authenticate
Got this from the following post
Configuring Fiddler to use company network's proxy?
If you don't know the proxy server details, you can go with other workaround to overcome this error "407 (Proxy Authorisation Required.)"
Workaround:
1. Download/Install Fiddler
2. Click Menu Rules -> Automatically Authenticate
Without closing Fiddler, now try to do restore package in Visual Studio. It should now restore the packages without any proxy error.
This is not a neat solution, but still an alternate workaround to resolve this issue. This solution tries to utilise Fiddler as Proxy.
Maybe you have wrong proxy credentials in Credential Manager. Try to remove it.
Control Panel -> User Account -> Credential Manager.
Remove proxy credentials resolved my problem.
Adding proxy username, password fixed my 407 authentication issue.
Place the following snippet in NuGet.config file located at C:\Users\myUserName\AppData\Roaming
<configuration>
<config>
<add key="http_proxy" value="http://my.proxy.address:port" />
<add key="http_proxy.user" value="mydomain\myUserName" />
<add key="http_proxy.password" value="[base64 encoded Password]" />
</config>
</configuration>
Ref: https://forums.asp.net/t/2096179.aspx?Proxy+407+Access+Denied
Using Wix installer (win 8), I have a custom action that runs the application after successful installation, using Wix:
<CustomAction Id='LaunchFile'
Directory='TARGETDIR'
Impersonate="no"
Execute="immediate"
ExeCommand='[SystemFolder]cmd.exe start CMD /c ""[TARGETDIR]ManagerAndControl.exe""'
Return="asyncNoWait" />
This works great, but for some reason, the CMD window remains open, and when the application is closed it is closed too.
I couldn't find anything similar in google, anyone encounterd a similar problem?
Thank you
EDIT:
I'm trying, as #Rolo suggested, the QtExecCmdLine:
<Property Id="QtExecCmdLine" Value='C:\Users\User\Desktop\tests.exe'/>
<CustomAction Id="QtExecExample" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="immediate" Return="check"/>
And also:
<Publish Event='DoAction' Value='QtExecExample'>(NOT Installed) AND (LAUNCHPRODUCT = 1)
</Publish>
But nothing happens, and the log says:
Action start 11:02:49: QtExecExample.
MSI (c) (E0:20) [11:02:49:911]: Invoking remote custom action. DLL: C:\Users\User\AppData\Local\Temp\MSIAD42.tmp, Entrypoint: CAQuietExec
MSI (c) (E0:EC) [11:02:49:913]: Cloaking enabled.
MSI (c) (E0:EC) [11:02:49:913]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (E0:EC) [11:02:49:913]: Connected to service for CA interface.
MSI (c) (E0!00) [11:02:49:944]: PROPERTY CHANGE: Deleting QtExecCmdLine property. Its current value is 'C:\Users\User\Desktop\tests.exe'.
Action ended 11:02:49: QtExecExample. Return value 3.
DEBUG: Error 2896: Executing action QtExecExample failed.
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: QtExecExample, ,
Action ended 11:02:49: FinishedForm. Return value 3.
Action ended 11:02:49: INSTALL. Return value 1.
Filling lost here
Use the "Quiet Execution Custom Action" instead.
http://wixtoolset.org/documentation/manual/v3/customactions/qtexec.html
Update:
I'll have to update my answer. You should use the WixShellExec custom action. It works pretty similar to Quiet Execution CA, but it will allow you to launch the app without waiting for it to close.
However it can only be used as an immediate custom action.
There is a full example of the implementation you need here:
http://wixtoolset.org/documentation/manual/v3/howtos/ui_and_localization/run_program_after_install.html
http://wixtoolset.org/documentation/manual/v3/customactions/shellexec.html
Edit your execommand like this
> ExeCommand='[SystemFolder]cmd.exe start CMD /c ""[TARGETDIR]ManagerAndControl.exe"" & exit'
EDIT
> ExeCommand='"[TARGETDIR]ManagerAndControl.exe"'
I've just tried this for me and it's worked after I recreated your original problem. However, where you have [TARGETDIR] I use [INSTALLDIR] - I assumed that this was referencing your install directory. You need to be aware of your use of inverted commas.
Thanks for your help, finally I solved it:
<Property Id="WixShellExecTarget" Value='[TARGETDIR]ManagerAndControl.exe' />
<CustomAction Id="LaunchApplication" BinaryKey="WixCA" DllEntry="WixShellExec" Impersonate="yes" />
<!-- UI code here -->
<Publish Event='DoAction' Value='LaunchApplication'>(NOT Installed) AND (LAUNCHPRODUCT = 1)</Publish>
Wix 3.6. I'm trying to run a bundle :
<Bundle Name="Setup" Version="1.0.0.0" Manufacturer="Bentley" UpgradeCode="37d68094-0b98-4b16-bfbe-7f0d3015064a">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<MsiPackage SourceFile="path/to/MyMsiFileWhichIsFine.msi" Cache="yes" Compressed="no" InstallCondition="1"/>
</Chain>
Result from execution :
0x800b0109 A certification chain processed, but terminated in a root certificate which is not trusted by the trust provider.
The log file says :
Detected partially cached package: MyMsiFileWhichIsFine.msi, invalid payload: MyMsiFileWhichIsFine.msi, reason: 0x80070570
I signed this msi. The bootstrapper was also signed using (cf this link):
insignia -ib Setup.exe -o engine.exe
signtool engine.exe (extra parameters excluded for simplicity)
insignia -ab engine.exe Setup.exe -o Setup.exe
signtool Setup.exe
One possibility is the msi was created externally rather than using Heat.exe that comes as part of WIX. I've had similar issues when I was trying to work with VB6 files, and had to add in flags to ignore those checks. But in your case, Bootstrapper might not be able to interpret the msi correctly. How did the msi get created? Did you use Heat? Can you post the Heat lines if so?
I found a solution ! I just skip the signing verification like this :
<ExePackage SourceFile="MyPath\MyFileToLaunch.exe" Compressed="no" SuppressSignatureVerification="yes"/>