Using Umbraco 4.9.0 and Courier 2.7.1 and automating revision transfer and extraction:
If there is an exception with the extraction (e.g. "access denied" when trying to overwrite a file) the exception is based back in the webservice response and read by System.XML.XMLReader (as part of the Umbraco.Courier.RepositoryProviders.WebServiceProvider.RepositoryWebservice.TransferResources method.)
Unfortunately the stack trace is also included along with the obfuscated courier method names. This causes an exception: "Response is not well-formed XML" in Courier.
This is because the obfuscated method names are using characters which are not valid in XML 1.0, i.e. control character 0x13.
This is frustrating for us as we can't see in our build server logs what the real failure is.
The way I see it this could be fixed in 1 of 2 ways:
Somehow get the xml response using XML v1.1 which allows these control characters (not sure if this is easy as it would depend whether you can tell System.Web.Services.Protocols.SoapHttpClientProtocol to read the response as XMl 1.1?) or
Just don't pass the stack trace (and therefore the obfuscated method names) back in the error response.
Got the issue reported some days ago (think it was you actually), and I did change the way the method names was obfuscated so it shouldnt break the soap response.
Problem with extraction exceptions not being passed back correctly
Using Umbraco 4.9.0 and Courier 2.7.1 and automating revision transfer and extraction:
If there is an exception with the extraction (e.g. "access denied" when trying to overwrite a file) the exception is based back in the webservice response and read by System.XML.XMLReader (as part of the Umbraco.Courier.RepositoryProviders.WebServiceProvider.RepositoryWebservice.TransferResources method.)
Unfortunately the stack trace is also included along with the obfuscated courier method names. This causes an exception: "Response is not well-formed XML" in Courier.
This is because the obfuscated method names are using characters which are not valid in XML 1.0, i.e. control character 0x13.
This is frustrating for us as we can't see in our build server logs what the real failure is.
The way I see it this could be fixed in 1 of 2 ways:
Hi Nick
Got the issue reported some days ago (think it was you actually), and I did change the way the method names was obfuscated so it shouldnt break the soap response.
The 2.7.3 RC has this change included
/per
You are super awesome Per - thanks loads!
(And yeah it was me reported it by email :) - I wasn't sure what was the best way to report this kinda stuff...)
#H5YR ;)
is working on a reply...