First creating a new project in VS 2017 with template of ASP.NET Core (and individual authentication) does not have a web.config; yet is added upon publishing the app to C:\inetpub\wwwroot (on new install of Window server 2016, and VS on same machine).
When published, it fails to open a web page giving a "500 - Internal server error" page display. Going into IIS Manager after clicking on mySite in left panel, trying to click on anything in the middle panel for the hosted web site fails to open with this error:
As you can also see it gives no information into the actual error.
So not sure why it's looking to \\?\C: for the web.config file? I believe if I can get help resolving this the web page should load; as it does load in development. As stated this issue is occurring on just deployment of a basic ASP.NET Core template; but it also is doing the same thing with my previous web site created with VS 2015 Community ported over to VS 2017 (with required update to it by VS)
The web.config file, which is only in the published app folder and not the development project folders, is:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\Laier-IT.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
</system.webServer>
</configuration>
This type of issue is typical of an IIS configuration that is not configured for .Net Core.
In order to host .Net Core applications in IIS it is necessary to install the .NET Core Windows Server Hosting bundle.
For detailed instructions on installing the .Net Core Windows Server Hosting bundle checkout the Microsoft documentation on installing .Net Core Windows Server Hosting.
This document also provides extensive information on deploying .Net Core to IIS and various other HTTP Servers.
Additionally you need to set the .Net CLR to no managed code in the application pool settings:
Related
I have an ASP.Net MVC web application. When i initially created the project i specified it as a windows authentication. After some experimentation and development, the requirements shifted away from windows authentication, so i reconfigured the solution/web config etc. to allow anonymous authentication, and to disable windows authentication. However, i seem to have missed something somewhere along the way.
My web application now works great when i publish it, but i am constantly needing to edit the .vs\config\applicationhost.config file.
The config file defaults to the following state whenever i open the solution in visual studio:
<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="false" />
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
These edits are required to get my ctrl+F5 functionality to work, each time i open the project in visual studio 2017.
At this stage i am not exactly sure, whether i should be looking at some setting in visual studio or perhaps IIS Express, so any help would be greatly appreciated!
I received the following communication from Bill H. at Microsoft which resolved the issue, sharing here in case anyone else encounters this problem:
"The value is stored in the project file so that it can be applied when you first download/clone a project. You can change the value in the property grid - select the project and press F4 to see the property grid"
I have been experiencing this weird issue since i have reinstalled my Visual Studio 2017 Enterprise. I have a .NET core application with this following web.confg file.
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="true" />
As you notice, it uses the pass-through authentication. But whenever I run the application through the IDE, it simply overwrites the above line and resets the forwardWindowsAuthToken to false. Which in turns, failed to work in the browser and gives 401 - Unauthorised error. I have reinstalled the VS, reset the settings and even cleared my code repository many times but still no luck.
Any help would be greatly appreciated.
The reason is, you have configured launching project using IIS Express. The web.config file values are required to run it properly. To change the values to use regular IIS, go to project properties and in the Debug tab select Launch: IIS, instead of IIS Express. This will still overwrite your values, but at least IIS integration will work.
You can safely ignore web.config values when you use .NET Core self-hosting, using .exe file, as the web.config is ignored when you self-launch the app that way.
I've been searching Google, reading various questions (and answers) here on Stack Overflow, and scanning the SlowCheetah NuGet page, the GitHub issues list, and the utility author's blog, and I still can't find an answer to figure out exactly what's causing my problems.
I have a solution hosted in a TFS 2013 Git repository. When a particular branch is pushed to the TFS server, it kicks off an automated build and deployment to a build site. All of that is working great. It also kicks off all of the unit tests and everything runs without issue.
That is, until I get to the SpecFlow WatiN tests...
The tests get kicked off without an issue, and I have the server set up to run the WatiN tests interactively within the browser. That all works. The problem is that the site the WatiN tests hit are on the Build server, which is a different URL than what I use locally on my development box (and also from the testing server, which is a third URL). I have the site URL set up in the App.Config of the unit test project (which is an MSTest-based project). I also have XDT transformation files set up for each of our target environments, including the Build environment in question.
When I do a push to TFS, or manually start a build, everything runs fine until it gets to the SpecFlow tests. These particular tests start, and if I'm actually logged into the VM-hosted server that acts as the build server when the build and tests are running AS THE Build/Test user, I can actually see the browser start up. I can also see, briefly, the "This page can’t be displayed" message in Internet Explorer, which is not the expected behavior (I should see the app's login page) and the test fails.
Looking at it a bit further, I started with the obvious - is it hitting the right site? Well, digging into the build folder on the server, I was able to verify that the transformation is NOT working - the app.config file has the site URL for the development machine and not the one for the Build environment!
The transformations for the web project ARE working - the changes for the Build environment are being populated for the front-end web application and the back-end service tier application and they work - I can bring up the site on the build server in a browser. But these projects are not using SlowCheetah, but rather the build-in web.config transformations. The unit test project DOES have the SlowCheetah NuGet package installed; it just doesn't seem to be working for whatever reason.
Here's the app.config file for the unit test project in question:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow" />
</configSections>
<appSettings>
<add key="SiteUrl" value="http://dev.server.url/" />
</appSettings>
<!-- Spec-Flow Configuration -->
<specFlow>
<unitTestProvider name="MsTest" />
</specFlow>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="DocumentFormat.OpenXml" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.0.5022.0" newVersion="2.0.5022.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
The configuration transformation file app.Build.config is as follows:
<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<appSettings>
<add key="SiteUrl" xdt:Locator="Match(key)" xdt:Transform="SetAttributes" value="http://build.server.url/" />
</appSettings>
</configuration>
These configuration files look OK to me, so I don't think there's an issue with the format of the files. I can also verify that the SpecFlow tests run and pass when I run them manually on my local development box. My guess is that either the transformation simply isn't being kicked off, or maybe there's something in the timeline of when the transformations are run and when the unit tests are run.
What am I doing wrong here? Any assistance is greatly appreciated!
In your Build Definition you probably defined the Configurations to use. Part of that also defines a Platform like Any CPU or x86. As it turns out in the solution the Platform Any CPU has a space where in the project files the Platform AnyCPU does not have a space.
I found the best way to get around this was to leave the Platform blank and only put in the configuration name. VS will pop up a warning letting you know that there is data missing, you can just hit Yes to save it anyways. Alternatively you can just type in your configurations like the following |Release,|Debug.
The pattern is [PlatformName]|[ConfigurationName],[PlatformName]|[ConfigurationName],...
I am using MVC 3 with SQL Server 2008 R2 DB.
I installed elmah 1.2.2 and SQL Server script.
Might anybody have some detailed information on how to setup Elmah with SQL Server 2008.
I checked online but could not find detailed information.
Since you have already run the SQL Server setup script and installed Elmah in your MVC application, you should just need to add the following to your web.config to have Elmah send its logs to your sql server instance.
<elmah>
...
<errorLog type="Elmah.SqlErrorLog, Elmah"
connectionStringName="<definedConnectionString>"
applicationName="MyAppName"/>
...
</elmah>
Keeping in mind that you will need to replace "<definedConnectionString>" with the name of the connection string that points to your SQl 2008 instance from your <connectionStrings> section of your web.config.
I would also recommend reading through the following 5 part series: Logging Errors with ELMAH and MVC 3, it contains a lot of great recommendations for using ELMAH with MVC. Also you might consider using installing the Elmah.MVC NuGet Package to change the default behavior of Elmah within an MVC application.
I've run into an interesting problem that I never encountered with XP or IIS 6.
Basically, I can't get a native Delphi (WebBroker) Web service server to work with a native Web service client in Windows 7 64-bit.
Here's the most basic breakdown. If I create a new Web service application in Delphi 2010 (or any version, back to Delphi 7), and access it using IE 8, I can see the HTML that the WSDLHTMLPublish component creates, but I can never get to the SOAP. In the same way, the WSDL Importer cannot get to the SOAP either. (I have IIS 7 configured to use a 32-bit application pool, and I have created a working Script Map to the Handler Mappings. In short, the 32-bit ISAPI Web service is running).
For example, I have a simple Web service server named TestService (created using the default sample interface generated when you create a new Web service server).
I installed it in a virtual directory named scripts.
If I enter http://localhost/scripts/TestService.dll/wsdl, IIS 7 displays the page http://localhost/scripts/TestService.dll.
If I put my mouse over the WSDL link for the ITestService, I see http://localhost/scripts/TestService.dll/wsdl/ITestService in the status bar. However, when I click this link, the address bar shows http://localhost/scripts/TestService.dll/wsdl/ITestService, but I see only the HTML from http://localhost/scripts/TestService.dll. There seems no way to get to the SOAP definition. IIS 7 seems to be ignoring everything after the script name (it is ignoring the pathinfo).
Additional evidence that IIS7 is stripping off the pathinfo is that if I pause my mouse over the ITestService link, the statusbar shows http://localhost/scripts/TestService.dll?intf=ITestService. Clicking that link takes me to another HTML page, the one associated with http://localhost/scripts/TestService.dll?intf=ITestService. However, any link that includes a pathinfo following the script name, takes me simply to http://localhost/scripts/TestService.dll.
I have tested this in Delphi 7, Delphi 2010, and Delphi XE, with the same results.
I am guessing that IIS7 is stripping off the pathinfo, since even the WSDL Importer cannot get to the SOAP definition.
Tried creating a new Web service using the CGI option, and got the same result.
Have any idea what is going on?
Added: Bob Swart reports he has had no problems under Windows 7 32-bit. Downloading the 32-bit OS and will try that (in a new VM).
The problem was that I had created a specific script mapping in the Handling Mappings for the ISAPI dll. This caused IIS to redirect all requests to the specific dll, which was why any request that included an info path part was ignored. The info path was stripped off.
What I really needed to do is to simply enable the Execute feature permission of the ISAPI-dll module mapping handler mapping. This module mapping is available for a virtual directory once you have allowed unspecified ISAPI modules (or CGI modules, if that is the kind of Web server extension you have created).
To fix my problem, I needed to
Delete the directory whose handling mappings I has messed up.
Since I already had allowed unspecified ISAPI modules (select Edit Feature Settings from the ISAPI and CGI Restrictions applet from the IIS section of the server), I then needed to add a new virtual directory for the appropriate Web site (here is where I recreated the directory that I deleted in previous step 1.
From the Handling Mappings applet for the virtual directory, you probably have the ISAPI-dll handling mapping disabled. Select it and select the Edit Feature Permissions option on the right-hand side. Enable the Execute checkbox.
Don't edit the ISAPI-dll handling mapping and add an Executable. Even though this dialog box says that Executable is optional, once you've added one, it's over. You can never remove it (I could never remove it). On one of my VM installs I had an Executable entry on this dialog box. In order to get rid of it, I had to uninstall IIS 7 and then reinstall it. (Maybe this wasn't necessary, but I could not figure out how to remove and reinstall a module mapping without entering the Executable entry).
Additionally, if your ISAPI DLL is a 32-bit DLL, and you're working in a 64-bit operating system, you need to enable 32-bit applications for the associated application pool.
I hope my pain has helped someone.
I know that this question is a little bit old, but this answer might help someone with the same problem.
When you add the Script Map in the IIS Manager it creates the handler in the web.config like this:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers accessPolicy="Read, Execute, Script">
<add name="MyISAPI" path="myisapi" verb="*" modules="IsapiModule" scriptProcessor="C:\MyISAPI\myisapi_extension.dll" resourceType="Unspecified" requireAccess="Execute" preCondition="bitness32" />
</handlers>
</system.webServer>
</configuration>
What you need to do is to add the attribute allowPathInfo="true" to the handler. The IIS Manager doesn't have this option and you have to edit web.config manually:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers accessPolicy="Read, Execute, Script">
<add name="MyISAPI" path="myisapi" verb="*" modules="IsapiModule" scriptProcessor="C:\MyISAPI\myisapi_extension.dll" resourceType="Unspecified" requireAccess="Execute" preCondition="bitness32" allowPathInfo="true" />
</handlers>
</system.webServer>
</configuration>
This way you can choose the request path of the ISAPI extension (in this example: http://HOSTNAME/MyISAPI/myisapi), otherwise without this change you will need to call the ISAPI extension with the name of the DLL (http://HOSTNAME/MyISAPI/myisapi_extension.dll)