Accessing WCF from Excel/VBA
-
I'm accessing WCF via Excel VBA using WCF Service Moniker[^]. Despite issues with https, non-intrinsic types (enum, Dictionary)...etc which all resolved (well, *avoided* by not using these, not resolved), I still face one obstacle - while invoking operations and sending to WCF interface with data of appreciable length OK (by setting Binding.ReaderQuotas.MaxStringContentLength to a big number on server side), unfortunately: retrieving data > 8192 characters from WCF interface seems like a show stopper. You can't configure proxy on Excel/VBA side to override ReaderQuota. "The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader..." It appears to properly consume WCF from Excel/VBA, you'd need do this thru calling dotnet dll from Excel/VBA[^]. But even this strategy is unproven... for example, your dll not going to have config where you can specify endpoint ReaderQuota overrides. There's a little article on this though[^] I Googled around no joy. Any help/suggestion? Thanks!
dev
-
I'm accessing WCF via Excel VBA using WCF Service Moniker[^]. Despite issues with https, non-intrinsic types (enum, Dictionary)...etc which all resolved (well, *avoided* by not using these, not resolved), I still face one obstacle - while invoking operations and sending to WCF interface with data of appreciable length OK (by setting Binding.ReaderQuotas.MaxStringContentLength to a big number on server side), unfortunately: retrieving data > 8192 characters from WCF interface seems like a show stopper. You can't configure proxy on Excel/VBA side to override ReaderQuota. "The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader..." It appears to properly consume WCF from Excel/VBA, you'd need do this thru calling dotnet dll from Excel/VBA[^]. But even this strategy is unproven... for example, your dll not going to have config where you can specify endpoint ReaderQuota overrides. There's a little article on this though[^] I Googled around no joy. Any help/suggestion? Thanks!
dev
-
I'm accessing WCF via Excel VBA using WCF Service Moniker[^]. Despite issues with https, non-intrinsic types (enum, Dictionary)...etc which all resolved (well, *avoided* by not using these, not resolved), I still face one obstacle - while invoking operations and sending to WCF interface with data of appreciable length OK (by setting Binding.ReaderQuotas.MaxStringContentLength to a big number on server side), unfortunately: retrieving data > 8192 characters from WCF interface seems like a show stopper. You can't configure proxy on Excel/VBA side to override ReaderQuota. "The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader..." It appears to properly consume WCF from Excel/VBA, you'd need do this thru calling dotnet dll from Excel/VBA[^]. But even this strategy is unproven... for example, your dll not going to have config where you can specify endpoint ReaderQuota overrides. There's a little article on this though[^] I Googled around no joy. Any help/suggestion? Thanks!
dev
We found VBA to be completely impractical, so much so that the team moved to VSTO, lost a major resource and put development back 2-3 months. It sounds like you got further down the line than we did :( . The whole construct became too fragile and required too much support. And getting VBA resources is almost impossible.
Never underestimate the power of human stupidity RAH
-
We found VBA to be completely impractical, so much so that the team moved to VSTO, lost a major resource and put development back 2-3 months. It sounds like you got further down the line than we did :( . The whole construct became too fragile and required too much support. And getting VBA resources is almost impossible.
Never underestimate the power of human stupidity RAH
-
:sigh: I know.
Never underestimate the power of human stupidity RAH
-
:sigh: I know.
Never underestimate the power of human stupidity RAH