ASP.NET: Multiple assembly versions, same web application

Question

Hello,

Hopefully you ASP.NET pros out there can answer this question. I have a single web application that contains a website and a web service - both have several assembly references in common (data access layer, utilities, etc) - however, recent changes made to the web service will require different versions of the common assemblies, versions that the website won't work with (in case you're wondering, the website is some legacy 1.x .NET code that explodes when using the newer version assemblies.)

Can anyone think of a way to allow my web service to reference one version and have my website reference another? I can obviously have only one version with the same name within the bin folder.

Thanks!

(P.S. - It just dawned on me that I could probably compile and reference the common assemblies with a different name, and place those in the web app's bin folder - but that sounds really fugly...)

Answer 1

Or you could separate the webservice into a new application independant of the website.

Answer 2

You can use the runtime part of the web.config to specify the dll to use (We have done it for SQLLite before):

 <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <qualifyAssembly partialName="System.Data.SQLite" fullName="System.Data.SQLite, Version=1.0.60.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139" />
    </assemblyBinding>
  </runtime>

Answer 3

I have a single web application that contains a website and a web service

That's your main problem there, you've released a partially functioning Application that relies on two different library code bases...

Even if you were to duplicate and re-reference your common assembly with a different name, you're still boned (pardon the phrase) re: Namespaces of all your classes inside that assembly.

I think you're best bet, would be to Pull the webservice out of your Web Application temporarily, and host them as two seperate app's until you can get your Common Lib's versioning issues sorted out.

Answer 4

I don't think compiling the newer set into an assmebly with a different name would work - .NET would still see the same namespace - so at best you'd have "Ambiguous Reference" or "Type x is already declared in dll y" errors, or at worst the framework would load the one relevant to the part of the app that was called first (website => 1.1, webservice => 2.0) and ignore the other one.

Your best bet would be to refactor the application in to two - web site and web service.

We've been doing this over the last couple of years with one of our clients - they have a huge site built on ASP.NET 1.1, but recent stand alone projects for them have started to move to 2.0 (3.5 under the hood, but obviously that's still hosted under 2.0) - we've basically had to port the common code to a new set of libraries built against 3.5, taking advantage of the new language features as we go, and we've moved those sections to new web sites (in IIS) as they are completed.

It's not ideal, yes we're then left with two copies of the codebase (1.1 and 2.0) and any fixes generally have to be rolled out in two places, but it seemed the best way to start moving them on.