I have zero knowledge on flex and need help to determine what is preventing my web service from being called.
We have a working application in production and the developer who wrote it has left.
I am trying to build it on my machine and I can see a web service call in fiddler being made with the URL "/Services.asmx/MethodName" (as a GET request).
I have set my break point in the asmx web service and it is not being hit. All I get in the flex front end is a pop up with " The remote server failed to respond and may be offline. http://MachineName/Services.asmx/MethodName"
The web service is in the same application as the web app that hosts the SWF file.
I have the cross domain policy file in place.
What I noticed in fiddler is the URL is "/Services.asmx/MethodName" and not "/WebApp/Services.asmx/MethodName" (not sure if this makes a difference) where WebApp is the IIS virtual directory to the web application that hosts the SWF.
Any ideas?
JD
If you are Web-services and your web-application is same domain then just pass the whole path like "http://..../Services.asmx" for creating web-service api instance in ActionScript 3.0 (for flex). and use this instance name to call your web-service method.
Please read this article from Adobe help for your perfect answer
Related
In general, if a third service provider manages the web server for me then it is hosted, while if I am by myself managing the web server then it is self-hosting.
In ASP.NET Core, In both places, I am the one who publishes the code on the server, at the time of IIS it is not called self-hosting? what exactly does "self" means?
For me as a programmer, self-hosting means the application should be able to host itself, which means it must be able to listen to the web requests directly or it must run on its own process. Am I wrong? Please someone help me to understand the meaning of "self" in self-hosting.
Also, the image Microsoft uses to explain self-host is very confusing to me, as far as I know, IIS uses w3wp.exe to execute the application as:
The above image is good, w3wp is the process within that our app executes and IIS is the overall container.
But now, look at this image:
Here the application is the wrapper and Kestrel is within the application and the process (dotnet.exe / application.exe) is the wrapper containing Kestrel, why is it so?
For me, it should be
Why is my image different from Microsoft's image for self-hosting? Where am I missing the concept?
I think that you need to extend the concept:
Hosted is essentially an application (web app) exposed via a third party service that run a server (web server) for you.
Self hosted is the same application exposed via a server managed by you.
Sometimes, as correctly mention by Vineet, self hosted stands for an application with a server process exposing the application itself. Like Kestrel for Blazor.
IIS is not the discriminant for hosted or self-hosted, is just the base of the concept.
From my point of view when I use IIS Express integrated in Visual Studio debug, the application is self hosted and hosted at the same time.
Is hosted in IIS Express from a web server perspective and, at the same time, is self hosted from a service perspective.
Just for information: the applicationName.exe produced by the compiler for Blazor app is just a launcher based on Kestrel. Is a web server that launch the applicationname.dll
An example below from two total different application. The executable (you can open it with a binary editor) is the same.
I have an application that is built using ASP.NET, with an embedded Silverlight Object that communicates with a WCF back end. It is set up like so:
Server 1: Hosts ASP.NET Website on IIS7
Server 2: Hosts WCF Application on IIS7
My Machine will try to access Server 1 over the internet to log in to the website. Server 1 will the authenticate the user using the WCF Web Service over our internal network on Server 2. I can do this but when it loads the silverlight object it crashes, complaining about CrossDomain/ClientAccessPolicy failure. So to be sure I put those two files on every folder in the inetpub/wwwroot on both Server 1 and 2, just to be sure. But I am still getting the same error.
When I run the application from Server 1, it can connect to the site through its local network IP and it all works, it also works when I run the ASP.NET application from Visual Studio 2010 on my own machine, with the web service references pointing to Server 2.
I am almost at my wits end, there have been so many red herrings that I have tried and none have worked. I am not even sure if it is Silverlight/WCF or the IIS configuration on each server that is breaking it.
If anyone can help me shed some light on this I would greatly appreciate it.
Thanks,
Stuart.
one idea could be to use fiddler and find the request which is making crossdomainpolicy xml request. Is that failing? Check the address it is pointing to. I debugged my issue using that. It was pointing to root of the server and my crossdomainpolicy xml was in WCF project folder.
I found the issue to my problem. I was not realising that the Silverlight application was trying to access a web service that was restricted by firewalls, so I had to create another web service that would re-route through the website and to the original web service.
What a bloomin' pain!
I have a similar problem to the one described here and I found the answer here to be helpful but I have a few more questions.
I've setup my project using Flash Builder 4 and imported my WSDL using the web service wizard making sure I pointed to the WSDL on the proxy. However simply doing that and enabling the "ProxyPreserveHost" directive did not allow the web services to run from the application being run on the proxy server. They just hang with no error or response.
So in addition to this I added this line of code to the service class that the Flash Builder wizard created:
_serviceControl.endpointURI = "https://site.mycompany.com/MyService/MyService";
This fixed the problem but I'm not sure as to why this is a problem in the first place. The location in the WSDL is specified to be http://site.mycompany.com:80/MyService/MyService and the server should be processing that request and converting it to https.
Anyone have any ideas or examples of how to get a Flex app built in Flash Builder working with a reverse proxy in place?
Thanks!
I've got a flex app that hits a remote SOAP service and populates a list with the results.
It works fine when i run it through flex builder, but when i compile the application and move it onto a webserver it can't access the services.
I've tried it from a standalone webserver and on my own machine. I'm assuming that there's a security issue that i've missed as i can't think of any other reason why it's ok in flex builder but not when compiled on the same box.
Thanks all.
Is it a crossdomain.xml issue?
The web server running the SOAP service needs crossdomain.xml file to allow your flash movie to access it. See http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
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?