I have WIX installers for two windows services. Both are installed using the same credentials, but one works while the other fails with the error "Service "PCP Event Processor-3.9.9.0-wix' (MyServiceExeName) could not be installed. Verify that you have sufficient privileges to install system services.". I use a common wxi file for both projects with the credentials to use, so it's not an account name or domain name typo AFAICS. The only substantial differences between the two services being installed are:
The failing project has a .licx file for the 3rd party component.
the failing project is a WinExe project. The successful install is an Exe (Console style app)
As far as I can see, there is no real difference (obviously GUIDs are different) between the wxs files for the two installers. The failing component has WIX installer code like this:
<Component Id="cmpMainExe" Guid="{EXCISED-FOR-CUT-N-PASTERS}">
<File Id="filASJHDJSDJSHGDJH" Source="$(var.EventPollingService.TargetDir)\EventPollingService.exe" />
<ServiceInstall Name="$(var.SVCNAME)-$(var.ProductVersion)-$(var.BranchName)"
DisplayName="PCP $(var.SVCNAME)-$(var.ProductVersion)-$(var.BranchName)"
Type="ownProcess"
Interactive="no"
Start="auto"
Vital="yes"
ErrorControl="normal"
Description="Manages the state model of a user's session by handling incoming events from the dialler"
Account="$(var.ServiceAccountId)"
Password="$(var.ServiceAccountPwd)" />
<ServiceControl Id="StartWixServiceInstaller"
Name="$(var.SVCNAME)-$(var.ProductVersion)-$(var.BranchName)"
Start="install"
Wait="yes" />
<ServiceControl Id="StopWixServiceInstaller"
Name="$(var.SVCNAME)-$(var.ProductVersion)-$(var.BranchName)"
Stop="both" Wait="yes"
Remove="uninstall" />
</Component>
I'm using Wix 3.5 with Votive in VS 2010, and both projects are .NET 3.5 SP1 apps. I'm using Windows 7, with UAC turned off.
Any ideas?
Look at the two build MSI's in ORCA from Windows SDK and verify the ServiceInstall table entries look the same.
However, in my experience, this is not likely to be an installer issue. This is usually a red herring that points to an application problem such as missing dependencies or application exception. After you rule out the ServiceInstall entries and verify that the service account credentials are correct, the account is not disabled and the account has the authority to logon as a service then start profiling your application. This is easiest to do right when the installer is hung at the error window.
Two last thoughts:
If a program has dependencies on the winsxs or GAC it won't work as these don't get installed until Commit execution which is after trying to start the service
If you need to grant the user LogonAsService rights look at the User element in WiX.
Related
So I'm building an MVC6 app in Visual Studio 2015 and have managed to figure most stuff out, however, I haven't yet worked out deployment.
In MVC4 (what I was using before), our process* was publish to a folder, then setup the website in IIS (Right-Click on Sites -> Add Website).
Actually, our process is set it up in IIS and TeamCity, but not for test apps like this :).
I followed this process and obviously it's trivial to setup the IIS website and publish to the correct folder...but that does not actually work for me.
We're running IIS 8 on Windows Server 2012 and we've installed the .Net 4.6 runtime on the server.
The following steps have worked for me and should help you host your project on IIS.
Using Visual Studio 2015 Preview as your IDE,
Create an ASP .NET 5 Starter App.
Check that it is working outside of IIS.
Once complete, publish the application. In this example, I have selected the location C:\PublishWebApp.
3.1. When publishing your application, make sure that you have:
Disabled precompilation
Selected amd64
(See image below)
Upon a successful publish, go to C:\PublishWebApp.You should see the folders approot and wwwroot inside.
Now open the IIS Manager (I am assuming you have the ASP .NET 4.5 feature enabled)
Create a new website.
6.1 : Select the wwwrooot folder as the website's physical path. In this example, it is C:\PublishWebApp\wwwroot.
Check the website to see that it is working. If you encounter any errors, please post them here.
If the precompile option is ticked in the Publish Web Settings window pictured above, then you must
Go to the wwwroot folder of your published web application. In this example, it is C:\PublishWebApp\wwwroot.
Locate web.config.
Inside the folder of your published application, there is an packages folder inside of the approot folder which should contain a folder named after your application, with a folder for the version underneath. Inside that folder should be a folder named root. In web.config, set the value for the key kre-app-base to the root folder. For reference, see the line of code below. In this example, the application name is WebApplication10.
<add key="kre-app-base" value="..\approot\packages\WebApplication10\1.0.0\root" />
I Spent hours on debugging the issue finally got it worked, steps:
1) Publish your MVC6 application using visual studio into file system, make sure you are selecting correct DNX Target version in my case its dnx-clr-win-x64.1.0.0-rc1-update1.
In the output folder map "wwwroot" folder to your applicaiton in IIS (DO NOT Map it to sup-applicaiton, only ROOT application in IIS works with DNX for example "Default Web Site").
I have just spent a day trying to get this working. i found this here (search for posts by GuardRex) invaluable, complete the steps the accepted answer gave, that's the start of it.
Pretty much if you try to add an application to a site there is bunch of workarounds and extra configuration needed that is detailed in the link.
For starters:
1)Make sure you have the HttpPlatform handler installed here
2)Seems obvious but make sure .net5 is installed on your server here
I know this is if you are adding an application to a site, but there's some pitfalls and much needed refinements needed for the deployment process at the moment that everyone should be aware of.
I have a strange problem when trying to get the application pools on the current machine. It seems that when IISExpress is installed, the Microsoft code wants to check IISExpress in addition to the full IIS. IISExpress uses separate applicationHost files per user. I'm not sure whether this call will require it to check all of those, or just those for the current user. Regardless, it's not finding the one it's looking for in the 'C:\Windows\system32\config\systemprofile\' directory. It should be going to %userprofile% or 'C:\Users\Administrator\' for the user that the application pool that this code is executing under is running as.
Does anyone perhaps know how this systemprofile directory might be coming from?
Exception:-
System.IO.DirectoryNotFoundException: Filename: \\?\C:\Windows\system32\config\systemprofile\Documents\IISExpress\config\applicationHost.config
Error: Cannot read configuration file
at Microsoft.Web.Administration.Interop.AppHostWritableAdminManager.GetAdminSection(String bstrSectionName, String bstrSectionPath)
at Microsoft.Web.Administration.Configuration.GetSectionInternal(ConfigurationSection section, String sectionPath, String locationPath)
at Microsoft.Web.Administration.ServerManager.get_ApplicationPoolsSection()
at Microsoft.Web.Administration.ServerManager.get_ApplicationPools()
at CustomCode.Classes.IIsApplicationPool.GetApplicationPool(String iisWebSitePath, String poolName)
I highly recommend to stop using the local reference to Microsoft.Web.Administration that gets shipped with IIS (even if it's in the GAC). This is because it has a very specific version number (i.e. 7.0.0.0) and this version might change in a future version of Windows and it will hurt.
Instead, checkout the nuget package: Microsoft.Web.Administration (https://www.nuget.org/packages/Microsoft.Web.Administration). This basically makes it so you can have a private deployment of your IIS dependencies.
If the application, in which you are using Microsoft.Web.Administration to check for app-pools, is running on IISExpress, it will always fallback to Microsoft.Web.Administration version 7.9.0.0 due to an assemblyredirect in the aspnet.config in the IIS express.
See C:\Program Files (x86)\IIS Express\config\templates\PersonalWebServer\aspnet.config
Here is the problem in the config:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Web.Administration"
publicKeyToken="31bf3856ad364e35"
culture="neutral" />
<bindingRedirect oldVersion="7.0.0.0"
newVersion="7.9.0.0" />
<codeBase version="7.9.0.0"
href="FILE://%FalconBin%/Microsoft.Web.Administration.dll" />
</dependentAssembly>
Make sure you are running the application in either the full IIS or on the Visual Studio Development Server.
Alternativly you could try and remove the assembly redirect, but i have not tried this, and this might cause problems in other places. We must assume that the IIS Express team made the redirect for some reason (other than convenience) :-)
I already know the answer is old but
have you tried specifying a different version of the dll?
A picture is worth in thousand words:
How are you trying to get the application pools? Are you using MWH (Microsoft.Web.Administration) APIs?
Full IIS ships with Microsoft.Web.Administration.dll (version 7.0.0.0).
IIS Express ships with a different version of Microsoft.Web.Administration.dll (version 7.9.0.0).
It seems full IIS is trying to use IIS Express specific assembly. I am not sure how you ended up in this state, but you can un-install IIS Express and see if this problem still occurs.
Edit:
Why do you want to use Microsoft.Web.Administration (MWA) version 7.9.0.0 in your web application? It is shipped with IIS Express 7.5 to work with per user applicationhost.config file ONLY and this does not use/work with inbox/full IIS configuration file that is located at \windows\system32\inetsrv\config\appliationhost.config.
In your case, web application running under full IIS is running with system identity and therefore MWA 7.9.0.0 is trying to load config file from 'C:\Windows\system32\config\systemprofile' directory.
I've just recently ran into this issue. After reading quite a few posts, this was the closest one at giving me any idea as to what was going on. While I don't necessarily have a solution to the conflict between the two versions (7.0.0.0 and 7.9.0.0) when running within the VS IDE, after a few hours struggling with it, I did find a of quirky trick you can do to work around the IDE's auto-redirection.
In the example of:
Developing an application that's referencing Microsoft.Web.Administration.dll (7.0.0.0) from the inetsrv directory and attempting to do any of the following and trying to connect properly access the application pool definitions of the real IIS, not IIS Express, with not installed. When running the compiled code outside the IDE, it always works correctly regardless of how it's specified.
ServerManager sm = new ServerManager();
sm.OpenRemote("localhost");
sm.OpenRemote("MYPC"); // Presuming you local machine's name is MYPC
These all trigger VS to redirect the reference from the 7.0.0.0 DLL to the 7.9.0.0, which causes the retrieval of incorrect sites or COM exceptions to occurs.
The quirk I found was to always use the OpenRemote(), even though trying to open the local IIS and specify "localhost" or "MYPC" as either "LocalHost" or "MyPc" (i.e. any combination of mixed case so that it is not an exact case-sensitive match to "localhost" (all lower case) or the local machine name.
This quirk may not be specific to all VS versions. I'm currently using VS Professional 2017 (15.9.11).
As I stated, it does fix the redirect, but it definitely help while debugging.
I found mapping the "TeamConfig folder" locally to my development machine helped resolved this issue for me.
I have a 3rd party web page screen capture DLL from http://websitesscreenshot.com/ that lets me target a URL and save the page to a image file. I've moved this code into my Azure-based project and when I run it on my local sandboxed dev box and save to the Azure blob, everything is fine. But when I push the bits to my live server on Azure, it's failing.
I think this is because either MSHTML.dll and/or SHDOCVW.dll are missing from my Azure configuration.
How can I get these libraries (plus any dependent binaries) up to Azure?
I found the following advice on an MSFT forum but haven't tried it yet. http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/0344dcff-6fdd-4479-a3b4-3e89750a92f4/
Hello, I haven't tried mshtml in the cloud. But generally speaking, to
use a native dll in a Web Role, you add the dll to the Web Role
project just like adding a picture (choose add existing items). Then
make sure the Build Action is set to Content. This tells Visual Studio
to copy the dll file to the output package.
Also check dependencies carefully. A lot of problems related to native
code are caused by missing dependencies, such as a particular VC++
runtime dll.
Thought I'd ask here first before I burn a day or two on an unproven solution.
EDIT #1:
it turns out that our problem was not related to MSHTML.dll or SHDOCVW.dll missing from the Azure server. They're there.
The issue is that by default new server instance have the IE security hardening feature enabled, and this was preventing our 3rd party dll from executing script. So we needed to turn off the enhanced IE security configuration settings. This is also a non-trivial exercise.
In the meantime, we just created a server-side version of the feature on our site we need to make screen captures from (e.g. we eliminated JSON-based rendering of UI on the client), and we were able to proceed.
I think the solution mentioned in the MSDN forum thread is correct. You should put them as part of your project files, so that the SDK will package and deploy them to the VM on the cloud.
But if they are COM and need to be registed you'd better call the register command via the Startup feature. Please check http://msdn.microsoft.com/en-us/hh351539
HTH
Environment: TeamCity 6.5.1 on Win2k3, BuildAgent(s) on Win2k3, Visual Studio 2k10, .NET v4, Nant 0.91
I'm completing the setup of TeamCity and am trying to lock down the BuildAgent account on the build machine(s) per our security guidelines. The build is crashing the first time "devenv.exe /build" is called via the Nant script:
Faulting application devenv.exe, version 10.0.30319.1, stamp 4ba1fab3,
faulting module msenv.dll, version 10.0.30319.1, stamp 4ba1fd94,
debug? 0, fault address 0x0000c36b.
I had no luck googling that message. However, if I change the BuildAgent Service from the Local Network Account to the Administrator account, things work. However, if I use another domain account, it fails. Also fails if I add that domain account to the local Administrators group.
Any ideas on what I'm missing? Is there a specific privilege you need to have in order for a "DevEnv /build" to work without crashing?
Yuck, I just went through this recently. First, use devenv.com, not devenv.exe. The devenv with the com extension can build a solution and send all output to the console, without using the gui. As the TeamCity agent is a service, it may not be allowed to interact with the gui at all.
Second, and I realize that this might not be possible for you (especially if you are building an MSI), but consider doing whatever you need to do to use the built in Visual Studio build runner that comes with TeamCity. It does utilize MSBuild to do its work. If you go this route and you still need devenv, then go find MSBuild Extensions Pack, which has already solved a lot of these issues with their own devenv build task.
Honestly, I ended up replacing Microsoft's installation projects with alternatives (InstallShield or WiX), and never looked back.
I notice that there's frequently an aspnet_client folder under the standard IIS web folder structure. What is this used for? Is it needed?
In the .NET 1.1 days and before, this folder provided ASP.NET with its JavaScript support for the validation controls and other functionality. If you don't have a .NET 1.1 site or older running it should be safe to delete it. I would rename it first to ensure it doesn't cause any problems.
In addition to what others have said, it's usually created by the aspnet_regiis tool, which can be (re-)run by things like Windows Update/AddRemove Windows components/IIS. So sometimes even if you do delete it, it can come back randomly. There may be a way to stop this behavior, but I haven't found it (maybe changing the application version to .NET 2 would do it actually).
So unless you're using certain features of .NET 1.0/1.1 (validation, Smart Navigation etc) you can delete it without any problems, just don't be too surprised if it comes back!
aspnet_client is a folder for "resources which must be served via HTTP, but are installed on a per-server basis, rather than a per-application basis".
Some of the uses of aspnet_client include storing resources (eg. JavaScript, images) for:
JavaScript for ASP.NET Web Forms controls when using client-side validation (mainly to manhandle older browsers like IE5, it seems)
ASP.NET 2.0 (until at framework 4.0) for 'Global Themes' (global to all sites on a server, that is)
some versions of Crystal Reports
There probably are/will-be further (ab)uses of this folder in the future. Needless to say, since it contains things which are "necessary for the application to run correctly" but which "are not supposed to be deployed by the application", it will remain something of a nightmare for both developers and system administrators.
It seems that the 'prototype' for the contents of the folder is in C:\inetpub\wwwroot, and it seems reasonable to suppose that if any given IIS website lacks a /aspnet_client resource, then IIS will try to do the right thing and ... as a last resort ... make a physical folder in the web site root folder, and copy the files there. It seems that IIS will do this at least when "ASPNET_regiis /c" is invoked a given server - which probably occurs automatically at some critical junctures ... like when .NET framework updates are applied to a server which has the IIS role.
Strategies for handling the aspnet_client directory include:
specifying a virtual directory mapped to C:\inetpub\wwwroot in the hope that IIS will forgo creating a physical directory
deleting the physical directory from time to time if you're sure your site doesn't need it and it really bothers you
ignoring aspnet_client
running "ASPNET_regiis /c" yourself if you're missing the folder, and need it
Probably most importantly, as a developer, you should clearly understand and document your applications' dependencies on the aspnet_client directory, and make sure that your installation procedure has relevant instructions for making sure that the directory exists. However, you should probably not bother to actually supply the directory as part of your packaged web application or web site - how could you possibly do this for each version of the .NET framework which the server will see over the lifetime of your application?!
Some links I will come back to later:
http://my.safaribooksonline.com/book/certification/mcts/9780735657489/2dot-using-master-pages-themes-and-caching/ch02s03_html?query=((aspnet_client))&reader=html&imagepage=#snippet
What is the aspnet_client folder in my ASP.NET website?
iis express path for global theme directory
http://my.safaribooksonline.com/book/web-development/microsoft-aspdotnet/0735621772/aspdotnet-configuration/111?query=((aspnet_client))#X2ludGVybmFsX0J2ZGVwRmxhc2hSZWFkZXI/eG1saWQ9MDczNTYyMTc3Mi8xMTE=
http://my.safaribooksonline.com/book/web-development/microsoft-aspdotnet/9780471785989/working-with-themes/ch41lev1sec8?query=((aspnet_client))&reader=html&imagepage=#X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTk3ODA0NzE3ODU5ODklMkZjaDQxbGV2MnNlYzEwJnF1ZXJ5PSgoYXNwbmV0X2NsaWVudCkp
http://my.safaribooksonline.com/book/web-development/microsoft-aspdotnet/067232542x/performing-form-validation-with-validation-controls/ch03lev1sec1?query=((aspnet_client))&reader=html&imagepage=#snippet
http://scn.sap.com/thread/3157366
It also has certain icons and scripts that are required for crystal reports to run properly even in versions later than 1.1
The folder is usually for storing client side Javascript, which ASP.NET uses for things like validation.
It should be safe to delete.
Figured I'd add this here as this is the link I kept being directed to when I googled this question. Apparently with .NET 4.0 and newer this folder is no longer needed and can be removed without issue.
If you are using Installshield to configure ASP.net website, be aware that this feature was present in Installshield 2010 and is missing in Installshield 2012.