Troubleshooting Print Digit errors

[SteveBurdette1]

I've used the 3.18 version of the Javascript API Print digit successfully with my local print service in some of the newer web applications that I've written.  In one legacy application that I'm upgrading to version 3.18 the Print digit successfully prints the base layer but fails to print any of the ArcGISDynamicMapServiceLayer layers that are contained in the map.  I've compared the way that I'm creating/adding the ArcGISDynamicMapServiceLayer to this legacy application, and all of the layer objects look similar to my other applications when I inspect them at runtime.  

My question is this:  what are some specific attributes that I should be looking for in the ArcGISDynamicMapServiceLayers at runtime in order to get to the bottom of this?  I have spent much time comparing what the map objects (between my newer apps and this legacy app) look like at runtime and am not seeing any differences. 

[RobertScheitlin__GISP]

Steve,

  Does your ArcGIS Server logs provide any clue?

[SteveBurdette1 · Accepted solution]

The logs really didn't give me any clues...I set the message level to "Info" but never saw any log messages when printing.  After more testing I discovered the issue in this legacy app: I'm defining my layer URLs with our mapProxy.ashx included ("/mapProxy.ashx?url=EsriMapServiceUrl"), which is fine for displaying the data on the map but is causing issues when the printing service is trying to print the layer.  If I remove the proxy from the URL when I'm creating the ArcGISDynamicMapServiceLayer then the printing service is able to print the dynamic map layers, but if the proxy is included the printing service is unable to print the dynamic layers.  

I can resolve this by fully qualifying the address of the URL ("MyWebApp.MyDomain/mapProxy" instead of "/mapProxy.ashx"), but do you have any other suggestions or common workarounds for this?  I'd rather not have to fully qualify all of my paths for ease of testing between local/server environments.  

[RobertScheitlin__GISP]

Steve,

   So I do not know of a workaround for that scenario.

[SteveBurdette1]

No worries.  Thank you for your responses.  For now I'll go without the proxy.