Dynamic C# dll components?
-
I'm not into C# for more than few days and I allready like it. I have some free time and would like to explore it, and it looks like it would be perfect if I could start using it for real, but I'm not shure if it could fulfill my needs. The thing is that, for example, I will be required to develop a pluginable application in a month or two, and I have been reading MSDN all day long, being unable to find out how to do it with C# and managed enviroment. Recently I used COM to develop plugin objects that would, upon plugin installation, register (regsvr32) themselves and add class GUID to my applications registry key. The application would then upon start enumerate all GUIDs from it's registry and load required plugin objects and it worked fine. Before that I simply had a plugin directory with plugin dll-s which exported function (.def) that was a object factory. App would enumerate dlls in that specific directory and LoadLibrary them and stuff. I wrote a simple component dll in C# and a client using it and it's easy and cool. But I don't have a slightest idea how could I (if it's possible at all) write a component and import it at run time only by knowing .dll path or some sort of object id? All plugin objects would ofcourse implement the same plugin interface and use some same typelib or something. Is there a way? :)
-
I'm not into C# for more than few days and I allready like it. I have some free time and would like to explore it, and it looks like it would be perfect if I could start using it for real, but I'm not shure if it could fulfill my needs. The thing is that, for example, I will be required to develop a pluginable application in a month or two, and I have been reading MSDN all day long, being unable to find out how to do it with C# and managed enviroment. Recently I used COM to develop plugin objects that would, upon plugin installation, register (regsvr32) themselves and add class GUID to my applications registry key. The application would then upon start enumerate all GUIDs from it's registry and load required plugin objects and it worked fine. Before that I simply had a plugin directory with plugin dll-s which exported function (.def) that was a object factory. App would enumerate dlls in that specific directory and LoadLibrary them and stuff. I wrote a simple component dll in C# and a client using it and it's easy and cool. But I don't have a slightest idea how could I (if it's possible at all) write a component and import it at run time only by knowing .dll path or some sort of object id? All plugin objects would ofcourse implement the same plugin interface and use some same typelib or something. Is there a way? :)
I should have read the previous messages, as it is allways suggested ;) I've just read the 'How to import C# dll dynamically' thread (20:11 24 Feb '02). So I think I could do something with that. If, however, someone would like to give me an idea of how to solve my problem - the best and easiest way - I would be thankfull :)
-
I should have read the previous messages, as it is allways suggested ;) I've just read the 'How to import C# dll dynamically' thread (20:11 24 Feb '02). So I think I could do something with that. If, however, someone would like to give me an idea of how to solve my problem - the best and easiest way - I would be thankfull :)
Are your plug-ins going to be written using .NET as well? James Sonork ID: 100.11138 - Hasaki "I left there in the morning with their God tucked underneath my arm their half-assed smiles and the book of rules. So I asked this God a question and by way of firm reply, He said - I'm not the kind you have to wind up on Sundays." "Wind Up" from Aqualung, Jethro Tull 1971
-
Are your plug-ins going to be written using .NET as well? James Sonork ID: 100.11138 - Hasaki "I left there in the morning with their God tucked underneath my arm their half-assed smiles and the book of rules. So I asked this God a question and by way of firm reply, He said - I'm not the kind you have to wind up on Sundays." "Wind Up" from Aqualung, Jethro Tull 1971
Well I suppose so, isn't a simple C# component also a .NET component (or it must implement System.ComponentModel.IComponent to be fully qualified .NET component)? I really don't quite understand the .NET philosophy, but as far as I do: All C# apps when compiled are a metadata that's compiled by .net at run-time prior to execution? Or there is a way to compile app (or component) to fully executable win32 code that can be run at platforms without .net? :) And I haven't considered the needs of the .net app deployment - what would I have to do exactly and how much would it cost me? I suppose that the only thing I would have to give to my app user is, exept the app itself ;), MS .NET Component update or something like that? But I haven't got the slightest idea of how to do it and would it cost me something. I'm sorry if my questions are stupid but I'm pretty new to all this and can't tell the difference between the stupid and the smart ones :)
-
Well I suppose so, isn't a simple C# component also a .NET component (or it must implement System.ComponentModel.IComponent to be fully qualified .NET component)? I really don't quite understand the .NET philosophy, but as far as I do: All C# apps when compiled are a metadata that's compiled by .net at run-time prior to execution? Or there is a way to compile app (or component) to fully executable win32 code that can be run at platforms without .net? :) And I haven't considered the needs of the .net app deployment - what would I have to do exactly and how much would it cost me? I suppose that the only thing I would have to give to my app user is, exept the app itself ;), MS .NET Component update or something like that? But I haven't got the slightest idea of how to do it and would it cost me something. I'm sorry if my questions are stupid but I'm pretty new to all this and can't tell the difference between the stupid and the smart ones :)
Actually you looked far more deeper than I was asking :) I was simply wondering if the plug-ins would be .NET or if they would be written as a C/C++/COM object. Now, the reason I was asking is because .NET gives you a lot of information about a .NET assembly at runtime; enough information that you can see what types are available in an assembly. I've written an article a while ago that does just this. Using Reflection to extend .NET programs, if you have any questions about it ask here or in the articles forum :) James Sonork ID: 100.11138 - Hasaki "I left there in the morning with their God tucked underneath my arm their half-assed smiles and the book of rules. So I asked this God a question and by way of firm reply, He said - I'm not the kind you have to wind up on Sundays." "Wind Up" from Aqualung, Jethro Tull 1971
-
Actually you looked far more deeper than I was asking :) I was simply wondering if the plug-ins would be .NET or if they would be written as a C/C++/COM object. Now, the reason I was asking is because .NET gives you a lot of information about a .NET assembly at runtime; enough information that you can see what types are available in an assembly. I've written an article a while ago that does just this. Using Reflection to extend .NET programs, if you have any questions about it ask here or in the articles forum :) James Sonork ID: 100.11138 - Hasaki "I left there in the morning with their God tucked underneath my arm their half-assed smiles and the book of rules. So I asked this God a question and by way of firm reply, He said - I'm not the kind you have to wind up on Sundays." "Wind Up" from Aqualung, Jethro Tull 1971
Thanx, I'll look into it right now :)