.Net development question
Discussion
Hi,
I'm developing a dll file to use in other projects which references other third party dll files. The question is is it possible to reference the third part dlls directly without adding them to the project? What i'm finging is that when i add my dll to a new project it doesn't work until i've added the third party dlls to the project also which is what i was trying to get away from.
Thanks in advance..
I'm developing a dll file to use in other projects which references other third party dll files. The question is is it possible to reference the third part dlls directly without adding them to the project? What i'm finging is that when i add my dll to a new project it doesn't work until i've added the third party dlls to the project also which is what i was trying to get away from.
Thanks in advance..
You will need to reference the third party dlls if you are calling code that is within them.
However, if you are looking at this from a deployment view, it is possible to compile all your assemblies into one physical dll, so that you don't have to distribute third party dlls (if that's what you're worried about)?
However, if you are looking at this from a deployment view, it is possible to compile all your assemblies into one physical dll, so that you don't have to distribute third party dlls (if that's what you're worried about)?
nekrum said:
Hi,
I'm developing a dll file to use in other projects which references other third party dll files. The question is is it possible to reference the third part dlls directly without adding them to the project? What i'm finging is that when i add my dll to a new project it doesn't work until i've added the third party dlls to the project also which is what i was trying to get away from.
Thanks in advance..
I'm developing a dll file to use in other projects which references other third party dll files. The question is is it possible to reference the third part dlls directly without adding them to the project? What i'm finging is that when i add my dll to a new project it doesn't work until i've added the third party dlls to the project also which is what i was trying to get away from.
Thanks in advance..
It does a lot of this kind of stuff so that you can get Intellisense, easily build deployment packages, and so on. You should be able to add an assembly reference to it regardless, but the question is why you want to get away from these 3rd party assemblies being referenced in the project?
I'm only guessing, but if he's writing some object that provides the capability for others to write plugins, in the form of a DLL with dynamic linkage.......
It's always a good thing if you can do this, because if you perform all of the necassary checks about what the plugin is doing, you can offer a stable and reliable environment for someone elses code, even if you didn't write it yourself.
As long as you have some scheme for dealing with calling conventions, they can even write their code in whatever language they want.
If you run their code on another thread or better in a separate process but in their DLL, then even if their code gnerates unhandled exceptions, you can still ensure that your top level object remains stable.
Seems pretty useful to me.
It's always a good thing if you can do this, because if you perform all of the necassary checks about what the plugin is doing, you can offer a stable and reliable environment for someone elses code, even if you didn't write it yourself.
As long as you have some scheme for dealing with calling conventions, they can even write their code in whatever language they want.
If you run their code on another thread or better in a separate process but in their DLL, then even if their code gnerates unhandled exceptions, you can still ensure that your top level object remains stable.
Seems pretty useful to me.
Edited by dilbert on Wednesday 2nd May 21:35
dilbert said:
I'm only guessing, but if he's writing some object that provides the capability for others to write plugins, in the form of a DLL with dynamic linkage.......
It's always a good thing if you can do this, because if you perform all of the necassary checks about what the plugin is doing, you can offer a stable and reliable environment for someone elses code, even if you didn't write it yourself.
As long as you have some scheme for dealing with calling conventions, they can even write their code in whatever language they want.
If you run their code on another thread or better in a separate process but in their DLL, then even if their code gnerates unhandled exceptions, you can still ensure that your top level object remains stable.
Seems pretty useful to me.
It's always a good thing if you can do this, because if you perform all of the necassary checks about what the plugin is doing, you can offer a stable and reliable environment for someone elses code, even if you didn't write it yourself.
As long as you have some scheme for dealing with calling conventions, they can even write their code in whatever language they want.
If you run their code on another thread or better in a separate process but in their DLL, then even if their code gnerates unhandled exceptions, you can still ensure that your top level object remains stable.
Seems pretty useful to me.
Was assuming it was something similar in terms of writing a library and wanting to hide/bundle up dependencies. Just really need clarification if that is the reason before coming up with a solution.
Plenty of other options around sticking it in the GAC/etc. too if it's more of keeping it out of the way of VS.NET.
J_S_G said:
dilbert said:
I'm only guessing, but if he's writing some object that provides the capability for others to write plugins, in the form of a DLL with dynamic linkage.......
It's always a good thing if you can do this, because if you perform all of the necassary checks about what the plugin is doing, you can offer a stable and reliable environment for someone elses code, even if you didn't write it yourself.
As long as you have some scheme for dealing with calling conventions, they can even write their code in whatever language they want.
If you run their code on another thread or better in a separate process but in their DLL, then even if their code gnerates unhandled exceptions, you can still ensure that your top level object remains stable.
Seems pretty useful to me.
It's always a good thing if you can do this, because if you perform all of the necassary checks about what the plugin is doing, you can offer a stable and reliable environment for someone elses code, even if you didn't write it yourself.
As long as you have some scheme for dealing with calling conventions, they can even write their code in whatever language they want.
If you run their code on another thread or better in a separate process but in their DLL, then even if their code gnerates unhandled exceptions, you can still ensure that your top level object remains stable.
Seems pretty useful to me.
Was assuming it was something similar in terms of writing a library and wanting to hide/bundle up dependencies. Just really need clarification if that is the reason before coming up with a solution.
Plenty of other options around sticking it in the GAC/etc. too if it's more of keeping it out of the way of VS.NET.
Not being .NET enabled, I had no idea what the GAC was, so I looked it up. I have to admit that I had wondered how the CLR, and dynamic linkage actually worked. I suppose I figured that concepts like Entrypoint, and Context must still exist. I should think that there's much more scope for the OS to frig with these things now though.
Looking at the internet though it seems it's all gone a bit backward, with everything using late binding and really long names. So much for the benefits of early binding. I'm thinking that maybe DLL Hell was not so bad after all!!!!!
dilbert said:
Looking at the internet though it seems it's all gone a bit backward, with everything using late binding and really long names. So much for the benefits of early binding. I'm thinking that maybe DLL Hell was not so bad after all!!!!!
Nah, it's really cool - lots of misinformation on the 'net.
You've got two options - GAC or not GAC. Personally, I avoid the GAC like the plague, as do most people in the real-world (TM). Hell, I even got away with recommending people not to use it in a couple of books.
Aaaaanyway, think of it as a 2 stage process; there's actually doing early binding itself and ensuring everything's nice and strongly typed, etc. And then there's finding what it is that you've bound to at run time. As long as you build a clever mechanism that only incurs the pain of finding this the first time it's needed at run time - by either checking the GAC or, failing it being found there, probing the path, then it's all peachy following that.
(Hint: it does it properly
)J_S_G said:
dilbert said:
Looking at the internet though it seems it's all gone a bit backward, with everything using late binding and really long names. So much for the benefits of early binding. I'm thinking that maybe DLL Hell was not so bad after all!!!!!
Nah, it's really cool - lots of misinformation on the 'net.
You've got two options - GAC or not GAC. Personally, I avoid the GAC like the plague, as do most people in the real-world (TM). Hell, I even got away with recommending people not to use it in a couple of books.
Aaaaanyway, think of it as a 2 stage process; there's actually doing early binding itself and ensuring everything's nice and strongly typed, etc. And then there's finding what it is that you've bound to at run time. As long as you build a clever mechanism that only incurs the pain of finding this the first time it's needed at run time - by either checking the GAC or, failing it being found there, probing the path, then it's all peachy following that.
(Hint: it does it properly
)When you say properly, do you mean that the CLR provides a real machine code stub, and the module boundary is in stdcall calling convention? Perhaps it's some other brand of Propa (TM)...
dilbert said:
J_S_G said:
dilbert said:
Looking at the internet though it seems it's all gone a bit backward, with everything using late binding and really long names. So much for the benefits of early binding. I'm thinking that maybe DLL Hell was not so bad after all!!!!!
Nah, it's really cool - lots of misinformation on the 'net.
You've got two options - GAC or not GAC. Personally, I avoid the GAC like the plague, as do most people in the real-world (TM). Hell, I even got away with recommending people not to use it in a couple of books.
Aaaaanyway, think of it as a 2 stage process; there's actually doing early binding itself and ensuring everything's nice and strongly typed, etc. And then there's finding what it is that you've bound to at run time. As long as you build a clever mechanism that only incurs the pain of finding this the first time it's needed at run time - by either checking the GAC or, failing it being found there, probing the path, then it's all peachy following that.
(Hint: it does it properly
)When you say properly, do you mean that the CLR provides a real machine code stub, and the module boundary is in stdcall calling convention? Perhaps it's some other brand of Propa (TM)...
Sorry - been out at a Microsoft conference in the States for a week. Junket? Me?
The machine code one's interesting... As much as MS spout "thou shalt not use unmanaged code", the amount of the Framework itself that actually has unsafe blocks and references to traditional COM DLLs is surprising. As for a stdcall - nah, I don't count that as propa nowadays; you'd lose too many of the fancy features you gain by a bit of indirection.
Managed .NET's not the thing for high-performance simulation (either mathematical or graphical) calculations, but for desktop apps where the CPU's generally sitting idle, the cost-benefits of the development and runtime platform to almost everyone are HUGE. And the benefits of the garbage collector, etc. generally outweigh performance improvements that an "average" coder would get by writing in C++, too.
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff