3

I've got an ASP.NET web site application targeting the .NET 4.0 Framework and the application exposes some web services using WSE 3.0 (Microsoft.Web.Services3.dll) for security. I'm getting a SoapHeaderException: SOAP header Security was not understood error when I consume the service. I have a very similar setup working OK when the application is targeting .NET 2.0 and I've compared the config files without identifying any differences.

Using Reflector I can see that Microsoft.Web.Services3.dll is referencing System.Web.Services, Version=2.0.0.0 but when I check the assembly binding using Fuslogvw.exe (Assembly Binding Log Viewer) I see Version redirect found in framework config: 2.0.0.0 redirected to 4.0.0.0. I've checked the various machine level config files and there is no explicit reference to a redirect so I'm fairly sure the redirect is due to a Microsoft Publisher Policy linked into the assemblies. I've tried to use the publisherPolicy Element to prevent this redirection using the config shown below but it does not seem to have any affect. I've also tried moving the publisherPolicy element outside the dependentAssembly element make it apply generally but that didn't help either.

Any ideas what I'm doing wrong or alternative ways to force the assembly bind to the specific version of the assembly?

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="System.Web.Services, Version=2.0.0.0" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
      <publisherPolicy apply="no" />
    </dependentAssembly>
  </assemblyBinding>
</runtime>
John Saunders
  • 160,644
  • 26
  • 247
  • 397
Martin Hollingsworth
  • 7,249
  • 7
  • 49
  • 51
  • Talk about heading down a rabbit hole! The problem was actually missing WSE / SOAP configuration as described in http://geeknotes.wordpress.com/2007/03/15/wse-30-hell-soap-header-security-was-not-understood/. I missed this initially when comparing the problem system with the working one as the configuration was in a separate sub directory web.config rather that in the root application web.config. Still curious whether it is possible to override the redirection of shared system assemblies though. – Martin Hollingsworth Nov 11 '10 at 21:45
  • Just have to comment on the fact that you're using an obsolete web service technology "for security". – John Saunders Nov 12 '10 at 21:08
  • I am well aware of that but it used by a CMS Product that we are working with so I have no control over it's use. – Martin Hollingsworth Nov 15 '10 at 21:31
  • Do you mean that the server to which your client connects uses WSE3? Because this doesn't mean you can't use WCF to connect to a WSE3 service. – LeonG Apr 01 '11 at 19:30
  • The "client" is a third party CMS system (an ASP.NET website) and is acting as a client using WSE3 to consume secure web services. The references to WSE3 are within the third party assemblies. Anyway, as I said in my comments, the problem I was having was due to missing configuration settings and after I added them the problem was resolved. The question is still up as a reference to real issue rather than the "rabbit hole" I went down. – Martin Hollingsworth Apr 04 '11 at 23:00

0 Answers0