ASP.NET: multiple build versions, the same web application

I hope you ASP.NET developers can answer this question. I have one web application containing a website and a web service. They have several common assembly references (data access level, utilities, etc.). However, the latest changes to the web service will require different versions of the general assemblies, versions that the site will not work with (in case you are interested, there is some old 1.x.NET code on the website that explodes when using new build versions.)

Can anyone think of how to allow my web service to link to one version and have a link to my site? Perhaps I only have one version with the same name in the bin folder.

Thanks!

(PS - It just dawned on me that I could compile and reference common assemblies with a different name and put them in the bin web application folder , but that sounds really awkward ...)

+4
source share
4 answers

Or you can split the web service into a new website independent application.

+1
source

You can use the web.config runtime to indicate the DLL to use (we already did this for SQLLite):

<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> 
+1
source

I have one web application containing a website and a web service

In your main problem, you have released a partially functioning application based on two different library code bases ...

Even if you have to duplicate and re-reference your common assembly with a different name, you still remain alone (skip the phrase) re: Namespaces of all your classes inside this assembly.

I think that it would be best for you to temporarily withdraw the web service from your web application and place them as two separate applications until you can solve the version problems for the version of Common Lib.

+1
source

I don’t think compiling a new set in assmebly with a different name will work - .NET will still see the same namespace - so at best you will have an "Ambiguous reference" or "Type x is already declared in dll y" , or, in the worst case, the structure will load the one that refers to that part of the application that was called first (website => 1.1, webservice => 2.0) and ignore the other.

It would be best to reorganize the application into two websites and a web service.

We have done this over the past couple of years with one of our clients - they have a huge site built on ASP.NET 1.1, but the latest stand-alone projects for them have started moving to 2.0 (3.5 under but, obviously, it is still hosted under 2.0) β€œWe basically had to port the common code to a new set of libraries built on 3.5, taking advantage of the new language features as we go, and we moved these sections to new websites (in IIS) as they were completed.

This is not ideal, yes, we are left with two copies of the code base (1.1 and 2.0), and any corrections, as a rule, should be deployed in two places, but this is the best way to start moving them.

0
source

All Articles