One of the biggest pains of .NET applications going against Exchange is getting detailed logs. Using a tracing tool like Fiddler is great since it will SSL decode traffic, however it won't capture traffic from a .NET application running on the same box unless that application can set its proxy settings to that of Fiddler. Having a client app modified to give the ability to set proxy settings is time consuming and often not possible. However, you don’t necessarily need to go through that given that a config file can be created in the same folder as the applications .NET executable and can be used to have the traffic logged to a file and even provide proxy setting defaults.
There are two fairly easy solutions:
1) Use an application config file to log off traffic to a file.
2) Use an application config file to force the application traffic to a proxy server – ie Fiddler.
The methods I'm describing only work for .NET applcations which are using .NET code to do the calls. There are some .NET applications which use non-.Net APIs to do calls, so these methods won't work for those applications. If the application sets an override for proxying then the .config file won’t work. However, if the application accounts for these settings then usually there is a way through the application to set them.
With .NET applications you can modify the application's application config file or its web.config so that you can have the traffic logged. See, .NET classes have default trace listeners built into them and you can flip them on and have their logging directed to a file. Doing this allows us to get logging for times where it would otherwise be difficult or not possible. You will want to NOT do this with machine.config as it will cause all applications on the system to log to the log file. Also watch out for web.configs which might be further down the sub folder paths as you could inappropriately override their settings. Every .NET application can have a .config file. With the exception of web apps which use web.config, a config file will start with the same name as the application’s executable name. So, bob.exe would have a config file of bob.config. If a config file already exists then you can splice in what you need – however, be very careful. If an application does not have a config file then you can just create one – also be careful as you can override its default settings and change its behavior in ways which may not be appropriate for the application. Note that when you modify a web.config that it will cause the application to reset. Further, you should ALWAYS make a backup copy of a config file before modifying it.
This example below will have the default listeners of several of the .NET namespaces log to the file called network.log. Be sure to set the .Net version. I advise doing research on the settings before usage as it may log more than you wish. Note that you should remove logging after you have resolved the problem since logging is accumulative and the log can easily grow dramatically. In between runs of a repro you should consider closing he application and deleting the log file so that you can easily find the start of the repro entries.
<trace autoflush="true" indentsize="4"/>
<add name="System.Net" value="Verbose"/>
<add name="System.Net.Sockets" value="Verbose"/>
<add name="System.Net.Cache" value="Verbose"/>
<add name="System.Net.HttpListener" value="Verbose"/>
<add name="System.Net" type="System.Diagnostics.TextWriterTraceListener" initializeData="C:\\traces\\network.log" traceOutputOptions = "DateTime" />
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
Alternatively can also set a default for the proxy address and port. If you set the proxy address and port to that of Fiddler (127.0.0.1 at port 8888) then you can have Fiddler do the tracing for you. This is possible because Fiddler is itself a proxy.
Consider the following for Fiddler:
<defaultProxy> Element (Network Settings)
Configure .NET Applications (This is on Fiddler’s site).