SP1 and the Oracle Adapter in BizTalk Adapter Pack 2.0
I experienced the following problem the other day when trying to configure a WCF-Oracle send port after installing SP1 for BizTalk 2006 R2. I believe the problem would show itself when using BizTalk Adapter Pack 1.0 as well, but I didn’t verify this.
Here’s a text version of the error:
—————————
WCF-Oracle Transport Properties
—————————
Error loading properties.
(System.MissingMethodException) Method not found: ‘System.Configuration.ConfigurationElement Microsoft.BizTalk.Adapter.Wcf.Converters.BindingFactory.CreateBindingConfigurationElement(System.String, System.String)’.
—————————
I know I’m not the first person to encounter this problem because I’ve seen a comment posted elsewhere, but I might be the first person to discuss it a little more in detail. The problem apparently affects not only WCF-Oracle send ports but also WCF-SQL. Viragg is correct in his comment that there was a breaking change done in Microsoft.BizTalk.Adapter.Wcf.Common.dll to the method BindingFactory.CreateBindingConfigurationElement with Sp1. As he mentions, the SP1 version it takes 3 parameters while the pre-SP1 version only takes 2 parameters.
So what should you do? Well, you can get away with just using the WCF-Custom adapter and using the appropriate binding type, e.g. oracleBinding or sqlBinding.
Admittedly, it’s kind of annoying that you have to do this, but it works. Where it would really be a pain is if you were upgrading a production environment and had to do this reconfiguration, which might require your change control process to be used, etc.
RSS Feed
Victor Fehlberg's Tech Postings 
Any one able to resolve this OR has reported to Microsoft?
Microsoft is aware of this issue. However, it is not clear to me if they are going to provide a fix or if they consider the WCF-Custom workaround to be sufficient. Anyone from Microsoft want to comment?
I have another finding on this Adapter.
When i send data to SQL and the send fails, it lock the databases until I reset the hosts……..
Using AmbientTransactions = False solves this but that is not really what I want.
Microsoft is messing stuff up… And althoug i was a believer taht BizTalk was a rock solid platform i am beginning to loose my faith……
I found that I had to set AmbientTransactions = False as well. I think I documented this somewhere else in one of my blog posts, but we also found some fundamental changes between the previous version and this latest version, causing a breaking change. I was pretty disappointed. In a few words the change had to do with setting xsi:nil=’true’. Things that worked in the old environment suddenly broke and using the skipNilNodes parameter alone didn’t fix it – there were actually code changes required.