I inherited a Silverlight 5.1 asp.net application which has been running successfully on a Windows 2008 R2 server running IIS 7 for many years. I've been tasked with moving this application to a Windows Server 2016 Standard machine with IIS 10.
I installed Silverlight 5.1 (client) and the Silverlight 5.0 sdk on the Windows 2016 machine but otherwise made no changes. The machine has Framework 4.7.2. Several other asp.net applications are hosted on this server, but this is the first Silverlight application.
I tried simply copying the old application to the new server, and also rebuilding and publishing the application from the source code to the new server. I've tried running under both http and https. In all cases I get the error as described below.
When I navigate to the application using IE 11 with the Silverlight plugin installed I get a popup, "Load operation failed for query 'GetUser'. [HttpWebRequest_WebException_remoteServer] Arguments: NotFound..." and etc.
Nothing is logged that can be seen in the Windows event viewer.
Using Fiddler I can see that the browser is making this call first and getting a 404 Not Found error:
GET http://xxx.xxx.xxx.xxx/ClientBin/PMSys-Client-Web-AuthenticationService.svc/binary/GetUser HTTP/1.1
Referer: http://xxx.xxx.xxx.xxx/ClientBin/PMSys.Client.xap
Looking in the source code I see there is a class named "AuthenticationService", which derives from System.ServiceModel.DomainServices.Server.ApplicationServices.AuthenticationBase, which in turn has a GetUser method. I can also see the file PMSys.Client.xap in my "ClientBin" folder. I assume some Silverlight magic inside PMSys.Client.xap creates the path http://xxx.xxx.xxx.xxx/ClientBin/PMSys-Client-Web-AuthenticationService.svc/binary/GetUser.
Using the same instance of IE 11 and Fiddler, but calling the old, successful machine, I notice that it gets Silverlight.js first, and then makes the same call to ...binary/GetUser. On the new, failing machine there is no call to get Silverlight.js. I assume this is a clue.
I can run this application in debug mode in Visual Studio 2017 on my local machine. The App.xaml.cs file contains a method "Application_Startup". This method calls WebContext.Current.Authentication.LoadUser(), which in turn calls this bit of code:
public EntityQuery<User> GetUserQuery()
{
this.ValidateMethod("GetUserQuery", null);
return base.CreateQuery<User>("GetUser", null, false, false);
}
This works on my local machine. I assume this is the "GetUser" call that is failing when I visit the application on my 2016 server; my understanding of Silverlight is that this "GetUser" call is made by the Silverlight runtime in the browser to the server.
My question is, what am I missing in my setup that is causing the 404 error? Why does the old, successful application load Silverlight.js, but the new, failing application does not?
This seems to be a server-side problem. If I paste the path http://xxx.xxx.xxx.xxx/ClientBin/PMSys-Client-Web-AuthenticationService.svc/binary/GetUser into a browser address bar I get a 404 error when I hit the new, failing site. For some reason IIS is simply not serving up Silverlight stuff. But if I pass that same path to my old, working application I get the usual browser prompt, "what do you want to use to open this file," and the result of the call streams down to me.
On both the new (failing) and old (working) sites, if I paste the path of the referer, http://xxx.xxx.xxx.xxx/ClientBin/PMSys.Client.xap, into the browser address bar I get the usual prompt, "what do you want to use to open this file."
I've checked every IIS setting comparing the old site to the new site and they are in agreement, including "Full Trust" and the existence of the .xap, .xbap and .xaml mime types.
Does something else need to be installed on my server in addition to Silverlight 5.1 and the 5.0 SDK?
I've seen several posts about installing RIA Services, but this appears to be a Silverlight 4 issue. RIA services are not installed on the old, Windows 2008 machine and the application is running successfully there. From what I've intuited RIA services need to be installed on the development machine in order to reference the "System.ServiceModel.DomainServices" libraries, but these become part of the deployment in Silverlight 5, so there is no need to install RIA services on the web server. I have confirmed that these libraries are in the deployment.
The answer is to enable HTTP Activation for the WCF Services under the Add Roles and Features Wizard, see this SO answer
We have the following web server and ASP.Net application specs:
Windows 2012 R2
IIS 8.5
ASP.Net Application using .Net 4.0
Classic managed pipeline
InProc session "UseCookies"
We have a problem when a successful login redirect to inner page which check the session keys to proceed, at that certain point the session keys are clear, where as I checked chrome developer tools I found that the asp.net cookie has no value.
I referred to other threads with the same problem but nothing helped, where all solutions been provided was to play with code where actually the same code and setup above is running fine on other servers, so my suspect is may be windows, .Net or IIS settings, where I have tested it locally on the same server using "http://localhost" and I disabled any tools like (firewall, antivirus, etc...) but it was useless.
Is there any configuration I should check?
I've just tried to deploy my first web application to IIS on my Windows 7 Home Premium notebook. After creating the application, I had to change to the Classic App Pool, then set that pool for framework 4.0. Now I get the following error:
HTTP Error 404.17 - Not Found The requested content appears to be
script and will not be served by the static file handler.
The requested URL is http://localhost:80/pvmms/default.aspx
I'm afraid extensive Googling has yielded nothing clear or definite enough for me to work with and as usual I've turned to the experts.
EDIT:
I suspect this is because there are no framework 4.0 handler mappings for .aspx files. However, aspnet_regiis even gives my admin user the finger and says I need admin rights to run it.
EDIT #2:
I registered all the frameworks (2 & 4, 32 and 64) and all now works. I found this by manually adding a script map for .aspx to aspnet_isapi and voila. I don't understand why the installation of the framework doesn't do this, unless my memory fails me and I only enabled IIS after installing VS.
Maybe too late now, but more often than not you need to run
aspnet_regiis.exe -i
after installing asp.net. Maybe I would do it anyway now.
In addition to above, if you need WCF support, you might need to run this:
c:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe -i
Replace v3.0 to whatever your current framework version is.
I encountered this error from IIS 8.5 when trying to access a WCF service I had written. Turns out the server didn't have the WCF HTTP Activation features turned on. Checked the boxes and clicked through the wizard, iisreset, started working.
If you are using iis 7.5.
Just go to IIS Manager, open your website properties.
You will see 'Handler Mappings' section there, just go to that section and Search for 'staticFile'.
Most probably its a last file in the list.
Then Right Click on it and Select 'Revert To Parent'.
I have wasted so many hours while i have faced this first time, anyways this will solve your problem.
I had this issue with Windows Server 2012 with ASP .NET 4.5 you can't use aspnet_regiis.exe, and just have to install ASP .NET 4.5 via the Add Roles and Features Wizard:
You can find the menu item "Add Roles and Features" in the menu "Manage", in the right corner of Server Manager
should check out this option i suppose
I solved this problem by enabling WCF Services
Programs and Features > NET Framework 4.5 Services > WCF Services> HTTP Activation node
But you have to admit it guys this ENTIRE IIS setup configure/guess/trial and see/try this/try that spends 4 or 5 of our days trying to find a solution around approach IS A COMPLETE AND UTTER JOKE.
SURELY, 'IIS' IS THE BIGGEST CONFIDENCE TRICK EVER PLAYED ON MANKIND TO DATE
I know this is an old question, but I've just had this with a 3.5 application on my rebuilt Windows 8 machine and I was still getting this after aspnet_regiis -iru and it turned out the be ASP.NET 3.5 wasn't ticked within Application Development Features (not enough reputation to post an image).
There is a chance that application pool created for you application by default is version 2. So although you see a handler for .svc extension in the list it does not work and treat it as static file. All you need is to open application pool properties and switch it to version 4.
Register asp.net again....will solve the issue.
Go to Visual Studio Command Prompt, And register asp.net as windows\microsoft.net\Framework[.Net version num]\aspnet_regiis.exe -i
I had this same issue on a windows 8 machine I am setting up. I had installed vs2012 before vs2010, which installs .NET framework 4.5. I have my app pools running in 4.0. I made sure I had aspnet registered for 4.0 using aspnet_regiis -i. That still didn't do the trick. Then I opened up the Windows Features and noticed that 4.5 added a set called ".NET Framework 4.5 Advanced Services". I enabled the WCF Service node and its children and then my svc endpoint operated correctly. Hope this helps folks who are making the move to Windows 8.
I stumbled upon this question when I ran into the same issue. The root cause of my issue was an incorrectly-configured app pool. It was set for 2.0 inadvertently, when it needed to be set to 4.0. The answer at the following link helped me uncover this issue: http://forums.iis.net/t/1160143.aspx
For Windows 10/Framework 4.7, I had to turn on HTTP Activation through the following method:
Control Panel > Programs and Features > Turn Windows Features on or off
Under .NET Framework 4.7 Advanced Services, expand WCF Services, select to check the HTTP Activation and whatever else you need when working with WCF
Click OK and let the install do its thing, then open an administrative command prompt and issue the IISRESET command
cmd -> right click -> Run as administrator
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i
For other people reading this:
This can happen is if the .Net version that you have registered isn't the one selected under the 'Basic Settings' of the application pool attached to your website. For instance, your sites application pool has .Net v2.0 selected but you registered v4.0
Just another possible solution I found having the same error message.
When trying to setup a .NET 4.0 web application to a new applicition pool I was receiving this strange error telling me it was trying to process my aspx file with the static file handler, which didn't make sense.
For some reason the ISAPI for .NET 4.0 was set to disabled in the ISAPI and CGI Restrictions area of the server level in the IIS manager. Setting it to enabled was all that was required, however the IIS 7.5 manager is so convoluted and hard to follow it took me a long time to figure this out.
I'm guessing that since it was a 4.0 Application that could not be processed by the 4.0 Engine the static file handler was being used by default.
I had the same problem. When I added Static content feaute for IIS, It works fine.
it could be multiple reason, in my case under Application pool->advance setting->Enable 32 bit application (should be true).It was set to false before.
Using IIS manager, I found that .aspx files were mapped (under "Handler Mappings") to ISAPI 2.0 - even though ASP.NET 4.5 had been previously installed. Editing them to point (also) to an executable for ISAPI 4.0 64bit fixed the issue.
The executable was found in
%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll
i received this message for an application on iis 7.5 with a classic app pool assigned to .net 2.0. i needed to go to Handler Mappings and add two script maps, both were the same with except for the name. one name was svc-ISAPI-2.0-64, the other was svc-ISAPI-2.0. The request path was .svc. And the Executable was %SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll. i restarted iis and all was happy
One of the worst case scenario I just solved is - having conflicting entry in Web.config.
On my local machine I didn't had .woff extension registered in IIS, so I added it using Web.config. But on production server .woff had mime type registered. This caused application level conflict.
Funny part is there are no error logged for this. Just a guess work (first time of course).
So for me solution was just to remove and/or elements from web.config.
I had the same issue, I just changed the target framework version on the website to the version it is developed in,Same in IIS. This solved my problem. Hope this helps...
Thank You
My RESTful WCF Web service appears to break itself if I leave it alone for a while! I can leave my PC with everything working and when I return and test the service with a simple url request it'll offer me the .svc file for download instead of initiating the request on the server!
This WCF service sits in it's own IIS Application folder under the root. I can get the service going again by opening up the IIS sub-folder in Visual Studio, deleting the web.config file and then adding it in again.
My first thought was that HTTP handler mappings for .svc have been borked so I re-ran ServiceModelReg.exe -i, but that hasn't resolved the issue.
Looking at the Handler Mappings for this IIS Application they appear correct and are inherited from the the web root. It's worth mentioning that this site also has another Application folder running WCF services from a .svc fle and is still functioning fine!
Now that I've checked the obvious am a bit flumoxed about where to look next! Hoping someone has suggestions...
Are you running IIS6 or IIS7? And what .NET-version?
IIS6:
http://blog.stevensanderson.com/2008/07/04/options-for-deploying-aspnet-mvc-to-iis-6/
IIS7:
Test this:
"%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" -r -y
Do you really need .svc-extension in the rest url?
This might solve the problem:
http://west-wind.com/weblog/posts/570695.aspx
Try
Go to programs and features, then turn windows features on or off.
Microsoft.net Framework 3.5.1.
Ensure both options are checked
Windows Communication Foundation HTTP Activation
Windows Communication Foundation Non HTTP Activation
Hope this helps.
Check out this article on getting your extension mapped correctly:
IIS Hosted Service Fails
EDIT: Are you hosting the service in your application? Maybe your app pool getting hung?
Well I did figure this out eventually. Just a weird quirk of IE/IIS. I was testing by putting my REST URI in IE's address bar and expecting to see a page of JSON if everything worked. This is what would happen the first time the service was used. On further attempts IE would offer to download a file called 'FooService.svc' that actually contained my JSON data - I was never being offered to download my server-side svc file.
Ho hum, computers eh. Can't live with 'em, ...
enable 32 bit run for connected app pool in IIS 7
It's resolved my problem.
A client has a ASP.NET web service on a shared server (hosted environment). You can go to the web service URL and view the documentation page (xxxxx/service.asmx?WSDL) and see all the methods. Using a tool such as SoapSonar you can execute any of the methods, but the response is always as if you sent (xxxxx/service.asmx) - in other words the web service documentation page.
Is this a medium trust environment? - I don't know, they don't know, don't ask
There are no errors returned or logged.
This is on a Win2k3 server with 3.5 Framework installed and II6. The webservice was build with Visual Studio 2008 and works locally, just not in this environment.
The client has no access to the server, the third party server provider is trying but of limited experience using ASP.NET web services.
Any thoughts on what could cause this type of behavior? What to look for?
Turns out the issue is that the client web.config contains the following entry:
cookieless="AutoDetect"
which causes a 302 redirect /xxxxx/xxxxxx.asmx?AspxAutoDetectCookieSupport=1
(hence it appears that the documentation page is always returned).
Can you verify that the header is sending a POST, rather than GET?