Advise needed: Asp.Net app architecture (centralising assemblies)

Hello all,

I'd really appreciate any advice from anyone experienced in the field of online application architecture (with Asp.Net apps) as Im a bit stumped on which way to go...

First, some background: We've developed an Asp.Net application that serves many clients. When a client purchases the application, they get their own website set-up with bespoke files (their own web.config, master pages, css etc). In an attempt to centralize this application, we have a directory of shared files 'CoreCode'. Each client website gets a virtual directory that will point to this shared folder.

Our method works well for centralizing the UI layer. The problem is in centralising the business logic layer for our application (app.BLL), which is contained in a separate project. We are constantly developing this application, adding new features and fixing bugs. At the moment, every time we make updates the BLL, we have to manually copy the .dll assembly file to the bin directory of every clients website, we 40+ clients so far and we make updates every week, as you can imagine, this is getting annoying. It has to be done of course because the shared CoreCode files often access the new updates to the BLL.

I need to figure out a better way of doing this, the problem Im having is that none of my options seem very viable...

The obvious solution, which Im sure youre thinking of now, is to put the BLL assembly in the GAC. There are some initial problems here in that the BLL references third party assemblies that are not strongly named so I get an error when I try and add the BLL to the GAC. I could probably get round this one though. The other problem is that Ill have to add a strongly named reference (with version) in the web.config of every client website, so wont that mean that every week when we update the BLL, Ill have to go through every web.config and update that reference?

Another solution would be to somehow have a shared bin folder (via a symbolic link of something). What are the ramifications of doing this? I can imagine wed end up with a pretty huge bin folder somewhere... Is this even possible?

Failing the above, my backup plan is to write a windows app to physically replace the assembly in all the bin files. Id really like to avoid this if at all possible.
Can anyone offer any advice on which route to take here? Any help will be greatly appreciated.



Who is Participating?
senior_internetConnect With a Mentor Author Commented:
I actually solved this by creating a NTFS junction in each app that points to a central folder and used assembliy probing to point the CLR to them.

Full description here:

I think the best way to do this is to expose your business logic through a webservice or services.  This will resolve your issues as you clients will have a reference to the webservice or services and any update to the BLL will only be published to the webservices folder. which will automatically be available to the clients.

Hope that this helps

senior_internetAuthor Commented:

Thanks for your reply. That's certainly worth considering, the only problem there is that it would require a huge amount of redevelopment :-/. My knowledge of web services are a rekatively weak, would there be a performance hit with the site having to make calls to a service rather than an assembly? Performance is quite a high priority for us.

Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

A couple of years back I worked for an onlinegaming company and all of our business logic was exposed through webservices.  We are talking here anythign from 5000 to 60 000 or more concurrent users worldwide and we got very good performance.  Your redevelopment should not be excessive if your business object are loosely coupled to your application. All you would have to do is to expose your public methods in your BLL through a webservice and a facade with exactly the same method names, then you only have to add a web refrence and a facade to call the webmethods to your web app and everything should still be functional.  You might have to refactor your using statements though.
What you need to do is to create a webservice that exposes all the public methods in your BLL via webmethods. ie if you have a public method in your business method with the following signature

public object DoSomething(string makeAnObject) {...}
then you would have the following in your webservice

[WebMethod(Description="I make an Object")]
public object DoSomething(string makeAnObject){...}

in the facade you have a public method
public object DoSomething(string makeAnObject) {call webmethod DoSomething("Car") deserialize and return the object}

you only requirement is that when you wish to return objects from the webmethod then they need to be serializable so that you can do Serialization and Deserialization as required.

senior_internetAuthor Commented:

Thanks for your help. In the end I had to find another solution as exposing the BLL methods as services would have taken too much time, resources and testing (the project in question wasn't developed using TDD).


Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.