How to rearchitect a sloppily used dll.

Our team has inherited legacy code that includes a sloppily used dll.
"Sloppily" meaning it has shared code, but there is no pattern for how it is set up.
Example.  10 console applications reference the dll.  In today's world, if a new version of the dll is rolled out, every calling app should really be recompiled to bring in the new version of the dll.  But the changed portion of the code might affect only 2 of the 10 calling apps.

My goal here is to minimize those recompiles.

We don't have time for a complete rewrite.  So I listed options below.  Please let me know i there are other ideas you might have that could help us!  Thank you!!!
1.Keep using the same dll, but make it lives in a shared location.(that way, all calling programs are using the same dll)
2.Split the dll into multiple dlls
3.Clean up the dll.  Move specific functions of the dll into the calling program where applicable (like if only one program is calling a dll function, move that function into the calling program)
4.re-architect  the dll into a WCF Service.
ToolTimeGangAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

käµfm³d 👽Commented:
In today's world, if a new version of the dll is rolled out, every calling app should really be recompiled to bring in the new version of the dll.
That's not always true. This is why have versioned DLLs.

1.Keep using the same dll, but make it lives in a shared location.(that way, all calling programs are using the same dll)
If you're going to do that, then you probably want to put it into the GAC instead.

2.Split the dll into multiple dlls
Feasible, but now you've split the issue you are currently encountering into multiple instances of the issue you are currently encountering. Careful thought would be needed for this approach, I think.

3.Clean up the dll.  Move specific functions of the dll into the calling program where applicable (like if only one program is calling a dll function, move that function into the calling program)
Again, feasible, but you'd need to think carefully about this. Those functions were (probably) put into a shared library for a reason. Make sure you not breaking that reason.

4.re-architect  the dll into a WCF Service.
Service-oriented architecture (SOA) is a hot term right now. However, you still have the same kinds of versioning issues with web services that you do with DLLs. It's slightly less of an issue with REST-based services, but it's not non-existent.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ToolTimeGangAuthor Commented:
You make good points on all of them.  I will look more closely at the concept of "Versioned dlls" and adding the dll to the GAC.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic.NET

From novice to tech pro — start learning today.

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.