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.
Related
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.
We have a continuous delivery process created using Jenkins, MSBuild, and Web Deploy. Things work beautifully when deploying to our development server, however, when I try to deploy a web deploy package using the *.deploy.cmd file on two newly configured servers the web.config changes defined in the parameters.xml file are not being applied. The rest of the deployment works great but I am seeing a message like this for every parameter that needs to change:
Verbose: Parameter entry 'config/1' could not be applied to '<path>\Package\PackageTmp\Web.config'. Deployment will continue with the original data. Details:
Cannot set a value on node type 'Element'.
Since the transforms for the exact same package work on deployments to one server and not to the new servers, this seems like a server configuration issue but I've gone through and checked everything against Microsoft's Web Deploy install instructions and it all looks fine. I wasn't the person who originally set up Web Deploy on the working folder so I don't know what they might have done differently. I suspect this is related to permissions but the few places I can think to check were the same on both servers.
I found other questions with this error message where it was an issue with the XPath in their parameters.xml file. I don't think this is my problem because I can deploy successfully to one of my servers but here's an example from my paramters.xml and SetParams.xml files for good measure:
parameters.xml
<parameter name="config">
<parameterEntry kind="XmlFile" scope="\\web.config$" match="//configuration/appSettings/add[#key='config']" />
</parameter>
*.SetParameters.xml
<parameters>
<setParameter name="config" value="<add key="config" value="testing" />" />
</parameters>
Does anyone know how to fix this or what kind of additional permissions I will need on my new servers?
In retrospect this is embarrassingly obvious but it turns out that our issue was that the server support team had installed the wrong version of Web Deploy. We needed 3.5 or higher and they installed 2.10. Updating Web Deploy on the new servers resolved the issue.
I've been trying to debug this ASP.NET cloud project over LAN, because we need it for testing at work. I have done plenty of research on the subject, but I simply cannot get it to work as expected. I think I have narrowed the problem down to being that, the project is a cloud service project.
If I create a new ASP.NET MVC project, without the cloud service, it works just fine, when editing the projects bindings, plus turning off the firewall of course. If I then do the same procedure, but with a cloud service project, with the asp.net mvc as the web role, I get "connection refused" when trying to access it over LAN.
Does anyone have any idea what's going on and/or how to solve it?
Bindings:
<bindings>
<binding protocol="http" bindingInformation="*:5807:localhost" />
<binding protocol="http" bindingInformation="*:5807:*" />
</bindings>
I spent almost a full day at work with exactly the same issue.
It finally started to work after I reïnstalled IIS express.
Uninstall at Programs and Features
Download the Microsoft Web Platform Installer found at link below:
http://www.microsoft.com/web/downloads/platform.aspx
search for IIS express, and install it.
After that, it worked like a charm for me. I hope it works for you as well, because I wasted way too much time on this problem...
I bought a new Windows 8 PC last week.
First I installed VS 2010 on it but then that wasn't working properly so I uninstalled VS 2010 and then installed VS 2012 professional edition and SQL Server 2012.
Now I am able to create Windows applications but I am not able to run even a simple ASP.Net website.
When I try to view Default.aspx in browser it throws an error message that
Unable to connect to the configured development web server
so then I went into Add or remove components and installed IIS. but I still get that error message.
Even if I try to save the website at a folder location, the ASP.Net development server is not able to run the web page.
I get the same error message using either IIS or ASP.Net development server.
I am wondering is it Windows 8 security related issue?
How can I make sure my ASP.net Development server was installed correctly and has the appropriate permissions to run?
Does ASP.net work with regular Windows 8? or do I need Windows 8 pro? Microsoft's website doesn't say anything about it so am assuming Windows 8 should work because the Windows forms application works.
Please advise. I just want to be able to run a simple ASP.Net application to verify the installation.
I tried http://forums.asp.net/t/1768992.aspx/1 but that didn't work in this case.
ASP.NET IIS Registration Tool (Aspnet_regiis.exe) would be one of my suggestions along with checking what identity is the Application Pool in IIS using as it may have limited permissions. Last but not least, run Visual Studio as an Administrator so you don't have UAC issues.
All right. I had this problem for a week and I have tried many solutions. Finally, the following procedure will fix the problem.
I have set the Firewall system manually. This means that, at the time of communication by programs Firewall notify me. Incorrectly linked to "devenv.exe" was blocked by the Firewall. Correct mode of communication "devenv.exe" will solve the problem. "devenv.exe" is located in the following path.
"C: \ Program Files (x86) \ Microsoft Visual Studio 12.0 \ Common7 \
IDE \ devenv.exe"
Devenv lets you set various options for the integrated development environment (IDE), and also build, debug, and deploy projects, from the command line.
Enjoy...
I've run into the same general error message that you stated, but the details of my error included the following:
Unable to connect to the configured development Web server.
Failed to register URL “http://10.10.7.209:53553/“ for site
“FooBarSite” application “/“. Error description: The format of the
specified network name is invalid. (0x800704be)
The fix for me was to make changes to the applicationhost.config file located in C:\Users\Jed\Documents\IISExpress\config
Specifically, I had to update the bindingInformation for the site so that the IP Address matched the IP Address of my development computer.
Instructions
Run ipconfig to determine the IP Address of your computer
Open C:\Users\Jed\Documents\IISExpress\config\applicationhost.config (in Notepad)
Scroll down to <sites>, then find the <site> that has the name of your project (in this example it was FooBarSite
Update the bindingInformation so the IP Address matches the IP Address that was determined in ipconfig
Example
<bindings>
<binding protocol="http" bindingInformation="*:53553:localhost" />
<binding protocol="http" bindingInformation="*:53553:10.10.7.209" />
<!-- I had to change the IP Address from 10.10.7.209 to 10.10.7.214 -->
</bindings>
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.