I have an MVC website (MVC 5.2.2.0), that uses ImageResizer and Azure Blob Storage, using the AzureReader2 plugin.
I am using default settings, so images will be accessed through /azure/images (where "images" is the name of my container), and it works perfectly in development - and if I deploy to an Azure Website using Debug settings.
If I deploy using Release settings, images stop working and return 404s with a times new roman text "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.", as shown below.
This is from my web.config, and is NOT modified on release (I double-checked):
<resizer>
<plugins>
<add name="MvcRoutingShim" />
<add name="AzureReader2" connectionString="DefaultEndpointsProtocol=http;AccountName=[accountname];AccountKey=[KEY]" endpoint="http://[account].blob.core.windows.net/" />
<add name="DiskCache" />
</plugins>
</resizer>
I am lost and don't know where to begin troubleshooting. I have tried disabling DiskCache plugin, which does not make any difference.
This is most likely because your configuration is enabling pre-compilation when you switch to release mode. Disabling pre-compilation should allow VirtualPathProviders to work again.
See "File Not Found - cause #4" in the Troubleshooting Guide for more information.
Related
I have an ASPNET Core project that is running a set of RESTful services using C# and Newtonsoft.JSON 11.0.2 which I incorporated using NuGet. When I run everything locally using Visual Studio 2017 and IIS Express, things work fine and my JSON Deserializer efforts work with no issue.
When I publish the solution in a Web Deploy package and then install that application in IIS 10 on a Windows Server 2016 instance in AWS, the deserializer fails. The error is:
Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value: <. Path '', line 0, position 0
It does not matter if I publish in Debug or Release mode.
I ran Postman calls and the JSON being returned is both validate and produces the correct objects. I did see that, in the Solution Explorer, the version is 11.0.2 but in the assets JSON file, the version is pointed to 10.0.1. The .CS project file, when viewed in a text editor outside of Visual Studio, does show 11.0.2.
When I look in the deployed application's folder on the server, I do not see any NewtonSoft DLLs but I do see other NuGet-obtained DLLs. This might not be an issue given how JSON.NET deploys but I thought it was worth mentioning.
I then included a logger and sent the incoming JSON to a file and, again, it all validated as expected.
I have tried everything, ensured CORS is properly implemented both in the application and in IIS. I am at a complete loss as to how to proceed.
Can somebody please help?
Thank you!
I had the same problem and solved by this code in web.config
<system.webServer>
<handlers>
<remove name="WebDAV" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
<modules>
<remove name="WebDAVModule" />
</modules>
</system.webServer>
I sometimes browse old question that has no/accepted answers and check if they are still in need of some help, or if something can be done to close the cold case.
This post has already been solved, but the cause and the solution were left only in the comments.
If the first character encountered when parsing is <, you can be sure
that is not JSON. Something is probably sending XML or HTML to your
code in the deployed environment. I would look at that angle. This
doesn't seem like a version conflict to me, otherwise you would be
getting a much different error about not being able to load the file
or assembly. I think this is solely a data problem.
Brian Rogers
#Brian Rogers - Thank you SO MUCH for this last comment. I ended up
opening Production to my development machine and then running
Wireshark to see the communications. Turns out that IIS had "GEWT"
instead of "GET" in the allowed methods web.config for the host
website and I was getting rejections in the cloud instead of the JSON.
Every test I ran which generated output was LocalHost but, of course,
none of the real production work used anything local. Once I fixed
that error, everything worked great!
Ken Tola
#ken-tola, can you please self-answer the question and then accept it to close the case.
What's the difference between:
<compilation debug="true" /> (the default VS 2013 web.config in debug mode)
<compilation debug="false" />
<compilation /> (the default VS 2013 web.config in release mode)
The bundling and minification now is always turned on by BundleTable.EnableOptimizations = true; so I'm wondering why the usage of this element and why the false value is not the default in release mode.
Without listing all the things it does, lets just say it does a lot. Of significance, disabling debug turns on browser caching of generated script resources and some other things you may not want cached.
Also, if an exception occurs it won't display the file name, function name and line number of the file in your source.
Debug=false SHOULD be set once you deploy your project to a staging server or QA server but it should be debug=true on your own machine for development lest you run into confusing problems about why changes that you make don't see to be reflected in the running web site etc (caching) or where exactly an error/exception happened in your code.
Here is a link that goes into deeper details on what debug=true does:
debug=true in web.config = BAD thing?
To get some diagnostics for our MVC4 application (with an WebRole for Microsoft Azure) we installed Glimpse through NuGet.
Everything went fine, but when I enable Glimpse through the ~/Glimpse.axd page our application is completely unreachable. On every request we get the message "This Webpage is not available" (Chrome).
In the output window in Visual Studio 2013 I saw an error message which suggests to disable async support through the web.config:
<appSettings>
<add key="Glimpse:DisableAsyncSupport" value="true"/>
</appSettings>
Unfortunately this is not helping. When we turn off Glimpse everything is just fine.
How can I find out what the problem is?
Update
The logs shows me this warning:
WARN | Unable to locate '</body>' with content encoding 'Unicode (UTF-8)' for request. The response may be compressed or the markup may actually be missing a '</body>' tag.
Found my solution on the troubleshooting page of Glimpse.
In short, url compression was applied so had to disable this in the web.config:
<system.webServer>
<urlCompression doDynamicCompression="true" dynamicCompressionBeforeCache="false" />
</system.webServer>
I'm currently struggling with httphandlers in IIS.
I'm developing a website in .NET4 in VS2010 and Cassini. In this website, i have a gallery, whose pictures are loaded through my handler.
For example http://mywebsite.com/Gallery/123/Pic1.jpg
My HTTP Handler gets the id 123 and returns the picture from the database (simplified).
So, everything works fine in Cassini (VS integrated webserver) and in IIS7 in "integrated mode". Pictures are loaded like they should.
But I have to deploy this site on a shared hoster, who is using IIS6.
After many searching and own logging, I found out, the the request isn't routed to my handler, and so I get a 404 from IIS.
My definition which is enough for IIS7 integrated mode:
<system.web>
<handlers>
<add verb="*" path="Gallery/*/*" type="[coorect Type spec]" />
</handlers>
</system.web>
For IIS7 in classic mode I had to add
<system.webServer>
<handlers>
<add name="ImageHandler" verb="*" path="Galler</*/*" type="[type]" modules="IsapiModule" scriptProcessor="c:\windows\Microsoft.net\framework\v4.0.30319\aspnet_isapi.dll"/>
</handlers
</system.webServer>
This last config only works whith the stuff in the module and scriptprocessor attributes...
But this config doesn't work in IIS6....
Can anyone help me ?
The issue is that IIS6 typically decides what ISAPI handler to pass the request to by using the file extension. So it sees .jpg and tries to serve a static file from that path. This is also what IIS7 refers to as classic mode. And you'll note you are referencing aspnet_isapi.dll in your configuration because it needs to be told what should handle this. Once you've passed it into aspnet_isapi, the asp.net http handling pipeline kicks in and you can execute your handler.
The easiest fix would be to find a host that supports IIS7. Failing that, you could see if they have any url rewriting options. With that, you could rewrite things so that you append an .ashx on the url, which will let IIS6 grab it and put it into the asp.net pipeline and your handler would fire. You could also see if they allow wildcard mappings, but that is a very tall order for most shared hosts.
I have deployed a few WCF services to a server via a web setup project
they are being hosted in an IIS Application, which appears to be running fine.
However when i try to navigate to the wsdl, nothing is found.
I am trying to set up diagnostics logging, to get some information.
I have followed the advice from here: wcf trying to set up tracing to debug, not writing to log file
Also, I have tried what is in the referenced MSDN documentation: under "Recommended Settings for Deployment or Debugging" .. my web.config has that identical configuration. But no log file is being created.
Nothing useful in the event viewer.
Any ideas?
Could be a permissions issue; IIRC those don't always turn up in the event log. Ensure the user IIS runs under has write permissions to the log file path.
This is typically the diagnostic config I use. Seems to work for me.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
...
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.ServiceModel"
switchValue="Verbose">
<listeners>
<add name="sdt"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="D:\wcfLog.svcLog" />
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>
If you are not getting any output it may be because your service is not starting correctly. The ServiceHost must be up for diagnostics to output anything. With IIS even though your site is running it does not mean that the ServiceHost started correctly. It's usually a config issue. I'm not a web guy but doesn't IIS write to EventViewer if there is an unhandled exception in the website?
Also, you could try creating a custom ServiceHostFactory. That way your code controls the ServiceHost creation and you can trap any exceptions and log them on your own.
Creating a custom ServiceHost in IIS -> LINK
This is an old question but for the benefit of anyone who might stumble upon the issue:
Make sure you have configured both the system.diagnostics and the System.serviceModel/diagnostics sections configured.
Make sure you have them configured in the correct App.config/Web.config file. The thing to note is that multiple config files may exist in a project, and the one used depends on the Build Configuration.
Personally I had the very same symptom until I noticed that I put the sections
under app.config (in my case, client side tracing), instead of
app.DebugLocal.config. The later was used as my build configuration was set to DebugLocal.