I believe the big problem arises if your computer swaps out the code.
There are some complicated rules involved, but in "The Cliff's Notes Version", your computer will swap out memory when it starts running low on RAM, and will move things from RAM to the pagefile. Then when you need to access that data again, the computer will reload it from the pagefile into RAM so it can be used.
For programs, it's a bit different. The OS can still swap out program code, but it doesn't move it to the pagefile. Instead, it gets swapped out to its original location. It's almost like the OS "forgets" the code, and then reloads it again the next time it needs to run it.
The problem arises when you load a DLL from a remote computer, then the connection gets interrupted. This can cause C3D to crash if it has swapped out your DLL, and tries to swap it back in. It may not be a big deal when running a DLL from your local server, since chances of the connection getting broken are much lower when a local server on a local intranet is involved. A web server is a different story.
There is also the fact that you have to relax security permissions in order to allow the DLL to run from the remote location, which opens a potential security hole in your network. That may not be palatable for your remote users.
If the security of your code is important, then the best bet might be to put all the critical code in the server side of your client-server app, and let your customers have a light-weight client side interface that relies on your server for all the fancy stuff.
Take all of this with a grain of salt, however. It's actually pretty hard to make firm recommendations about what course of action to follow, since I have very limited (almost non-existent) knowledge of precisely what you're doing.