I have a problem with hosting an ASP.NET RC1 application inside IIS.
I've read through similar issues here on the site, aswell as went through official Microsoft documentation, but to no avail. I simply cannot make the app start inside IIS8 which is a must in this scenario, as I need to use it with an SSL certificate, and no relevant logs are shown unfortunately.
App is packaged under dnx-clr-win-x86.1.0.0-rc1-update2
If I try to start it inside my local VS2015, it works flawlessly. If i run the Web.cmd on the server machine from command line, app starts without any problems. However, when I try to run it through IIS, event log catches the following.
Faulting application name: dnx.exe, version: 1.0.0.20309, time stamp: 0x56e05cbb
Faulting module name: ntdll.dll, version: 6.2.9200.21815, time stamp: 0x56eaff87
Exception code: 0xc0000374
Fault offset: 0x000db583
Faulting process id: 0xae4
Faulting application start time: 0x01d1aba4b38c38e7
Faulting application path: C:\inetpub\wwwroot\approot\runtimes\dnx-clr-win-x86.1.0.0-rc1-update2\bin\dnx.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: f1f534cd-1797-11e6-9404-000d3ab185aa
Faulting package full name:
Faulting package-relative application ID:
It seems to me like it is using a wrong dnx version, but this shouldn't be possible as i published the app with:
dnu publish --runtime active --no-source
First of all thanks Clint for pushing me in the right direction.
Unfortunately I ended up spinning up a new Windows Server 2012 instance, and installing everything from the grounds up, which seems to work great at this moment. I have probably messed something when initially setting up the server, but it was a test one so no harm is done. I have a few observations for DNX to IIS publishing, which could help others with similar problems or at least mitigate at least some of the problems.
Very important steps:
If publishing from command line, publish with dnu publish --runtime active. Add --no-source when you are sure you don't need to make any quick changes to make the app work so it compiles into NuGet packages.
Try to run the app manually by running web.cmd from the publishing folder from command line. If this doesn't work, IIS is least of your problems, and you need to resolve the app startup first.
Install IIS locally on your development machine, and try to make it first work with that one, which will help you understand which issues are happening to you and how to resolve them on the real web server.
Use Event Viewer -> Windows Logs -> Application to catch .NET and HttpPlatformHandler errors during startup
Enable stdout inside wwwroot/web.config for your solution.
Battling different issues:
1. Various http 4xx and 5xx errors.
Ensure that Http Handler 1.2 is installed. If you are not sure, check the add / remove programs section in control panel, where version is clearly visible. If using a x64 system, you need to install x64 runtime
Check that you have unlocked handlers in IIS
Check that Application pool is set to No Managed code (32 bit app support was not required in my case)
2. I'm not sure I published to a good folder
Create a folder for your web app inside your wwwroot folder e.g. C:\inetpub\wwwroot\myApplicationName
Copy publishing files to that folder. Structure should be as follows:
C:\inetpub\wwwroot\myApplicationName
approot
logs
wwwroot
Create a new website in IIS and attach it to your application pool that is set to no managed code
Set the application folder to be C:\inetpub\wwwroot\myApplicationName\wwwroot
3. Event Viewer - DNX Could not write to logs folder
This is an issue with IIS permissions on the logs folder from your publishing artefacts. Right click -> Properties -> Security on the logs folder and Add permissions for the following user.
IIS_IUSRS (permissions: read and execute, list, write)
Once you do this, restart the website, and check if this issue is gone. If Event Viewer is not logging anything, check if there is a file generated in the logs folder where you should get the next troubleshooting hint.
NOTE: If you publish an app update, and you overwrite the logs folder accidentally, you will kill its permissions and this issue will return. After the initial publish, just copy approot and wwwroot, and leave the logs intact to avoid this.
4. Unable to load application or execute command 'Microsoft.AspNet.Server.Kestrel'. Available commands: web
Try to run a dnu restore before publishing manually
Ensure that you have published with --runtime active
First make sure you have httpPlatformHandler v1.2 installed. Then follow the steps and issue resolutions here. If it still is not working, I've heard some people have resolved their issues by adding a Configure1() method in Startup.cs. See the details here.
I got one of my projects working with IIS but it was a struggle. So I decided to wait until the next release. I personally don't think it's worth bothering with right now. Because it relies on dnx which is being replaced in the next release. So whatever you do to get it working, probably won't be relevant after the next release.
Related
I have my web app completed and want to publish it. Let me say upfront that it is entirely probable that I am doing something wrong or have made incorrect choices in my publish profile. This is my very first app!
It runs fine with no errors within Visual Studio. It does have a couple of warnings about nulls - would that keep it from publishing? I have eliminated all of them but a couple (which I am not sure how to get rid of at this point - Dereference of a possibly null reference) and as it is a historical info 'view only' app, with no data being able to be modified, is that really an issue?
When I publish, I am publishing to a network folder. The publish succeds, but when I click the application file in the folder, it opens a command prompt window and runs a few lines of code and then stops. No browser opens. I never view the app itself.
Here is what was in the command prompt window:
info: Microsoft.Hosting.Lifetime[14]
Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[14]
Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
Content root path: S:\Visual Studio Projects\Healthy Shots\
My Publishing profile choices are:
Configuration: Release
Target Framework: net6.0
Deployment Method: Self-contained
Target Runtime: win-x86
File Publish Options:
Produce single file
Delete all existing files prior to publish
Databases:
Default Connection with 'Use this connection string at runtime' checked. Below that shows the connection string that is in my app.
Entity Framework Migrations (nothing here)
Any assistance would be much appreciated. Thank you! Please let me know if you require additional information.
According to the output, the application has launched successfully and is running. If you want to see it in a browser, you need to launch that yourself and navigate to https://localhost:5001. Web apps do not launch browsers themselves. It would make no sense for them to do so as they typically execute on a web server which might not even have a browser installed on it. Your IDE might launch a browser when you press F5 or Ctrl+F5 to run the app locally, but that is not the same thing.
I have an ASP.Net application who's code is sitting in an Azure Repo. The project has a build pipeline that builds on master branch merges. I then have a Deployment pipeline that takes the latest build and deploys local on my web server through a deployment pool I have running on my server. The web application builds with the VS Build task and deploys with the IIS Web App Deploy task. Both work fine.
I have one VM in with Visual Studio that I am trying to use to remote debug the web server. I have VS Remote Tools on the web server and it successfully runs. On my VM, I am able to open VS, attach debugger to a remote process on the web server successfully. The problem is that the symbols are not loading and I'm not sure what the correct sequence of items is here.
First, it doesn't appear that there are any .pdb files in the build produced by the Azure Pipeline. Second, I'm not sure what is the proper way to get the code onto the VM for debugging (Clone repo, vs download zip, etc). Third, I attempted to add a Publish Smybols task to my deploy pipeline, however its generating .pdb folders not files, and I'm not sure where to place these either on the web server, or on the vm.
My background is in classic local TFS setups, so working, building and deploying from Azure DevOps has me confused on how to get remote debugging to work.
OK this is not for the faint-hearted. It has taken me 3hrs to slowly work through this - but it's worth it. Many times has something worked locally, but then when you trigger an Build Agent with CI on a remote server you can't Step through the code with breakpoints.
So this info is if you are using the above situation - Azure build agent and Continuous Integration. If you are using a Publish Profile this doesn't apply.
First things first... The most important parts of this answer can be found in this blog:
https://willys-cave.ghost.io/i-have-a-dream-of-a-single-build-consistent-x-and-simple/
I've added that Url to the wayback machine at archive.org in case it disappears.
So yes the problem is the .PDB files - they need to be included by adding Publish symbols task. in your VSO pipeline.
Note: I had to change the BuildConfiguration parameter to debug (different from Willy's instructions). Otherwise when you eventually start to hit breakpoints the code is optimized and you won't see variable values in the hover-over etc.
In VS 2019 Willy's instruction for Link to the symbols during remote debugging sessions needs reading carefully. I didn't. There is a better image on:
https://devblogs.microsoft.com/devops/vsts-is-now-a-symbol-server/
I include the screen capture here:
Importantly you need to add your VSTS hostname into the list of Symbol Servers
Now mine still wasn't hitting the breakpoints and I found this page (which is generally about using the slightly different method of Publish Profiles), but I noticed some more components were loaded into IIS... Yes! You may need these too.
https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging-azure?view=vs-2019
So the most important image I will paste here:
You need to add IIS Management Scripts and Tools to your IIS installation.
That should do it. Also I run my remote debugger as Administrator, attach it to the w3wp.exe (show All Users Processes) and if it doesn't appear - reload the remote page and Refresh as if the pool goes to sleep you won't see it in the list
Good luck!
I have an ASP.NET 4.6.1 application that I am trying to deploy to a remote web server using TeamCity and MSBuild. Below is the MSBuild build step within TeamCity.
When I run the build in TeamCity, it always fails on this build step with a FILE_IN_USE_ERROR. The DLLs that are being updated before the error are usually the same, but sometimes they are different.
[MSBuild output] Info: Updating file (MyApp\bin\roslyn\Microsoft.VisualBasic.Core.targets).
[10:35:23]
[MSBuild output] Info: Updating file (MyApp\bin\roslyn\System.AppContext.dll).
[10:35:23]
[MSBuild output] Info: Updating file (MyApp\bin\roslyn\System.Collections.Immutable.dll).
[10:35:23]
[MSBuild output] MSDEPLOY : error Code: ERROR_FILE_IN_USE [C:\BuildAgent\work\b89cd3dfa447b\MyApp\MyApp.csproj]
I've already read through many articles (here, here, here, and here) suggesting that I drop an app_offline.htm file before deploying so that the IIS can re-route traffic and the file locking issues will stop. I tried that and it doesn't work. I still get the file in use issues during this build step.
I've also read in plenty of other discussions that another solution is to stop the application pool, deploy the app updates, and start the application pool. This is not a realistic solution because the deployment usually lasts between 15 and 20 minutes. Plus, this doesn't allow me to show a nice message to any current users.
I've been reading about this for a while now and it seems like this is a common use case for deployment to an IIS web server. Shouldn't this just work without locking files? Does anybody know of any other solutions to this problem?
I would try by stopping app pool to see if that`s a root cause of the issue.
But I'm not sure why it fails on .csproj file, because usually you don`t deploy those on server. So either it fails on different file (that is actually in use by web application) or it fails during build, not deploy (than app-pool stop will have no affect).
I have a website that has been hosted on a test site and I am now releasing it to a public facing demo site on IIS7. I first copied the website up to the Demo machine, created a seperate site and pointed it to my copied files. I logged into the site and performed a quick run through of the main functionality, all worked well. The config file is exactly the same as the existing Demo config except a few additional Application settings.
I then pointed the Demo site to my new Website folder. The old website folder was located at C:\inetpub\wwwroot\DemoSite\10.5
The new one is at
C:\inetpub\wwwroot\DemoSite\10.7
When I browse to the login page it appears. When I try to log in it hangs and eventually gives me a page cannot be found error. I checked the event logs and there are the following errors
Application: w3wp.exe
Framework Version: v4.0.30319
Description: The process was terminated due to stack overflow.
Faulting application w3wp.exe, version 7.0.6002.18005, time stamp 0x49e023cf,
faulting module clr.dll, version 4.0.30319.269, time stamp 0x4ee9ae83, exception code
0xc00000fd, fault offset 0x00012f71, process id 0x%9, application start time 0x%10.
This must be something to do with IIS as I can log in with the same code in the same folder but with a different IIS site
Any ideas?
After going through all the IIS settings I noticed the Application pools had a different value for "Enable 32bit applications". I changed the setting on the Demo from YES to NO and it worked. My guess is that this was built on a 32 bit machine before, and now it is being built on an x64 processor.
I’m trying to use a (VS 2008) Web Deployment project in a TFS solution to deploy the web site to the (TFS 2008) build server to run web based unit tests.
For some reason, that I can't yet figure out, it is failing to create the virtual directory:
Using "CreateVirtualDirectory" task from assembly "C:\Program Files\MSBuild\Microsoft\WebDeployment\v9.0\Microsoft.WebDeployment.Tasks.dll".
Task "CreateVirtualDirectory"
Initializing IIS Web Server...
C:\Program Files\MSBuild\Microsoft\WebDeployment\v9.0\Microsoft.WebDeployment.targets(667,5): error : Access is denied.
C:\Program Files\MSBuild\Microsoft\WebDeployment\v9.0\Microsoft.WebDeployment.targets(667,5): error :
Failed to create virtual directory 'abc'.
Done executing task "CreateVirtualDirectory" -- FAILED.
The TFSService user certainly is in the Administrators group on the TFS Build machine (which is running Windows Server 2008). I don’t know what else could be wrong. I’ve checked the event log an there’s no clues there. I am able to manually create the virtual directory on that machine through the IIS console with no problem.
Any ideas what could be the problem or suggestions for how to diagnose this further?
it has got to be permissions...did you try putting the TFSService in the same Groups you are in?
Is the TFS account running under the same privileges as the account that you use to connect to IIS? Do as Craig suggested and move the TFS account into the groups that you participate in.
You're sure that the build is running under the TFSService id and not under another id set up just for builds, and which may not be in the administrator's group? I haven't done more than just play with automated builds since I do mostly solo development, but I recall setting up a separate build id when I was looking at this.
I have seen this occur when the IIS server wasn't running on the default port. I'd recommend checking IIS to see if it's running on port 80 as a step to diagnose your issue further.
I eventually managed to get deployment working by calling the _CopyWebApplication build target of the web application from my TFS build script (after manually creating the IIS virtual directory).
I had to add an additional target though to get linked files in the project to be copied also as the built in _CopyWebApplication target doesn't include those.