I am running the Windows Server 2012 Release Candidate. For testing purposes I deployed the WCF Service Application from the VS Template without modifications on the Default Website. Retrieving the Service1.svc only works if the App pool is in Classic Pipeline Mode but not in the Integrated one.
If I switch to integrated mode I get a HTTP-Error 404.17 - Not Found.
The Isapi Handler to aspnet_isapi.dll for the *.svc extension is registered for 32 and 64 bit as well. The Service works in classic mode. So the handler registration seems to be partly right.
I already tried setting "Enable 32-Bit Applications" to True. Deploying the Application as 32bit or 64 bit made no differnece neither.
What am I missing?
Related
In IIS we had an aspnet_isapi extension that handles the request, it then spawns a process w3wp.exe, w3wp.exe then loads and starts the CLR and then CLR does its job.
Now, Kestrel is configured inside the Main() method, so first the Main() should execute, so who starts the Core CLR ? is it IIS for windows and Apache for Linux? Do IIS and Apache know how to search and start Core CLR?
What I know is, when a .NET application is executed at that time the control will go to the operating system, the OS creates a process to load CLR.
The program used by the operating system for loading CLR is called runtime host, which are different depending upon the type of application that is desktop or web-based application i.e.
The runtime host for desktop applications is an API function called CorbinToRuntime.
The runtime host for web-based applications is the ASP.NET worker process (aspnet-wp.exe).
So, how is it possible that first the Main() method will execute and then the CLR, i am not able to digest it, please help.
Forget about everything you know about IIS.
For Apache or nginx, just run your ASP.NET Core console application (who initializes Core CLR) at a local port (http://localhost:5000 for example), and then set up reverse proxy rules to forward external traffic to that port.
That's roughly what Microsoft documented in this article
Such reverse proxy setup is common, as other web stacks (Node.js, Python, Go) are using the same approach.
Because of this specific setup, Linux launches your .NET Core console app by analyzing the COFF envelope (of dotnet executable, or your own executable for self contained deployment) to locate the native entry (not your managed Main).
Apache/nginx is not involved in anyway.
Calling into this entry triggers CoreCLR initialization, and in turn your managed assemblies are loaded and managed Main is called.
You might find articles like this helpful.
I have .net framework 4.8 web site deployed on IIS 10. And It's pool stops on every first request after each start.
Here is the list of programs and features on server:
Programs and features
In Application Windows log I found 10 errors per each request. Everyone error is:
The Module DLL C:\Windows\system32\inetsrv\aspnetcore.dll failed to
load. The data is the error.
And in System log I have warning:
A listener channel for protocol 'http' in worker process '2968' serving application pool '{MyPoolName}' reported a listener channel failure. The data field contains the error number.
With binary data in details tab: In Words 0000: 8007007E
I tried to repair installed version of .net 5. Also tried to install .net framework 4.8, but installer didn't allow to do it because of:
.NET Framework 4.8 or a later update is already installed on this
computer.
I even tried to create site with empty directory. When I create one on my computer it shows "403.14 — Forbidden" as it should. But after doing the same on server empty site pool stops as my site's pool.
Have you ever faced such a problem? I have no idea how to fix it!
I have .net framework 4.8 web site deployed on IIS 10. And my IIS pool stopped on first request. Researching similair issues I found this artcle on the Microsoft Monitoring Agent APM service. This service was disabled, I removed the Microsoft Monitoring Agent APM as it was not being used. My application now successfully launches.
https://kevingreeneitblog.blogspot.com/2017/03/scom-2016-agent-crashing-legacy-iis.html
Thank you for your help. I solve the problem with complete reinstallation of server OS and components. My consider is that the problem was into iis or OS component.
If run a WCF service application straight out of the box in 64 bit mode with service selected , it works fine an gives me the default data contracts.
If I change app to x86 and build with x86 ( not any CPU ) - and configure IIS 8 application pool for this application to allow 32 bit - it fails. How do I make the WCF Application work in 32 bit ( it must be 32 bit because it needs to be a wrapper for some legacy dlls ) . Note: I haven't referenced the DLLs or anything - it is just straight out of the box default WCF application ( Not a WCF library ) . help :-)
Although I am not sure why it is not working in your case, there are two issues to consider when running in 32-bit mode on 64-bit server:
Setting the platform target in Visual Studio: Setting this to x86 will force the target assembly to be built as a 32-bit application. If the assembly that loads the target assembly is running in a 64-bit process, it will fail to load your assembly
However, you do not have to specify x86 to allow your assembly to be loaded in a 32-bit process. If you specify Any CPU as Platform Target, it can be loaded in either a 32-bit or a 64-bit process.
32-bit IIS process: If your application is running as a web app, (running in an IIS app pool worker process), you’ll want that worker process (w3wp.exe) to be a 32-bit process. That can be specified in the advanced settings of the app pool:
Although is says 'Enable', it actually means “force”, meaning that the app pool worker process will always be launched as a 32-bit process when this setting has a value of True. Setting it to False will launch a 64-bit app pool worker process.
I have a solution which basically contains three components:
• WCF Service that is hosted locally having a back-end SQL Server Express DB and this WCF service is hosted from a Windows Service
• A console application
• A Windows Store Application
This is what they are meant to do:
• WCF service his hosted locally and is used by the console app and the store app for communicating with the database
• The console app adds an image for processing to the database by contacting the WCF service
• The store app will at regular time look for unprocessed images in database via the WCF service and will process them
Now, the difficulty is:
• The WCF service is hosted successfully and is working absolutely fine and I can check that by hitting its URL http://localhost:8081/XYZ
• The console app is also able to submit images to the WCF service and add their local paths to the database
• The store app however always throws the EndpointNotFoundException when accessing the service at that same localhost path
What have I tried:
• I have tried almost everything from searching through stackoverflow to googling and haven't found a solution yet
• I was thinking that it might be a port issue and so I turned off the firewall to check this, but it did not work, and the store app kept throwing the EndpointNotFoundException
What have worked:
• The complete set-up has, however, worked perfectly on my machine. It is strange that its not working on my client's Windows 8 machine.
Point to be noted:
• The complete solution has been developed in Visual Studio 2013 and the App is for Windows 8.1
• I am not sure, but it seems my client has a Windows 8 machine and we are installing the app on that. (Possibly, that might be a problem. But I'll check)
If there is any help someone could provide me, I'll be really greatful. Thanks in advance!
This is expected. Windows Store apps cannot connect back to the local system in production. This loopback prohibition is disabled for debugging.
See How to enable loopback and troubleshoot network isolation
If your app is to be side-loaded rather than deployed through the store then see Using network loopback in side-loaded Windows Store apps
We have a WCF service hosted in IIS that currently calls a VB6 DLL to do part of its job. This works fine, but we can't deploy the service to a 64-bit target environment without configuring IIS to run it in a 32-bit worker process.
I am currently investigating ways around that restriction. Porting the VB6 DLL to .NET is not possible for various reasons, so I created an ActiveX EXE wrapper around the DLL in VB6, so that the service can run in 64-bit and the VB6 parts in 32-bit.
When I tested the service I got this error:
Type: System.UnauthorizedAccessException
Message: Retrieving the COM class factory for component with CLSID {9AE7303B-D159-43F6-B1A5-52D297581820} failed due to the following error: 80070005.
After some Googling I found that this is due to either:
Calling an MS Office component
DCOM permissions not being configured
NTFS file permissions not allowing read/exec access to the IIS worker process identity (ASPNET in my environment)
Of these:
Definitely not applicable
Also not applicable; I am not hosting the EXE in DCOM or COM+, just a simple COM out-of-process activation
This looks likely; however, I checked the permissions, and NTFS reports that the Users group (which ASPNET is a member of) does indeed have read/exec access to the file
I tried calling the EXE from a unit test fixture, which is executed in my admin-level account rather than the IIS worker process account, and it worked fine, so the error is definitely something to do with permissions. I'm not sure what to do next. Can anyone suggest things I can check?
My test environment is Windows XP / IIS 5.1
UPDATE:
The IIS virtual directory is configured for Anonymous+Windows access; the WCF service uses only Anonymous authentication, the Windows authentication is for the VS debugger. Task Manager reports that the aspnet_wp.exe process is definitely running in the ASPNET account.
I explicitly granted Read and Execute access to the ASPNET and IUSR_<machine> accounts on all the COM exes and dlls involved. This made no difference.
I explicitly granted Local Launch and Local Activation access to the ASPNET and IUSR_<machine> accounts on the relevant interfaces in the DCOM configuration. This made no difference either.
As I see it I have 3 options:
Keep trying to get this working somehow.
Go the whole hog and host the EXE in COM+.
Give up. Tell users that the WCF service must be configured to run in a 32-bit app pool on 64-bit Windows.
Your error is an Unauthorized access exception. Therefore, the problem is probably rights related.
You could check what the security context of the 32bit worker process is.
Also check your event log, they may be information there about what account is being used.