When I deployed my app I had to add following code to my web.config file because otherwise the server won't display my .svg file
<system.webServer>
<staticContent>
<mimeMap fileExtension=".svg" mimeType="image/svg+xml" />
</staticContent>
<system.webServer>
However, if I leave that bit of code in the file while I develop on my machine, it leads to weird errors (e.g., my machine doesn't load my .css file anymore). All works fine if I comment that out again while working locally.
But exactly that is a hastle, commenting/uncommenting that code always when developing resp. deploying.
So my two questions:
1) Is there a way to include code conditionally in the web.config, e.g., depending on if degug or release build, or if deploying?
2) Why is that code causing trouble on my local machine in the first place?
UPDATE: So Q1 is answered, but still looking for an answer to Q2! Can't accept an answer before that ...
In your web.config File you have an arrow that points to two other Files called Web.Release.config and Web.Debug.config there you can make such changes. There you can modify your web.config based on your Run Mode.
There is a very good Microsoft Article about it im pretty sure it will help you
https://msdn.microsoft.com/en-US/library/dd465326(VS.100).aspx
I had the OwinStartup configuration code working perfectly and then it stopped working. Unfortunately I'm not sure exactly what I did to get it to stop working and am having a really hard time figuring it out.
To make sure I have the basics covered, I doubled checked to make sure the I have the
[assembly:OwinStartup(typeof(WebApplication.Startup))]
attribute assigned properly and made sure that I don't have an appSetting for owin:AutomaticAppStartup that is set to false so I made one set to true to be safe as there was nothing there before.
<add key="owin:AutomaticAppStartup" value="true" />
I also tried specifically calling out the appSetting:
<add key="owin:appStartup" value="WebApplication.Startup" />
Before it stopped working I upgraded the Microsoft.Owin.Security NuGet packages to 2.0.2, so I tried reverting them to 2.0.1 (that was a pain) but it didn't change anything. I have WebActivator installed on the project and am using that to bootstrap other things but I've tested that on a fresh WebApplication template and it works there so I don't think that is the culprit.
I also tried removing my Startup class and using Visual Studio to add a new one using the OWIN Startup Class type in Add New Item and that isn't getting called either. Next I tried adding a second Startup class since I know it will throw an exception if there is more than one OwinStartup attributes defined, but it isn't throwing any exception there.
Not sure what else to try. Any thoughts?
Update
Turns out that Resharper removed the reference to Microsoft.Owin.Host.SystemWeb when I used it to remove unused references.
Make sure you have installed Microsoft.Owin.Host.SystemWeb package in the project. This package is needed for startup detection in IIS hosted applications. For more information you can refer to this article.
If you've upgraded from an older MVC version make sure you don't have
<add key="owin:AutomaticAppStartup" value="false" />
in your web.config. It will suppress calling the startup logic.
Instead change it to true
<add key="owin:AutomaticAppStartup" value="true" />
I realize you already mentioned this but sometimes people (like me) don't read the whole question and just jump to the answers...
Somewhere along the line - when I upgraded to MVC 5 this got added and I never saw it until today.
Alternative answer to the original problem discussed - Owin "not firing." In my case I spent hours thinking it wasn't firing due to being unable to set a breakpoint in it.
When debugging OWIN startup in visual studio
IIS Express - Running "F5" will break on the OWIN startup code
IIS - Running "F5" will not break until after OWIN (and global.asax) code is loaded. If you attach to W3P.exe you will be able to step into it.
If you are having trouble debugging the code in the Startup class, I have also had this problem - or I thought I did. The code was firing but I believe it happens before the debugger has attached so you cannot set breakpoints on the code and see what is happening.
You can prove this by throwing an exception in the Configuration method of the Startup class.
DEBUGGING TIPS
If debugging does not work try using IIS Express or try the method below for local IIS
Using local IIS
For some reason this method enables debugging of this method:
Request a webpage
Attach to w3wp.exe process
Touch the web.config file
Request a webpage
Extra tip
Maybe doing this will flush a cache:
In web.config add the optimizeCompilations attribute with a false value
<compilation debug="true" ... optimizeCompilations="false">
Run site
Undo the change in web.config
I had a similar issue to this and clearing Temporary ASP.NET Files fixed it. Hope this helps someone.
I had the same problem. Microsoft.Owin.Host.SystemWeb package was installed but during the installation NuGet was not able to add the dll as a reference for some reason. Make sure your project has that reference. If not you can try to reinstall:
update-package Microsoft.Owin.Host.SystemWeb -reinstall
I had an error like below on reinstall but somehow it worked:
System call failed. (Exception from HRESULT: 0x80010100
(RPC_E_SYS_CALL_FAILED))
I had same problem when I added Owin to an existing web project. I eventually found the problem was due to the following in the web.config file.
<assemblies>
<remove assembly="*" />
<add assembly="System.Web.Mvc" />
<add assembly="System.Web.WebPages" />
...
</assemblies>
The remove assembly="*" was causing the problem. When I remove this line the Owin startup code ran.
I eventually change it to the following and it worked perfectly
<assemblies>
<remove assembly="*" />
<add assembly="Microsoft.Owin.Host.SystemWeb" />
<add assembly="System.Web.Mvc" />
<add assembly="System.Web.WebPages" />
<add assembly="System.Web.Helpers" />
...
</assemblies>
In my case this Microsoft.Owin.Host.SystemWeb package is present in the project.
But below two tags are not present in web.config.
<add key="owin:AutomaticAppStartup" value="true" />
<add key="owin:appStartup" value="namespace.className.methodName" />
after adding them it works smoothly.
In my case, the IIS application pool was not set to v4. It was v2.
Changed the AppPool to v4 and everything was okay.
In my case, my web.config had
<authorization>
<allow users="?" />
</authorization>
To force it to fall back to Owin, I needed it to be
<authorization>
<deny users="*" />
</authorization>
I found the following article to be very helpful:
https://weblog.west-wind.com/posts/2015/Apr/29/Adding-minimal-OWIN-Identity-Authentication-to-an-Existing-ASPNET-MVC-Application#MinimalCodeSummary
In my case, I had to set the following before Owin authentication would work instead of windows authentication:
<system.web>
<authentication mode="None" />
<system.web>
This worked for me:
add authentication mode="None"
<system.web>
<compilation debug="true" targetFramework="4.6.1" />
<httpRuntime targetFramework="4.6.1" />
<authentication mode="None" /><!--Use OWIN-->
</system.web>
In my case, my website's output path is changed by somebody, the IIS Express even not load OWIN, and the setup class will not be hit of course. After I set the output path as "bin\", it works well.
I am not sure if this will still help someone, but I've done all of the solutions above (and from some other posts) to no avail.
What fixed the issue on my end was to put a backslash to the end of RedirectUri value in the web.config (crazy, I know!). RedirectUri is a parameter in UseOpenIdConnectAuthentication.
So, instead of:
<add key="ida:RedirectUri" value="https://www.bogussite.com/home" />
Do this:
<add key="ida:RedirectUri" value="https://www.bogussite.com/home/" />
And updated the Reply URL on the Azure App Settings as well.
That somehow made the Startup to run as expected (probably cleared some cache), and the breakpoints are now firing.
FYI. I was modelling my code from here: https://github.com/microsoftgraph/aspnet-connect-sample
After converting a class library to a Web Application Project, I ran into this and became stubborn. Turned out, in my .csProj file, I had this:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
thus building the various dll's into a subfolder of the bin-folder (which ifc. won't work). Solution was to change both text-contents for OutputPath to just bin\.
For me it was because they are not in the same namespace. After I remove my AppStart from "project.Startup.AppStart" and let they both Startup.cs and Startup.Auth.cs with "project.Startup" namespace, everything was back to work perfectly.
I hope it help!
If you are seeing this issue with IIS hosting, but not when F5 debugging, try creating a new application in IIS.
This fixed it for me. (windows 10) In the end i deleted the "bad" IIS application and re-created an identical one with the same name.
I think what some people were trying to get to above is that if you want to programatically make your OWIN server "come to life", you'd be calling something like this:
using Microsoft.Owin.Hosting;
IDisposable _server = WebApp.Start<StartupMethod>("http://+:5000");
// Start Accepting HTTP via all interfaces on port 5000
Once you make this call, you will see the call to StartupMethod() fire in the debugger
In case you have multiple hosts using the same namespace in your solution, be sure to have them on a separate IISExpress port (and delete the .vs folder and restart vs).
I messed around with a lot of the suggestions on this post.
I had the following but still could not land on a break point. Throwing an exception proved the code was being entered.
<appSettings>
...
<add key="owin:AutomaticAppStartup" value="true" />
<add key="owin:appStartup" value="SSOResource.Startup, SSOResource" />
...
</appSettings>
Finally out of desperation I looked at project->properties, and then under the WEB section I also checked the NATIVE CODE checkbox (ASP.NET should be already checked).
That finally fixed it for me.
Note : I am using Visual Studio 2017 Professional.
First add the OWIN Auth Class and then enable OWIN:AutomaticAppStartup key in your web.config like
Now it will fire
I have an MVC WebAPI site that has the latest ELMAH.MVC NuGet package installed. Under Visual Studio, I can access
http://localhost:1234/elmah
and get the error log, just like I'm supposed to be able to.
When I deploy it to Azure, it throws an error when I do that. Fortunately, Elmah is logging the error to the XmlError log in App_Data, and I found this:
<error errorId="92ad3ee1-3fd5-449a-8cb4-0474aa771aab"
application="/LM/W3SVC/417796901/ROOT"
host="RD00155D430783" type="System.Web.HttpException"
message="Server cannot set status after HTTP headers have been sent."
source="System.Web"
detail="System.Web.HttpException (0x80004005): Server cannot set status after HTTP headers have been sent.
And then goes on for many lines of stack trace, NONE of which comes anywhere near my code.
What's going on? I've just added the Elmah.MVC nuget package, and made the following changes to the Web.Config
<elmah>
<security allowRemoteAccess="yes"/>
<errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/App_Data" />
</elmah>
<location path="elmah.axd">
<system.web>
<allow roles="*" />
</system.web>
</location>
It's not coming anywhere near any of my controllers, so I don't have any control over when Http status headers are set or sent.
Thanks for any help.
itanex is right! Put an empty text file (i.e. placeholder.txt) in the App_Data folder and mark it as "Content" and "Always Copy" - This will ensure that the App_Data folder is getting created. Also, as Simon point out, the correct path (based on your config) is /elmah.axd
via https://stackoverflow.com/a/11680786/1037948:
Allow remote access:
<elmah>
<security allowRemoteAccess="true"/>
</elmah>
I have an MVC 4 application with an .otf font in the /images folder. It works on my desktop, but when I deploy to azure I get a 404 when trying to access /images/myfont.otf
The font already has the Build Action property set to 'Content'
How can I force Azure to pick this up?
You probably need to configure the IIS to properly serve this file type. You do this by adding the following to the <system.webServer> element in Web.config:
<staticContent>
<mimeMap fileExtension=".otf" mimeType="font/otf" />
</staticContent>
More info
http://www.big.info/2013/06/how-to-use-otf-opentype-format-fonts-on.html
Place the following in web.config in the system.webServer configuration:
<system.webServer>
<staticContent>
<remove fileExtension=".otf" />
<mimeMap fileExtension=".otf" mimeType="font/otf" />
</staticContent>
</system.webServer>
HTTP Error 404 means the content is not found on server. It does mean that when you deploy your application to Windows Azure the content was not in the package.
As you suggested above that you do have .OTF set as content it means that you are asking compiler to treat it as static file and don't build it however specific file will not be copied to the final output folder to be the part of final CSPKG. You would need to set "Copy to output directory" as "copy always" so it can be part of CSPKG and deployed to Azure Cloud service.
Once you set file properties correctly and build your application, you can manually visit to your output folder to the verify that file is there as well as your CSPKG just by unzipping it.
The problem for me is that the files weren't included with the project. They were in the correct file path ((project)/Content/fonts/*), but not considered part of the project (i.e. references by the *.csproj file). The solution was to right click the fonts folder and choose the Include in Project option.
My best bet is that you've got relative paths to your font files within your css.
Are you getting a 403 Forbidden? That might indicate that your filepath's are off.
Try changing your paths from ../filename.otf to something like /Styles/filename.otf (or whatever your path is)
My ASP.NET MVC application is within a folder called Stuff within IIS 6.0 webroot folder. So I access my pages as http://localhost/Stuff/Posts. I had EMLAH working while I was using the in-built webserver of Visual Studio. Now when I access http://localhost/Stuff/elmah.axd, I get resource not found error. Can anyone point my mistake here! Here is config file entry,
<add verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah"/> //Handler
<add name="ErrorMail" type="Elmah.ErrorMailModule, Elmah"/>
<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
<add name="ErrorFilter" type="Elmah.ErrorFilterModule, Elmah"/> //Module
Working with IIS7 I found I needed both sections of the web.config populated (system.web AND system.webServer) - see Elmah not working with asp.net site.
Perhaps this is related.
Have you added an ignore *.axd routes in global.asax?
For Elmah, we need to differentiate between two things:
First the http modules doing all the work of error logging, emailing...etc.
Second, the http handlers, displaying the error log page and other pages (rss...etc.)
I was having the same problem of 404 resource not found because I have a weird setup!
on my development machine, (windows 7, iis 7 ) elmah was working like a charm because the application pool was working in the integrated pipeline mode. In the production machine, however, the application was using the managed pipeline and I tried all my best to make elmah work but it was all useless...
I then got the idea of displaying the UI (error log page, rss, error detail,...) using regular aspx pages.
I downloaded the source code, made some changes (sorry Atif, I was forced to do this because I needed the quickest solution) and then in my application , I created a folder under which I created regular aspx pages which inherits from Elmah defined pages.
The page only contains one line (ex: for the detail page: <%# Page Language="C#" Inherits ="Elmah.ErrorDetailPage"%>)
Now, I was able to run Elmah regardless of IIS 6/7 and it is working like a charm.. and It saved me from a big headache of correctly configuring http handlers and troubleshooting its work! additionally, configuring security is much simpler!
I don't know if the community is interested in this solution (If so, I am ready to post my full changes).
Hope that this gives you an idea on how to solve the problem in an alternative way (and if you need the modified dll with complete instructions on how to use it, just tell me!)
In the application pool settings in IIS set Managed Pipelin Mode to Classic if you don't want to change code or the web.config file. Your axd.s will then work as before.
Can you post the rest of your web.config?
Or, if you're comfortable enough, can you just ensure that the httpHandlers and httpModules (NOT handlers and modules) sections are filled in properly in the web.config?