I have a WCF server hosting clientaccesspolicy.xml (for Silverlight clients) and I was testing access to it using Internet Explorer. When I accessed it using http://localhost/clientaccesspolicy.xml everything worked correctly, but when I used http://machinename/clientaccesspolicy.xml it wasn't retrieved.
I downloaded, installed and ran Fiddler and now the http://machinename/clientaccesspolicy.xml URL works correctly - even without Fiddler running.
Obviously this isn't a scalable solution to the problem so I was wondering if anyone know what Fiddler might have done to fix my issue, or what might have been causing my issue in the first place? Windows Firewall has been disabled throughout my testing.
It turns out our testing systems have Privoxy installed on them incorrectly - it successfully blocked the connection attempts because they weren't whitelisted, but didn't display the error message it should be configured to do so. Fiddler replaced the proxy with its own settings temporarily and hence let it work. Thanks (and an upvote) to Ladislav for the hint.
Related
Upon calling a 3rd party SOAP endpoint i'm getting a 401 Unauthorised error - This is from my production server only. Works fine on every other machine I've tested on.
Production is running on Windows server 2008
I'm using the wsdl url to setup the request. I've noticed it seems to throw back the 401 so fast, that it doesn't seem to even be sending it to the remote machine. Is there perhaps some machine specific config that could be causing this?
I'm unsure of how to debug the situation as i can't replicate it on my local machine
There is no code i can think of that might help with this issue, since it is literally a single call of a SOAP wsdl
this.UseDefaultCredentials = true;
Placed the above manually inside the initialization of the class. From scouring the internet it seems occasionally windows server will use weird credentials and fail to bypass its own checks resulting in a 401 immediately.
Forcing useDefaultCredentials fixes this issue.
If I'm not running fiddler then my WCF throws exception : "Add service reference gives Exception": Unable to connect to remote server.
However, everything works fine while running fiddler. How to know what fiddler is doing and what change I should do accordingly in my WCF code to make it work without fiddler? Please suggest?
I'm trying to analyse this using WireShark.But, I'm new to this tool and finding difficulty.
Note: I found, there is a another server sitting between my client and the server from where I'm trying to get data.
if you run fiddler, it will change your proxy settings in the browser. That also can cause this issue.
check the proxy settings in IE.
I am working on WCF Client Server application , keeping both on separate machines.
I am a bit aware about DTC issues because of TransactionScope when we run cient and server on different machines, so I resolved it for different clients and server by doing follow.
Setting Security settings for DTC including Outbound settings in Client and Inbound on Server.
Keeping firewall totally turned off (For making my side safe for now)
All the clients and server are working properly except one machine.
I have checked,
1.Security settings
2.Firewall => Off
3.Same Guid issue
4.Restarting DTC
5.PingDTC (That I already tried and dnt want to use again coz not at all user-friendly tool)
every possibility I found from Google, but this machine only having error.
In both the case if I make it client or Server, it can not communicate with another machines, and rest all are ok with each other.
Can anybody please suggest me proper solution?
Troubleshooting MSDTC is quite a pain.
Is the problem machine the same operating system as all of the others? I have found that XP, Vista, 8, and Server 2012 don't work without putting in a registry key at:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC\ { RestrictRemoteClients, DWORD, 0 }
You will probably need to create the RPC key, it's normally not there by default.
Generally, even though DTCPing is quite an awkward tool to use, it has proven invaluable for me every time I have some unfathomable reason why MSDTC isn't working. If the above doesn't work, can you post the error messages you get from DTCPing?
I am trying to get the Remoting appender to work in log4net. I have implemented the method shown in these posts and I see the server object listening on the correct port, but I cannot get the client object to actually make the remoting connection. Client and server are both running on the same machine (my development box) so it should not be a firewall issue. I implemented the TimedRemotingAppender as show in the posts, and I can set a breakpoint on the LogEvents method, and see that it hits the breakpoint whenever I call log4net, but nothing ever appears at the server. I'm pretty sure I have the config files correct.
Any log4net gurus out there, is there a trick to getting this to work?
Thanks,
Peter
OK, I figured out that it is not really a log4net issue. I made a change elsewhere in my code, changing this line of code:
RemotingConfiguration.Configure(null, true);
To this:
RemotingConfiguration.Configure(null, false);
and data started flowing. I'm not sure what extra code I would have to write to get the "secure" version of remoting connections working, but any machine we would do this on is already behind the corporate firewall, so I may not have to fuss with security.
Thanks,
Peter
One of the services works fine but the other always throws a Socket Timeout 'forcibly closed' error.
I have portSharingEnabled='true' on both services and the netTcp Port Sharing windows service switched on.
I've done a lot of research on this but am unable to find the cause, any suggestions?
It's not an option to change the port either due to legacy system setup.
Each netTcp Binding looks liks this:
8033:*
Is that right or is the * the issue here? I've run out of ideas as you can tell.
Last point: It definitely isn't a timeout issue as I get the error on the client side instantly each time. All other binding config values are matched on both server/client side and set close to max as suggested by other similar issues here on SO.
Hard to tell for sure. To diagnose the issue further, for the service and the client I would enable WCF Tracing and see if there is an underlying exception. Here's a good blog article on how to create and read the log using the tools included with Visual Studio:
http://www.atulverma.com/2011/10/enable-wcf-tracinglogging-using.html