I created a WCF service for logging using the enterprise library logging block. The service is working properly from an ASP.net website. Also the method is taking lists and primitive types as parameters so there should be no cross platform issues. So I place a reference of this service from visual studio into my silverlight project, which is mvvm by the way, and I make a call to the service. And nothing happens. No exception no logging nothing. At first I thought it was just an exception that was not propagating back to my service, so I placed a message immediately after my method's async call and that message ran fine. So I'm stumped. I also have a try catch block wrapping my service call and the catch block is never being called meaning an exception is not thrown.
This was my error I was getting an exception before the call and that was preventing my service from being hit.
Related
I have the unfortunate task of updating a WCF project to .NET Framework 4.8 and replacing the existing log4net exception handling with Microsoft Logging and Application Insights.
My approach was to implement Dependency Injection to make instantiation easier and because I am already used to that design approach with .NET Core. As you may know, WCF services adds its own complexity since WCF is responsible for instantiating the services and lower level objects (like custom customUserNamePasswordValidatorType). I was able to handle most of this by implementing a WCF Service Factory and updating the svc markup with it.
I have added Application Insights to the project via the appropriate NuGet packages which updates the web.config with appropriate httpModules for general exception handling. I was even able to add a custom TelemetryInitializer in Application_Start to include a few custom properties in the message.
My problem is getting an instance of ILogger<T> with the attached Application Insights provider into the instantiated service.
At first, I was getting an exception because of the parameterless constructor of Logger<T>. This was fixed by updating my WcfServiceFactory to the following
container
...
.RegisterType<ILoggerFactory, LoggerFactory>(TypeLifetime.Singleton)
.RegisterType(typeof(ILogger<>), typeof(Logger<>), TypeLifetime.Singleton);
This allowed an instance of the logger to be passed into the constructor of each service. However, calls to log messages are never written to App Insights and an inspection of the logger shows zero providers.
My guess is that because a new instance of LoggerFactory is being created, the already existing instance used in the httpModules is ignored.
According to https://github.com/unitycontainer/microsoft-logging, I need to refactor what I am doing and actually create an instance of a LoggerFactory and manually add the desired providers. My issue is that I cannot figure out how to do that with Application Insights. Everywhere else I used it, I would just call the AddApplicationInsights() extension method but that does not seem to be an option here (at least not with Unity).
So I guess my issue boils down to the following questions
Can I get the WcfServiceFactory to use the existing App Insights logging? Maybe establish something in Global.asx?
How can I manually register App Insights as a provider in the WcfServiceFactory including the custom telemetry?
No need to use ILogger if the intention is just to log a custom error. You can log exception on AppInsights directly using the telemetry client, like this:
var telemetryClient = new TelemetryClient(TelemetryConfiguration.Active);
telemetryClient.TrackException(new Exception("Logged random exception message."));
I've created a WCF service with a method GetTestValue. I've also created a test application to test this service.
When I add this WCF service with connected service to the test application I can only call GetTestValueAsync, there is no GetTestValue method. Somehow this add process add this async thing behind the method name. So in this test application, the WCF call works fine when I call GetTestValueAsync. I get the result back.
Then I've created a Xamarin cross application app where I added this WCF service too, and when I call the GetTestValueAsync from this application I get the following error:
Error in deserializing body of request message for operation 'GetTestValue'. OperationFormatter encountered an invalid Message body. Expected to find node type 'Element' with name 'GetTestValue' and namespace 'http://tempuri.org/'. Found node type 'Element' with name 'GetTestValueAsync' and namespace 'http://tempuri.org/'
Somehow strange in the test project it works fine, and in the Xamarin cross application not.
Did someone have the same problem?
Why is this connected service always this Async to my method name?
How can I stop this Async being added to the method name?
Thanks for any help.
At the moment Xamarin apps aren't compatible with the Task-based asynchronous WCF proxy methods that the WCF Web Service Reference connected service provider generates (bugzilla.xamarin.com Bug 51959).
One way to generate an older, compatible style of WCF proxy methods is to run SvcUtil.exe with the /async and /tcv:Version35 switches in a Developer Command Prompt. That will generate synchronous proxy methods, Begin/End style Asynchronous Programming Model (APM) callback proxy methods, and event-based proxy methods, all of which are compatible with Xamarin apps.
(Note: If you leave out the /async switch, SvcUtil.exe will generate the newer, incompatible Task-based proxy methods.)
Duplicate: By chance, I replied on a more recent duplicate of this question first:
How to use WCF services in .netstandard with Xamarin.Forms project?
I know this is old, but I had the same problem and searched a while. When you are adding the Reference in your project, you can check "generate synchronized operations" and the "Async"-suffix aren't generated anymore. My VS runs in german language, so I just translated the options. If your adding new methods the setting will be considered too.
Greetings from germany.
I mean if a wcf client makes a call to wcf method, and then if wcf generates an exception which is uncaught at wcf side,
then it is my understanding that this error/exception at wcf side breaks the channel established between client/wcf by wcf proxy object(only if uncaught at wcf side)?
Is that true?
If true,then if i want to use same proxy object again (which was used to call wcf method when exception occurred) to make another call to wcf, may be in catch block at client end (may be for retrial of last call), then is there any way i can use that
or need to create/use new new proxy object?
When throwing a FaultException from a WCF service, is there a way it can be thrown without faulting the actual connection? I'm looking to prevent an action for a particular method, but don't want to disrupt the client's connection (just return saying "you can't do this action right now, and here's why"). Or, is the required paradigm to recreate a new proxy in the .NET consuming app (in the case of .NET)
If you throw a FaultException then the client will get an exception but should be able to carry on using the same connection. If you let any other kind of exception out of the service (without having a Custom Error Handler in place) then it will fault the channel
Are you using .NET 4.0, can you use WebFaultException to return an HTTP status code with the appropriate error reason?
I am working on a prototype using WCF 4 routing services to create a pass through router, leveraging the error handling functionality
I have a requirement where if a WCF service generates a custom exception (in this scenario it is called a notPrimaryException), it should be handled in the same way as a communication exception is handled in WCF4 routing services error handling, that is, the message should be resent to the endpoints in the backup list.
Now I understand that this custom exception is returned from the service to the router as a fault exception at the message layer as opposed to a communication exception being returned at the transport layer.
I have tried using message inspectors and the IErrorHandler interface (ProvideFault and Handle Error) to identify if the notPrimaryException is occurring at the router but nothing is being picked up until it returns to the client as an unhandled fault exception. I was hoping to intercept this fault somewhere on the router and resend the message accordingly but I don't know if there are any appropriate behaviors.
Is there a way to shoehorn additional exception/fault types into the error handling infrastructure or is there another approach I may have overlooked?
Thanks and Regards,
Ivan
You should not be handling application errors on the router. Generally, the application developer has placed FaultExceptions on the service with the expectation of being able to handle them on the client.
If the FaultException is not received by the client, how does the client know what/anything went wrong?
The only errors you should be handling on the router are transport layer exceptions, application exceptions should be handled in the application.