3

I'm working on a WCF service. The WCF service interface and implementation are in separate projects. There's also a Windows service project to host the WCF service.

One of the things the WCF service implementation needs to do is call out to several external (SOAP) web services. The way we typically structure this is we create a separate class library project for the SOAP service(s); we'll create a Web reference and a factory/helper method in the class library.

The above detail may or may not be pertinent to the real problem. Which is that I get an error when building the WCF service implementation project (where X is one of the SOAP service wrapper assemblies):

referenced assembly 'X' does not have a strong name

But the WCF service implementation project isn't set to be signed (nor is the interface project). And at this point the only two things referencing it are the Windows service project and a unit test project -- and neither of those is signed either.

The WCF implementation also references other (pre-existing) web service wrapper projects, but it's only complaining about these two. I've pulled up an existing and a new project file in a text editor side by side... And I can's see any significant differences.

I've also checked whether any of the projects is importing a setting that requires it to be signed, as described in Stack Overflow question Remove signing from an assembly. That doesn't appear to be the case.

I was attempting to use AutoMapper -- 1.1 since we're still on .NET 3.5 -- in my WCF implementation. That is a signed assembly, so I can see where it might have a problem reflecting on my code and the SOAP service wrappers. But it seems to me that would be a run-time problem, not build time. But because I suspected it might be at least a contributing factor, I removed AutoMapper and the dependent code but I still get the same error.

I have researched the issue, most of the search results consist of instructions on how to sign (possibly third-party) assemblies.

I've tried removing and re-adding the references, restarted Visual Studio and my PC.

Visual Studio 2010 / .NET 3.5 on Windows 7 64-bit.

I'm sure I'm missing something fairly obvious ... I just can't figure out what.

Community
  • 1
  • 1
David
  • 2,226
  • 32
  • 39
  • You'll need to post the trace you get out of running Fuslogvw.exe for the failed bind. – Hans Passant Jul 20 '13 at 18:26
  • Can you clarify when exactly it complains about the 2 webservices not being strongly signed? When compiling the WCF? or when compiling the webservices? Or when a call is being made? – Basic Jul 21 '13 at 00:10
  • @Basic - when compiling the WCF service implementation project (which references the SOAP web service wrappers). – David Jul 21 '13 at 17:02
  • @Hans = thanks for the response, I was not aware of fuslogvw. However mine is a build-time not run-time issue. – David Jul 21 '13 at 17:15
  • That increases the odds that the wrong assembly will be found. You still use Fuslogvw. You really need to do the legwork to get an answer, remote debugging by us isn't going to work. – Hans Passant Jul 21 '13 at 17:24
  • @Hans I'm not sure I understand how that increases the chances of the wrong assembly being found. Could you explain please (or point me to an explanation)? – David Jul 21 '13 at 18:19
  • I'm not sure how @HansPassant thinks you should use fuslogvw (although he knows his stuff so he's probably right). Failing that, any chance you can provide a minimal test case - 2 projects referencing each other which demonstrate the problem? Also, details of which version of VS, etc. you're using – Basic Jul 21 '13 at 20:41
  • @Basic - I've updated my question with the platform info. Meant to put that in initially :( – David Jul 22 '13 at 12:32
  • I will work on putting together a test case - unfortunately my employer is somewhat paranoid about disclosure (or lack thereof), so I'm going to have to do some scrubbing. – David Jul 22 '13 at 12:34

2 Answers2

1

Well ... this is embarrassing.

As I suspected, it was something simple. The service interface and implementation were in fact set to be signed; I was incorrect about that. However, this was done not in the project settings/file, but in the AssemblyInfo.cs file, via the directive [assembly: AssemblyKeyFile("keyfile.snk")].

I was not familiar with this method of signing. I gather it's been deprecated since VS2005 -- partially because it's more straightforward to manage signing via the project properties, partially because putting this information into the AssemblyInfo is considered a security risk.

And I had in fact looked at at least one of the AssemblyInfo files ... but apparently I didn't scroll down far enough. (I said it was embarrassing.)

Hopefully someone else can benefit from this.

David
  • 2,226
  • 32
  • 39
0

You can not reference an unsigned assembly from a signed assembly, the project which fails to build should be the one that has a strong name key tied to it.

It is possible that you have a signed version of one of your references in the Global Assembly Cache that MSBuild is picking up instead of the reference you selected.

Joe Caffeine
  • 868
  • 5
  • 10