When inspecting a dump file from our application in NTSD, I ran the !DumpDomain SOS command. I was expecting to see just the system, shared and default app domains, but in addition the was a domain called /LM/W3SVC/2/ROOT-1-130793976001194923 which had loaded quite a few assemblies.
Where does this app domain come from and what is the purpose? Our app is hosting IIS - is IIS creating this app domain?
Yes, IIS creates an AppDomain per website like
/LM/W3SVC/2/Root/Website1-x-xxxxxxx
/LM/W3SVC/2/Root/Website2-x-xxxxxxx
If one of the .NET application crashes, it will not affect the others.
From MSDN:
When a request first enters managed code (managed modules or handlers), the IIS ManagedEngine module creates an application domain. The application domain then performs necessary processing tasks, such as authenticating a user with Forms authentication or other application services provided by managed code.
Related
I have a WebApi project that wraps the Dynamics CRM Online web service and provides a REST api. I have a simple controller that gets some contacts from CRM and returns them to the caller.
Everything works fine when I run it in the local emulator. However, when I deploy the project to Azure, I can reach the home page, but the controllers all return http 500 errors. Why would this happen? And how can I troubleshoot to get more details?
UPDATE
The issue is with the absence of Microsoft.IdentityModel.dll on the Server 2012 instance running the web role in Azure. I found this by opening web role instance in RDP, installing Fiddler, and making the request from Fiddler to the local IIS server. It responded with the detailed error.
Now my issue is figuring out how to enable IdentityModel on a Windows Azure Web Role. You're supposed to be able to add it via the Server 2012 Add Roles and Features wizard, but it's totally locked down on the Web Role. You can't check any boxes that aren't already checked. Is this even possible?
The issue is giving the Web Role access to Windows Identity Foundation when it's inherently not there. Marc Schweigert provides clear steps to do this here:
http://blogs.msdn.com/b/devkeydet/archive/2013/01/27/crm-online-amp-windows-azure-configuring-single-sign-on-sso.aspx
Go to the 23:00 mark of the video and you'll see the 4 necessary steps:
Reference Microsoft.IdentityModel.dll (need WIF SDK installed)
a. Set copy local = true
Create RegisterWIFGAC.cmd in your web role project
Create Startup Task in ServiceDefinition.csdef that invokes RegisterWIFGAC.cmd
Add GacUtil to the project (used in the startup task) to put Microsoft.IdentityModel.dll in the GAC every time the web role starts).
I have an ASP.Net MVC3 application that has been running fine in the default Application Pool on my IIS 6 server.
I need to get it running under its own service account, so I created a new Application Pool and moved the application into it. With default settings the application continued to work fine.
I set a custom Identity on the application pool, and the application now just gives me the "Directory Listing Denied" error.
I tried switching the identity back to Network Service, and the application started working again.
What could be preventing the application from running with the custom Identity? It's like ASP.Net is not even starting up.
I've run aspnet_regiis -ga <domain\username> and added the account to the IIS_WPG group, so the identity account should have access to ASP.Net.
More Info
I've been doing some diagnostics with Process Monitor and it shows that aspnet_isapi.dll is not being loaded with the custom identity.
When the identity is "Network Service" I can see aspnet_isapi.dll being loaded followed by webengine4.dll. This happens immediately after the NTLM authentication occurs.
With the custom identity, the NTLM authentication happens and then the w3wp process just starts looking for the default files (Default.aspx, Default.htm, etc).
I've checked, and the account has access to the framework version folder where these DLLs are stored.
you need to give the user that you are specifying in the custom identity explicit read or read/write at the folder level of you application. Right click on the containing folder then "Properties" and add the user with the permissions required by the app to the security tab.
Turns out I needed a wildcard mapping to aspnet.isapi.dll, though I'm not sure why.
Without the custom identity the application works fine without a wildcard mapping. With the custom identity I need the mapping. On another server the custom identity work fine without a mapping. Weird.
Did you already check Directory browse settings?
http://www.iis.net/configreference/system.webserver/directorybrowse
Now that you are using a different user then the default one, make sure that you have set the Anonymous Authentication to use the app pool user. There could also be something related to what #Gabe Thorns mentioned, it might be an issue with wildcard mappings. If you do not have wildcard mappings set to run the asp process then it will try and look for files, avoiding asp processors.
Hope that helps.
Have you explicitly granted permissions to the application pool identity on the application folder?
The account should be something like IIS AppPool\MyAppPoolName
More info on this can be found here:
http://www.iis.net/learn/manage/configuring-security/application-pool-identities
I have an Azure Website developed for which I would like to reduce the initial loading time. On a regular ASP.NET site I would configure the Application Initialization IIS module, but with Azure Websites direct IIS configuration is not possible.
The website is running in reserved mode if that makes any difference.
Actually, Application Initialization module is installed by default for Azure Web Apps. You can directly configure it from either your web.config file or through apphost.config XDT. Just stick something like below in a web.config in the root of your web app.
<system.webServer>
<applicationInitialization
doAppInitAfterRestart="true"
skipManagedModules="true">
<add initializationPage="/default.aspx" hostName="myhost"/>
</applicationInitialization>
</system.webServer>
Application Initialization is not supported with Windows Azure Websites. because it is a native module and Windows Azure Websites does not allow configuring native modules via web.config.
Alsom the content for Windows Azure Websites are physically located at a centralized location and from there they loaded and executed to webservers. While shared instance gets a slice of host VM, versus reserved instance get a full host VM to run your web applications, in both cases the website application is coming from same centralized located so it does not matter if you have reserve instance to get Application Initialization working.
Application Initialization is necessary for your application and your websites is running in reserve mode, you can use Azure VM or Windows Azure Web Role to have it working.
Currently there's "Always On" setting for Azure Websites which does pretty much the same thing.
When I create a new "WCF Service Application" in Visual Studio and right-click Service1.svc, I can choose "View in Browser". A web browser appears showing http://localhost:50311/Service1.svc, which says
Service1 Service
You have created a service.
To test this service, you will need to create a client and use it to call the service. You can do this using the svcutil.exe tool from the command line with the following syntax:
svcutil.exe http://localhost:50311/Service1.svc?wsdl
...
The service somehow seems tied to Visual Studio itself, since the web page becomes inaccessible if I close the solution. What's going on? I don't have a web server installed, and I didn't (knowingly) start the service. What is the source of the displayed web page, and why is it on port 50311? Can the page be customized?
What you're seeing is the development web server that starts when you run a debugger instance of a project that requires a web server. (WCF, ASP.NET).
The port 50311 is determined by your project settings (most likely random, but you can specify).
The page for a .svc file is not meant to be customized. Since the service is waiting for a caller, that default page simply tells you that it's running properly.
Keep in mind that WCF offers several binding options that use various protocols (HTTP, TCP). Depending on the protocol that you choose, you will have to host in either IIS, a Windows Service or elsewhere. By default, new services will adopt a binding that works in IIS.
Check out Introduction to Building Windows Communication Foundation Services
We're developing an application that is sensitive to the domain name of the request. The problem we're running into is that we have to use IIS in order to test the application because Cassini will only send "localhost" as the requested domain despite using a different domain in the address bar. While IIS does give us better performance than Cassini, we would still like to be able to hit F5 to run our application from within Visual Studio.
Is there any configuration that can be done to specify the domain name to use in Cassini?
I just released the CassiniDev 3.5.1/4.0.1 beta with a simple test fixture example if you are interested.
It supports arbitrary IP addresses and host names. Should fit your needs quite nicely.
http://cassinidev.codeplex.com