I have a old style .NET Web Service running in IIS correctly on my local machine:
http://localhost/MyService/MyService/Service1.asmx
I added a Web Reference and set it's property to dynamic so that I could simply change the URL in the Web.config file. Prior to deploying to staging server, I configured it thus:
<client>
<endpoint address="http://staging.myserver.net/WSTest/WSTest/Service1.asmx"
binding="basicHttpBinding" bindingConfiguration="Service1Soap"
contract="ServiceReference1.Service1Soap" name="Service1Soap" />
</client>
I can access it on the server like this and it works:
http://staging.myserver.net/MyService/service1.asmx
However, I need it to resolve like the following as this is how external clients are accessing it:
http://staging.myserver.net/MyService/MyService/service1.asmx
I can see nothing wrong with the IIS configuration settings on my staging server. Am I missing something?
Generally speaking, you are free to set up applications under a website, even in nested way.
Website
|
--Application MyService
|
--Application MyService (here you host the .asmx)
Like you discovered, it is very easy to achieve.
However, there are a few red flags,
.asmx is too old, and most people upgrade to REST/Graph based web API.
Nested applications are still rare (or unnecessary). In most cases you should aim at short URLs. But since it is your external users who demand such URL pattern, you might not have a way to convince them.
Related
I know there are related posts here on this forum and another resources but I got stuck with this and couldnt proceed.Problem is i've done a website with vs2010 when i publish it to ftp server and navigate to url adress I got this error. Here the things that i've done
-I've enabled IIS services and static content
-I've revert to parent the staticFile under handler mappings
-I've registered the asp.net again in command prompt(the regiis.exe thing)
-In IIS manager i've added my website adress under sites, stopped default web site and started mine.
-I've added my site to classic.NET AppPool(integrated,and v4.0)
-I've enabled the default browsing..
-I've done all the advices that generally covered..
Here is my web.config
<configuration>
<system.webServer>
<directoryBrowse enabled="true" showFlags="Date, Time, Size, Extension" />
<defaultDocument>
<files>
<add value="AnaSayfa.aspx" />
</files>
</defaultDocument>
</system.webServer>
<system.web>
<compilation debug="true" targetFramework="4.0" />
</system.web>
</configuration>
where am I doing mistake? I've spent 2 days and couldnt proceed an inch.I will burst into tears if this problem solved.Any help will be greatly,greatly,greatly! appreciated,will be my hero,master (: thanks
Go to Command Prompt and install / repair ASP.NET
C:\Windows\Microsoft.NET\Framework\v4.0.30319>aspnet_regiis -i
Go to IIS => Select the Server Name (System Name)
Go to ISAPI and CGI restrictions
Allow the Not Allowed restrictions.
I got this working when i change the app pool's .Net framework version to my application's .net framework version.
My application's framework version was 4.0 but app pool's setting was defaulted to 2.0. I had to change it to 4.0, then it worked fine.
+1 with #Dablue, IIS 8.5 does not support the aspnet_regiis command anymore. For me, the issue is resolved by installing the "Asp.Net 3.5" or "Asp.Net 4.5" under
Web Server > Application Development.
#regeme - I was experiencing a similar problem when trying to run my own site and after a lot of digging I finally resolved it. In my case it was related to a *.json file trying to be loaded and no rules being initialized for it. If you look closer at your error it should give you an idea of what it is IIS is not loading.
After looking at the web inspector's network tab I was able to see which items were returning 404's they were all *.json.
I'm assuming since your error is returning a "content appears to be script and will not be served by the..." it is the same case.
My resolution:
A) It is possible you have already done this as it would throw another error, I'm just covering our bases.
Go to IIS HTTP Response Headers
create a mime-type ".json" "application/json"
B) **SEE NOTE
Go to Handler Mappings.
Set Request Path: to "*.json"
Executable: to "C:\Windows\System32\inetsrv\asp.dll"
C) You may want to restart your service at this point again just to be safe this can be done in the IIS panel or cmd prompt.
Windows key + r
type: cmd and hit ctrl+shift+enter
type: iisreset and hit enter
*NOTE: This may save you a lot of headache, in my case I installed the 64 bit dll of asp.dll instead of the 32 bit version the folder for the 64-bit version is in C:\Windows\SysWOW64\inetsrv\asp.dll
IMPORTANT these file locations are in windows 8 and to my understanding are the same in windows 7 but this may not be the case for your OS double check.
Lastly if you are missing the asp.dll this is simply because you are missing windows features. Simply go to add/remove programs (Programs and Features)
Turn Windows features on or off
drop down Internet Information Services
drop down World Wide Web Services
check Application Development Features make sure it's not just a partial check and that all sub-items are being installed
On Windows 2012 and IIS 8.5 aspnet_regiis is no longer valid.
Instead, add the aspnet-4.5 rolefrom within server manager
Open server manager
in the left column select IIS
Scroll the right window until you see "Roles and Features"
Tasks select Add roles
Under "server roles" open "Web Server (iis)
open "Web Server"
open "application development"
Select "ASP.NET 4.5" (the "asp.net 4.5 extensibility" will not do it)
We got the same issue when hosting our MVC application on the web server. All the applications were working fine except the WCF service.
It was resolved, when we added a server role for .NET Framework 4.5 WCF service in Windows Server Manager.
Visit http://community.bamboosolutions.com/blogs/bambooteamblog/archive/2013/02/08/how-to-enable-and-use-net-framework-3-5-and-4-5-in-windows-server-2012.aspx
For me the issue was fixed by right click on Virtual directory-->convert to application
Check out this, in my case this solved the problem
https://support.microsoft.com/en-us/kb/2019689
This might help you
In this case, a 404.17 error is returned if the *.aspx resource being requested from the site is handled in an Application pool that is not running in Classic Mode, is not 32 bit, or is not running the 2.0 version of the .NET Framework. In order for the resource to be served correctly in this example, all 3 pre-conditions must be met. Specifically, the application pool hosting this resource would have to be configured for Classic Mode, it would need to be configured to use the 2.0 version of the .NET Framework, and it would need to be set for 32 bit applications.
I had to create a new Web Site. There was some invalid configuration in my Website level that referenced my application's virtual directory directly.
For example, https://server/app gives me the 404.17 error but https://server/app-test works successfully. Swapping the two application names (using appcmd) caused the working app-test (now renamed to app) to begin failing. After creating a new Web Site named MyApp Web Site I was able to again create a new app, this time named app that worked successfully.
After extensive review of Default Web Site we cannot identify what configuration is causing 404.17 for apps named app and not alternatively named apps like app-test.
I believe the ultimate cause of this, is I did not have .NET Extensibility Services and ASP.NET 4.5 added through the server roles and features—During installation. Thus, the installer of my app failed to successfully configure Default Web Site correctly. For example, the created app pool incorrectly installed with v2.0 Integrated and not v4.0 Integrated. After installing the required roles and features I verified ISAPI (64 bit v4) was configured correctly, and the App Pool was appropriately configured for v4 Integrated. Unfortunately, I cannot identify any additional settings that would cause this issue—especially explicitly targeting the app virtual path.
This solved the issue for me. +1 to all who spoke a reasonable solution without having to pass through a 3 ring circus.
Turn on IIS Windows Features like these
I know how to give service reference in Visual studio. Now I'm going to deploy the code in IIS server. there how to give Web reference (i.e Url of web service . Can any one help me.
In system 1 (Web application with web service) . system 2 (web application, web service has to fetched from system1). I can execute it in VS2008 because i can easily give service reference to system2 web application..
You don't need to add the reference again when deploying, but you may wish to change the address of the service, security information, quotas, timeouts, etc. All of this is configurable.
Web/service reference information is stored in .Net configuration files (e.g. app.config and web.config). When you deploy, you can change those values as needed to point to the correct location.
Example
Note the address attribute. This can be changed to the address where your endpoint resides.
<system.serviceModel>
<client>
<endpoint
address="http://localhost/SampleServer/PersonService.svc"
binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_PersonService"
contract="People.PersonService" name="BasicHttpBinding_PersonService" />
</client>
</system.serviceModel>
I am currently testing the following structure in IIS for my AppFabric Workflow Services and WCF Services:
/WebApp/ <-- IIS Application here
/WebApp/bin/ <-- binaries here
/WebApp/web.config <-- empty.
/WebApp/WorkflowApp/V1.0/web.config <-- Settings are stored here
/WebApp/WorkflowApp/V1.0/MyWorkflow.xamlx
/WebApp/WorkflowApp/V1.0/Default.aspx <-- just for testing
/WebApp/WcfService/V1.0/web.config <-- Settings are stored here
/WebApp/WcfService/V1.0/MyService.svc
/WebApp/WcfService/V1.0/Default.aspx <-- just for testing
My web.config contains the following section:
<appSettings>
<add key="TestSetting" value="Test Setting Value" />
</appSettings>
From one of my code activities in my workflow service, and from inside my WCF service, I want to read an item from "appSettings" using the following code:
var config = ConfigurationManager.AppSettings["TestSetting"];
This always returns null. I also tried WebConfigurationManager.AppSettings["TestSetting"], but this also returns null. It seems that the web.config hierarchy is not working for appSettings.
Just for testing, I added a Default.aspx with the following contents to see if this appSetting is accessible from an ASP.NET web page, and it works!
<html>
<body>
<h2>
TestWebApp
</h2>
<%= ConfigurationManager.AppSettings["TestSetting"] %>
</body>
</html>
It seems that the web.config in the sub-folder is not processed at all. Why doesn't the configuration scoping not work for AppFabric workflow/WCF services? And what can I do to make it work?
If I place the workflow/WCF service in the root of my web applicaiton in IIS, the appSettings section is accessible as expected. It is only when I place my workflow service in a sub-directory, the configuration sections are not accessible.
Update:
I have modified the question to generalize it to WCF and Workflow services, because it affects both cases. The reason I'm trying this, is to reduce the number of IIS applications and application pools.
According to the Windows Server AppFabric Architecture Guide:
Similarly to the application pool planning, we recommend that you logically group multiple services into a web application where it makes sense. AppFabric is designed to handle hundreds of web applications. However, for optimum performance and manageability, the goal should be to keep the number of web applications as small as practically possible.
From this text, it leads me to believe that having multiple WCF/Workflow services in sub-folders of web apps should work.
I believe the problem is that your workflow is not running on the ASP.NET thread but on it's own thread in the thread pool. As a result it doesn't really care about ASP.NET scoping rules but use the standard AppDomain config file.
I'm having a problem with deploing my solution to Windows Azure.
I've created a basic ASP.NET web role and tried to run that against my local DevFabric and everything is running perfectly. The ASP.NET site is reachable via a browser, I can see the valid results of executed code and everything is perfect.
Later on, I tried to deploy that to Windows Azure, the exactly same solution that I run against my local fabric and it was deployed successfully. Azure "told" me that the solution is ready (the green icon).
When I try to reach my service's url, I'm getting 10060 timeouts, as if the url is not reachable at all. This is for both, the staging and production environment.
I tried to look into the diagnostic logs, but there is nothing mentioned about any problems, moreover, the traces created by my application are written to the WADLogsTable, that indicates that the application is actualy running and it executed (at least some of) my code, but it's it's not reachable via the browser.
What is wrong with that, or what I'm doing wrong?
Service definition:
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="CloudServiceX" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="WebRole1">
<InputEndpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" />
</InputEndpoints>
<ConfigurationSettings>
</ConfigurationSettings>
</WebRole>
</ServiceDefinition>
Check for HTTP/HTTPS endpoint is enabled in your web role
I contacted the Azure team and they told me that they had network-related issues inside their data center.
Call the support and they should resolve the problem for 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.