I am using VS2010 + C# + .Net 4.0 + IIS 7.0 + WCF. When I create a WCF client object instance in below code, I find "check point 1" is logged, but "check point 2" is not logged. But no exception is thrown (I catch exception in the whole block of code, and "check point 3" is not output).
Any ideas how to debug further to see issues in WCF client proxy creation? What are the normal issues in WCF client proxy creation (I think the creation just need to create a local memory object to represent the WCF client object instance, no need to really communicate to remote WCF service, so should not fail normally, please correct me if I am wrong)? Maybe some configuration errors?
BtW: the code below is in a WCF service (WCF server end, running/hosted in IIS 7.0) to call another remote WCF service.
try
{
MyLogger.Write("check point 1 " );
Foo.CustomerInfo ci = new Foo.CustomerInfo();
MyLogger.Write("check point 2");
}
catch (Exception ex)
{
MyLogger.Write("check point 3");
return;
}
thanks in advance,
George
Few ideas:
Try putting logging in Foo.CustomerInfo() constructor
Try using end to end tracing with Service Trace Viewer (usually in NETFX 4.0 Tools\SvcTraceViewer.exe).
Make sure you have you service return exception details in faults so client can "see" them (e.g. serviceDebug includeExceptionDetailInFaults="true")
If you autogenerated client proxy, you can still edit it and add logging in the partial class of client proxy
Related
We have a WCF service hosted as nettcp mode and WCF client library, both services and client has been created using .net framework.
Now we are creating new application using Asp.net core 2.1, still here we need to consume the above created WCF Service using the same old WCF client Library.
Added this WCFClient library reference(.net framework) into our Asp.net core application. Here am using the below proxy constructor to pass my end point details.
public LoggingServiceProxy(Binding binding, EndpointAddress remoteAddress)
: base(binding, remoteAddress)
new LoggingServiceProxy(new EndpointAddress("net.tcp://localhost:9100/LoggingService/Tcp"), new NetTcpBinding(SecurityMode.None));
After adding System.ServiceModel.NetTcp and System.ServiceModel.Primitives NUGET references, resolved all other errors. But code thread aborted abruptly when it executes the proxy code
((ICommunicationObject)this.channel).Open();
No more information, debug message available after this point. No exception raised.So we have no clue on what is it?
Note: When I stop my service to test, I clearly get exception "EndPointNotFound".
Expected behaviour is to able to consume the service from Asp.net Core application -> WCF Client Library(.net framework) -> WCF Service nettcp (.net framework)
After did more dig into the auto generated proxy code, found that this issue is happening in the event of InnerChannel_Opened() and InnerChannel_Closed()
Above event got the following line of code "lock (this.channelLock)" which causes the issue. No exception raised. simply thread aborted/exited. When comment it out these events, it works fine, but am not too sure whether it is ok to comment these auto generated code.
lock (this.channelLock)
{
if (this.IsDisposed)
{
throw new InvalidOperationException("Cannot use disposed object.");
}
if (this.Opened != null)
{
this.Opened(sender, e);
}
}
First, I created a WCF service (netTcpBinding) hosted by a server application and all work fine (tested with a client application).
Then, I imported the same service class in a prism module (IModule). In the module, I create an instance of the ServiceHost by using the service class type:
public ServiceHost Host = new ServiceHost(typeof(MyService));
In the initialization step, I open the connection:
try
{
host.Open();
}
catch (Exception ex)
{
log.Error(ex, "SAP service starting is failed.");
throw;
}
When I attempt to connect with a client application to the WCF service, no error is occurred: Address, binding and contract are found in the configuration file, the instance of the ServiceHost is correctly created and gets the status "opened", the socket connection is opened. From the client application, I am able to perform a call to a method of the service (no error occured to the socket opened by the server) but the service doesn't receive the call: a break point at the top of the called method is not hit during a debug session of the WCF service.
When I add a service behavior (httpGetUrl and httpGetEnabled to true) in the configuration file to get the WSDL information, the link does NOT occur any error but the page stays blank and its title keeps as information "Loading ..." (no WSDL generated).
If I move the service class and the creation of the service host to the prism executable project (.exe) which initializes the modules, the WCF service works fine !
By adding the diagnostic tools in the configuration file of the service () and by calling the "test" method, I can see the last logs:
Any idea ?
Can we create a service host in a library project working like a prism module ? Is there any contraindications ?
I've found ! But nothing linked to prism or unity.
The application set an notify icon in the right bottom of the screen. This notify icon has a context menu to finish the application. The notify icon is associated to the thread of the application.
Later, I added TopShelf to start the service. It seems that the adding of the context menu occurs a problem. I have no exception but well the problem described above. The removing of the context menu solves the issue.
There is no contraindications to define a WCF service host in a prism module. That works perfectly.
I can use this program on my own computer, but I can not use on the server.
Server use supreme authority Administrator to open the program.
Server WCF HTTP Activation Feature with .NET4.5 is opening.
Server endpoint address use "http://localhost" like following
endpoint address="http://localhost" binding="basicHttpBinding" bindingConfiguration="NewBinding0" name="ProductService" contract="ProductService.IWCFProductService"
Wrong Message:
The communication object, System.ServiceModel.ServiceHost, cannot be used for communication because it is in the Faulted state.
Stack trace at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)
at System.ServiceModel.ServiceHostBase.System.IDisposable.Dispose()
at FileUtilityHelperService.Program.Main(String[] args)
This simply means that there has been an unexpected exception somewhere in your code. The error message "...because it is in the Faulted state" means that communication between the server and the client is unusable.
What you need is better error handeling.
Use try/catch around your code that can potentially generate an exception
Always order exeptions from the most specific to the least specific
You would probably like to log your errors to a file or database, log4net is great for this (and comes as a nuget package)
I have a WCF Service hosted and the client is hosted on the same server. I try to show some error message via a dialog box. its working as expected when i try to perform some action which throws that error in server but its showing Bad request when i try to work on Local machine.
Can't post the configuration file. Client machine So :) . Hosting is IIS
I found that in the controllers catch block where i am calling the wcf service whenever we are having an exception we are setting
Respose.StatusCode = (int)HttpStatusCode.BadRequest;
return Json(execption.Message);
Does this have anything to do ?
I added this setting in the web config and i am able to see the actual message in my local machine too
<httpErrors existingResponse="PassThrough" />
Is there any other way of doing it from coding part
All,
I have a WCF web service (let's called service "B") hosted under IIS using a service account (VM, Windows 2003 SP2). The service exposes an endpoint that use WSHttpBinding with the default values except for maxReceivedMessageSize, maxBufferPoolSize, maxBufferSize and some of the time outs that have been increased.
The web service has been load tested using Visual Studio Load Test framework with around 800 concurrent users and successfully passed all tests with no exceptions being thrown. The proxy in the unit test has been created from configuration.
There is a sharepoint application that use the Office Sharepoint Server Search service to call web services "A" and "B". The application will get data from service "A" to create a request that will be sent to service "B". The response coming from service "B" is indexed for search. The proxy is created programmatically using the ChannelFactory.
When service "A" takes less than 10 minutes, the calls to service "B" are successfull. But when service "A" takes more time (~20 minutes) the calls to service "B" throw the following exception:
Exception Message: An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail
Inner Exception Message: The message could not be processed. This is most likely because the action 'namespace/OperationName' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding.
The binding settings are the same, the time in both client server and web service server are synchronize with the Windows Time service, same time zone.
When i look at the server where web service "B" is hosted i can see the following security errors being logged:
Source: Security
Category: Logon/Logoff
Event ID: 537
User NT AUTHORITY\SYSTEM
Logon Failure:
Reason: An error occurred during logon
Logon Type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
Status code: 0xC000006D
Substatus code: 0xC0000133
After reading some of the blogs online, the Status code means STATUS_LOGON_FAILURE and the substatus code means STATUS_TIME_DIFFERENCE_AT_DC. but i already checked both server and client clocks and they are syncronized.
I also noticed that the security token seems to be cached somewhere in the client server because they have another process that calls the web service "B" using the same service account and successfully gets data the first time is called. Then they start the proccess to update the office sharepoint server search service indexes and it fails. Then if they called the first proccess again it will fail too.
Has anyone experienced this type of problems or have any ideas?
Regards,
--Damian
10 mins is the default receive timeout. If you have an idled proxy for more than 10mins, the security session of that proxy is aborted by the server. Enable logging and you will see this in the diagnostics log of the server. The error message you reported fits for this behavior.
Search your system diagnostic file for "SessionIdleManager". If you find it, the above is your problem.
Give it a whirl and set the establishSecurityContext="false" for the client and the server.
Don't call the service operation in a using statement. Instead use a pattern such as...
client = new ServiceClient("Ws<binding>")
try
{
client.Operation(x,y);
client.Close();
}
catch ()
{
client.Abort();
}
I don't understand why this works but I would guess that when the proxy goes out of scope in the using statement, Close isn't called. The service then waits until receiveTimeout (on the binding) has expired and then aborts the connection causing subsequent calls to fail.
What I believe is happening here is that your channel is timing out (as you suspect).
If I understand correctly, it is not the calls to service A that are timing out, but rather to service B, before you call your operation.
I'm guessing that you are creating your channel before you call service A, rather than just in time (i.e. before calling service B). You should create the channel (proxy, service client) just before you use it like:
AResponse aResp = null;
BResponse bResp = null;
using (ServiceAProxy proxyA = new ServiceAProxy())
{
aResp = proxyA.DoServiceAWork();
using (ServiceBProxy proxyB = new ServiceBProxy())
{
bResp = proxyB.DoOtherork(aResp);
}
}
return bResp;
I believe however, that once you get over that problem (service B timing out), you'll realize that the sharepoint app's proxy (that called service A) will timeout.
To solve that, you may wish to change your service model from a request-response, to a publish-subscribe model.
With long-running services, you'll want your sharepoint app to subscribe to service A, and have service A publish its results when it is ready to do so - regardless of how long it takes.
Programming WCF Services (O'Reilly) by Juval Lowey, has a great explanation, and IDesign (Juval's company) published a great set of coding standards for WCF, as well as the code for a great Publish-Subscribe Framework.
Hope this helps,
Assaf.
I actually triggered this error just now by doing something silly. I have a unit test that modifies the system date in order to test some time-based features. And I guess the apparent time difference between when I created the context and when I called my method (because of the changes to the system date), caused something to expire.