At the end of the day we may be talking about a small percentage of file growth here. As far as DLL hell goes, that was somewhat my initial point to an extent, but a lot of the DLL quandaries have to do more with design more than anything. A few poorly designed COM libraries combined with two interdependent DLL's can easily lead to DLL hell.
I'd say it's a pretty huge growth. But it does avoid dll hell. However, VS's runtime also avoids dll hell because it uses side-to-side configuration. So there you have it - the runtime is safe.
Your own dlls is another matter, though, sadly.
Originally Posted by Adak
I assure you that you are perfectly capable of avoiding DLL by doing the following:
- If your program has dependencies, check them.
- If you can avoid using COM objects that need registering, do so.
- If you do any sort of update whatsoever, always unregister, then reregister COMs.
- Simply putting a get_version() or similar function in the library, and checking its return.
I would put avoid using .NET framework in the list, but seeing as that it will surely result in flaming, I won't. Really the main thing is the last point on my list. Naming them is a great idea, right? Wrong! Believe it or not, the above average user will think they can get rid of those nasty start-up errors by simply renaming the DLL to match whatever your program argues is "missing." Users are unpredictable. Never forget that.
I'm no fan of .NET either, but I'd rather use ways around the DLL hell than avoiding dlls. It's 2008 for dll's sake! There should be no more dll hell today, especially not if proper method to avoid it is used.
But now this is turning into a static vs dll topic :|
I think the pros and cons of both ways have been discussed already. For Visual Studio, it's safe to distribute runtime and use dynamic linking. This cannot be assured for other compilers / other dlls.
absolutely right 5001
i have done exactly that, many times, but can not remember how many times i could get it to work correctly.
i like one thing about .dlls that, if found in the same folder as .exe, then, the program runs just fine.
Not always. Read up on the dll hell link. Dlls are shared, even if they are apart. It still doesn't eliminate one dll hell situation.
it is literally dll-hell!!
i just hope that situation is improved now
now i figure why those silly errors would come up:
i had a program that would use some common msvc .dlls, but, i would put the needed dll with the program installer, that would put them in the same folder as the program. But. when the installer was run to uninstall my program, then, some times, it would report error (installer), saying that, one or more apps need to be closed, before uninstall could continue.
Well the upshot of Elysia's DLL method is that the user may already have that particulare DLL installed already. If not, you are doing some other program a favor by adding it to the user's system.
There are several ways to link the DLL, but that is a topic for another thread (since even though I am usually always up for writing long winded code for the sake of education, even I get tired at times). The msvc DLL's should be shipped with your program and installed into the system32 directory. You should first dynamically link to the existing DLL (which will additionally tell you if it doesn't even exist) and make sure you aren't overwriting their newer build with your older one.
If your code is likely not to be able to cope with a newer msvc DLL (which would be extremely unlikely) then you should keep your version of the DLL in your own directory. If you do this method there should be no complaints come deleting time.
Depends on how old the stomped applications are. My client's machines run applications -- written ten years ago with VC++ -- that won't even compile with Visual Studio 2005. Can't imagine if they were all dynamically linked and we plopped a new runtime on them.
These servers also run Java software that depends on Java 1.4.0. An axis library that one app uses breaks when you upgrade to 1.5 because the exception semantics of a library function changes, so we can't upgrade the VM (i.e. the runtime) for one application without break a seemingly unrelated application.
Sharing runtimes is a nice idea on paper, but when you have multiple applications whose lifetime spans several versions of said runtime, it can create huge problems if you try to upgrade.
Last edited by medievalelks; 05-09-2008 at 05:33 AM.
Newer versions of VS runtime will not run older versions of VS applications.
Plus VS6 or earlier already has appropriate DLLs installed with XP (as it ships with them).
