Programming Practice: Third-Party DLLs

[Glenn9999]

A question that's been rolling around in my mind. This is probably the best place I could think of to ask it, so here goes. How do people typically handle third-party DLLs and the expectation of them being on the machine?

Actual non-packaged apps are an easy thing (require installation, or package if the EULA allows), but the Microsoft stuff seems to be a lot more nebulous to me since it might or might not be packaged in the OS. For example, if you were to download a file, you can code your own easily enough but you can call the IE download file routine as well. Or if you needed to play a sound file, you could go to the known Windows routines or you could possibly call Windows Media Player (assuming the EULA fits and I'm not sure of that at all).

I guess I'm wondering more "best practices" regarding this matter than anything else.

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[ousoonerjoe]

I never assume the target system will contain the DLL in question.

For example, our shop places Outlook on every machine that goes out to the floor. Our Terminal Services users do not have Outlook installed and therefor do not have email. I always check to see if the component is there, then try to find a viable work around when it is not. When possible, adding the DLL to the setup and installing it then can be an option.

--------------------------------------------------
Stubbornness is a virtue -- if you are right. --Chuck Noll
--------------------------------------------------