I have two solutions, one is the WCF service and the other one is the Silverlight.
I would like to use the debugger on both solutions at the same time. The debugger for the WCF service automatically starts a ASP.NET development server. However, I have a hard time making my Silverlight client connecting to the ASP.NET development server. The error says that I'm lacking of the client domain policy file.
Does anyone know where should I put the clientaccesspolicy.xml for the ASP.NET development server?
Thanks a lot!
clientaccesspolicy.xml needs to be in the root directory for the web server running the WCF service. In your case, this probably means the solution directory for the WCF application (if you're running the web server "in place").
You could also try using Fiddler or Firebug to determine exactly where the file is being requested.
Related
Is it possible to make HTTP calls to applications outside of Azure from a web API running in Azure?
I'm trying to connect a ASP.NET web API in Azure to a wpf application that runs on a PC at my company. Both the applications request data from each other using HTTP calls with JSON. This works fine locally because i can use localhost but
when running the web API in Azure the web API can't reach the wpf application
I have looked into Azure Point-to-Site and Site-to-Site connections but most examples that i found show connection with a VM in Azure and nothing about web API's.
Thanks in advance!
I still don't get your scenario even after reading all the comments, however here's a shot in the dark.
First of all, no, there are no restrictions as to what destination you may call from Azure, yes that includes the dark web, although not necessarily a recommended destination for both traffic and tourism alike.
For the second part, if what you're calling is behind a firewall and your API runs in Azure App Service, take a look at Hybrid Connections, it's built as a solution to that exact scenario, no IPsec or firewall rules are in play. The connectivity from on-prem will be outbound.
I have a WCF service hosted in IIS. My client is a Windows forms. I have provided service reference in my client application, so that it can generate server proxies (based on the service wsdl) and access methods exposed in my service. If I want to debug the server code, I can step into(F11) that server method from my client application. I understand that I am not actually debugging the server code, but I am stepping into the proxy generated by the client. I am confused that for some services, for debugging the server side code, it is often suggest to attach the debugger of client application to w3wp.exe. Why is this done, is there any reason for doing this?
Thanks
I have seen this before. I think that Visual Studio is smart enough to detect that the server code is hosted inside IIS, and it suggests that you attach to the application pool inside IIS, if you do this you can actually debug the WCF service code.
This is mainly suggested to ensure you are testing the latest service code.
if you are debugging the proxy, you have to make sure you update the proxy for every change made in it or you will still be looking at the old proxy while the actual service has changed and the reference is not updated.
if you attach a debugger to w3wp.exe, you will be hitting the current version of the WCF service code and not the version in your proxy.
creating my first webservice and need some assistance. i'm trying to create a web service to send data on a machine that doesn't have IIS. I have seen examples of this on msdn Host web service outside IIS.
My question so far is the address for the web server as the one in the example uses Http://localhost/WSEHostedWebService, i'm not sure what to use here as there is no web application or even IIS running on the intended machine. Should this point to a directory on the intended machine i.e. c:\webservice\myFirstService.asmx ?
To quote them "The following code example creates a Windows service named WindowsServiceToHostASMXWebService that hosts a Web service named Service at the soap.tcp://localhost/Service endpoint." - Try saying that fast with a mouth full of water :D
Anyhoo, unless you specifically need ye olde worlde asmx service do it in a WCF web service inside a windows service instead read this and this other link with example
As the link above says WCF handles the HTTP stuff outside of IIS anyhow.
I'm using a web service which works fine when I run it on my machine in an ASP.NET application using the default IIS Express VS 2010 comes with. However, when I move it to our server with IIS I get the error:
Error: There was no endpoint listening at 'web service name here' that could accept the message. This is often caused by an incorrect address or SOAP action.
'web service name here' is just a placeholder I put for this post. It has the right web service name.
So I pulled out the small login code that this is failing on into a console application and ran that from the IIS server and it worked! So I have to assume this is some kind of permissions issue with the IIS server on how it's running my web service code? In my ASP.NET program I have a separate DLL that handles the web service. The ASP.NET application fires off a separate thread that uses the DLL I made that uses the web service. Is it something to do with the separate thread permissions maybe? Any ideas?
Your first step when faced with this sort of issue is to search your config files for "web service name here" (or if this isn't actually the message you're getting the address given in the message). My suspicion is somewhere you'll have a WCF reference set up which needs a proper IP address.
Once you've got the address (assuming it looks valid) you need to check you can access it from the machine which is having the difficulties - it may be a firewall issue.
Now that you've established that your console application is connecting correctly from the same machine the next step is to check that both your IIS App Pool and Console application are running under the same user account/permissions. It may be that one identity has permission to access the network/internet and the other one doesn't.
Okay, I'm a very green developer (co-op student) so I'll try my best to make sense. Currently I have a web application (call it "Updater") that is an aspx and runs through IIS. My boss has asked my to look into creating a program (exe or command line) that can run the app through created encapsulated web server that can act like IIS. This is so that I can run the exe during an installer procedure on a client's machine so that the updater can configure the client's program.
So Far I've looked into sources upon sources on how to create a self hosted web server to handle a web app and I've managed to do the following:
-Create a command line server hosted at a given port #######.
-Use a StreamReader to read an html file
-Use HttpResponseMessage to set the Content to this html page.
Obviously this is very rudimentary, but I couldn't understand how to switch the app over to the server I created rather than the IIS.
Any help ont he matter would be appreciated, like I said I'm still quite new.
You can use OWIN to self host from within a console application.
Look for 'Self-Host OWIN in a Console Application' in the following link:
http://www.asp.net/aspnet/overview/owin-and-katana/getting-started-with-owin-and-katana
You need to start you self host server with the address your app is trying to contact. If your IIS is running with the default settings it should be http://localhost:80. Before you start the self host server you need to shut down your IIS website that is running on port 80. Two applications can not listen on the same port at the same time.
What you ask is a redistributable web server for ASP.NET. So, you might find interesting the UltiDev Web Server, formerly known as Cassini web server.
From their website:
UltiDev Web Server Pro (UWS) is an advanced, redistributable web server for Windows that can be use as a regular web server to host web sites and ASP.NET applications, or packaged with your ASP.NET web application and installed on your customers' systems along with your web app or site.