.NET (Core and Framework)

Not Active28-Jun-11 2:15

28-Jun-11 2:15

Xmen W.K. wrote:
do I have to make it in big font, so you can see ?

Nice attitude. Good luck with getting anyone to help you now.

I know the language. I've read a book. - _Madmatt

Not Active28-Jun-11 1:47

28-Jun-11 1:47

Have you looked at MEF[^]

I know the language. I've read a book. - _Madmatt

Pete O'Hanlon28-Jun-11 3:33

28-Jun-11 3:33

I'm not sure why this was downvoted. MEF was going to be my recommendation as well.

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

Not Active28-Jun-11 3:37

28-Jun-11 3:37

Pete O'Hanlon wrote:
I'm not sure why this was downvoted.

Simple retaliation. Read the other responses, the OP is being an a$$.

I know the language. I've read a book. - _Madmatt

Xmen Real 28-Jun-11 4:39

28-Jun-11 4:39

Pete O'Hanlon wrote:
I'm not sure why this was downvoted.

That guy need to learn bit respect, voted me down for nothing.

Pete O'Hanlon wrote:
MEF was going to be my recommendation as well.

yes I know but MEF is not really what I was needed. The following is from my post

Assume this, if a plugin wants to connect a server over internet, the firewall will show the name of my application and user may allow without knowing its the plugin who is trying to connect.

TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L
%^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2
W_AD`EPABIKRDFVS)EVLQK)JKQUFK[M`UKs*$GwU#QDXBER@CBN%
R0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia>

-----------------------------------------------
128 bit encrypted signature, crack if you can

Dave Kreskowiak28-Jun-11 4:45

Dave Kreskowiak

28-Jun-11 4:45

Xmen W.K. wrote:
That guy need to learn bit respect, voted me down for nothing.

It's not Mark that needs to learn a bit of respect, and it's wasn't he that downvoted you...

Xmen W.K. wrote:
Assume this, if a plugin wants to connect a server over internet, the
firewall will show the name of my application and user may allow without knowing
its the plugin who is trying to connect.

DLL's don't get a process name. DLL's are loaded into the host .EXE process just as if it was part of the .EXE itself. There is no distinction between the .DLL code and the .EXE code, so any code in your .DLL that goes through the firewall is going to appear to the firewall as coming from the .EXE.

The only way I see to getting around this would be to host your .DLL's in a seperate .EXE process and use interprocess communication methods to talk between the two. But, considering the requirement, that's adding a LOT of weight and overhead to your application for very little to no benefit.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak

Xmen Real 28-Jun-11 6:25

28-Jun-11 6:25

Dave Kreskowiak wrote:
The only way I see to getting around this would be to host your .DLL's in a seperate .EXE process and use interprocess communication methods to talk between the two. But, considering the requirement, that's adding a LOT of weight and overhead to your application for very little to no benefit.

Thats what I asked, if you have read my question. But there is benefit, the spyware kind of plugins will always be separated and end user will be responsible for anything goes wrong, not the host application.

-----------------------------------------------
128 bit encrypted signature, crack if you can

Dave Kreskowiak28-Jun-11 6:43

Dave Kreskowiak

28-Jun-11 6:43

The end-user is going to be accountable for it no matter which executable runs the thing! If the app name comes back a normal production app, then they can just look at the plugins and see that something here isn't quite like the others.

I think you're inflating the usefulness of this idea.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak

Xmen Real 28-Jun-11 6:58

28-Jun-11 6:58

Dave Kreskowiak wrote:
I think you're inflating the usefulness of this idea.

I'm just trying to make application more separated as much as possible. I used PipeStream to communicate between processes as I wrote above...the question was simple, is that the only way ? but some people were in too hurry to read that.

Anyway thanks for the reply Smile | :)

-----------------------------------------------
128 bit encrypted signature, crack if you can

Pete O'Hanlon28-Jun-11 7:12

28-Jun-11 7:12

I didn't misread it. I just thought it was a daft idea. Marshalling backwards and forwards of data could end up beinga a fairly expensive business.

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

Xmen Real 28-Jun-11 7:21

28-Jun-11 7:21

Sending/Receiving data through pipe is a daft idea ?

-----------------------------------------------
128 bit encrypted signature, crack if you can

Pete O'Hanlon28-Jun-11 7:24

28-Jun-11 7:24

No - the effort you'll expend creating an overengineered plug-in framework is the daft idea.

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

Xmen Real 29-Jun-11 14:54

29-Jun-11 14:54

Creating that thread and expecting right answer(s) was the daft idea. You guys just read the question, replies completely different thing, ignoring what actually been asked, down votes for nothing.

-----------------------------------------------
128 bit encrypted signature, crack if you can

Pete O'Hanlon29-Jun-11 20:38

29-Jun-11 20:38

No. I understood what you were after from the start (and I haven't voted on this). The reason that I would suggest MEF is because I am friends with the guys who wrote it, and know that they didn't think this was an issue that they had to contend with, so you could learn a lot from the architecture they put in place. If they didn't think that, why should you have to worry about it?

Bottom line - yes, separate processes is the only way you could achieve this, but each process takes up valuable memory and resources and can lead to your application being treated as a memory hog. More importantly, you are expecting the users to have to trust individual plugins through your firewall - I've worked with an application that does this and it was a complete PITA from a user perspective (the application was Lightwave and had something called the Hub that had to be granted access through the firewall). It was an awful experience, and not one I'd want to inflict on users. Even Chrome and Firefox don't feel this is a necessary step. So yes, it is a daft idea.

Of course, you can arrogantly go on your way and overengineer this thing, and then wonder why you end up having no users. Good luck with that.

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

Xmen Real 30-Jun-11 0:33

30-Jun-11 0:33

Pete O'Hanlon wrote:
The reason that I would suggest MEF is because I am friends with the guys who wrote it, and know that they didn't think this was an issue that they had to contend with, so you could learn a lot from the architecture they put in place.

I'm not against MEF or saying its not good but I tried, its too much code just for plugin.

Pete O'Hanlon wrote:
If they didn't think that, why should you have to worry about it?

So you are saying now, I must walk the same path they did.

Pete O'Hanlon wrote:
Bottom line - yes, separate processes is the only way you could achieve this

See its not that hard, could be said earlier.

Pete O'Hanlon wrote:
ut each process takes up valuable memory and resources and can lead to your application being treated as a memory hog.

Not all plugins will start at once, user must click to start them. If (s)he starts 100 plugins, then Im not responsible for that. Its same as you are suggesting I shouldn't worry about firewall issue.

Pete O'Hanlon wrote:
Even Chrome and Firefox don't feel this is a necessary step. So yes, it is a daft idea.

These kind of things doesnt effect those big popular companies.

Pete O'Hanlon wrote:
Of course, you can arrogantly go on your way and overengineer this thing

Arrogantly ? If I had to go that way, then why would I asked here in first place. And I dont see it as overengineer or whatever you call it. Its just the way things works.

-----------------------------------------------
128 bit encrypted signature, crack if you can

Pete O'Hanlon28-Jun-11 5:02

28-Jun-11 5:02

Xmen W.K. wrote:
That guy need to learn bit respect, voted me down for nothing.

Revenge univoting is not teaching somebody respect. It's just childish. It is the forum equivalent of "Did-to, Did-not" that children engage in.

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

jschell29-Jun-11 9:48

jschell

29-Jun-11 9:48

Xmen W.K. wrote:
So first thing came in mind was to just load the DLLs and call the common
abstract class methods. After completing all that, I noticed that there could be
many security issues.

Such as what exactly?

The only security concern that I specifically see with the above description is that you might need to verify that the loaded dlls hasn't been hacked (signature verification.)

Xmen W.K. wrote:
Assume this, if a plugin wants to connect a server over internet, the firewall
will show the name of my application and user may allow without knowing its the
plugin who is trying to connect.

At some point you have to trust the plugin. For instance consider the situation I mentioned above where someone has maliciously replaced the real plugin with one that has the same name and same functionality but which transmits all of the data to a third party.

Xmen W.K. wrote:
My question is, is that the only way ?

First step is to identify what your actual security requirements are.

As an example if you want the user to validate the plugins then you should insure that your application will not load any plugin unless the user has verified it and has done that in the application.

Xmen Real 29-Jun-11 14:44

29-Jun-11 14:44

jschell wrote:
At some point you have to trust the plugin. For instance consider the situation

There is no trust on plugins, if I trust, host application will lose the trust and it will be in firewall block list. And that will ruin entire point of stats management and other important things.

jschell wrote:
As an example if you want the user to validate the plugins then you should insure that your application will not load any plugin unless the user has verified it and has done that in the application.

Well, thats the problem. A user can validate any plugin, regular user has no knowledge whats going on behind the application. Even a programmer, will have read all the source code to make sure the plugin is not a spyware or virus, that may steal their work or documents.

Here is more detailed explanation

- Host Application uses web service, sends and receives informations, update stats.
- User trusts on host application.
- Everyone in the entire world is allowed to create own plugin
- But if host application loads plugin even in separate AppDomain, it still uses same firewall setting, which is already allowed by user, and plugin has direct access to internet.
- Only way I see is separate process for each plugin. So if plugin tries to connect, firewall will confirm that.
- My question was that, is separate process only way to avoid that ? thats it, thats it, nothing more than that.

-----------------------------------------------
128 bit encrypted signature, crack if you can

LCARS x3211-Aug-11 17:37

LCARS x32

11-Aug-11 17:37

You could have your program ask the user if the plugin should be allowed internet access the first time the plugin is loaded. And I mean the very first time, not each session. You can verify the plugin hasn't changed by storing a hash of the plugin's file and checking it against that hash any time it loads. Force the plugin developers to use your program to update the plugin so you know when to regenerate the hash.

In effect, your program becomes a mini firewall. No extra exe's and your program protects the user from malicious plugins. Unless, of course, the user allows the plugin access. But you can't win them all

-Ray

Xmen Real 11-Aug-11 18:19

11-Aug-11 18:19

good idea but I rather call it workaround. thanks

-----------------------------------------------
128 bit encrypted signature, crack if you can

LCARS x3211-Aug-11 19:33

LCARS x32

11-Aug-11 19:33

It may be, but so is creating separate exe's and talking through interprocess communication. At least this way, it's a true integrated plugin. It's also how most developers are used to creating plugins. I can't think of any other applications that use interprocess communication for plugins.

I hope somebody else can give you a better solution. But I wouldn't hold my breath Smile | :)

Xmen Real 12-Aug-11 0:31

calling webservice funtion frm Smar Device

12-Aug-11 0:31

True, but I don't have any other choice.

-----------------------------------------------
128 bit encrypted signature, crack if you can

imtiazahmad27-Jun-11 1:26

imtiazahmad

27-Jun-11 1:26

Hi me using the following code for calling webservice funtion frm smart device but it give error .My firewall already set off.

Error deail : unable to connect to the remote server/ould not establish connection to network

localhost.WebService webSevice = new FirstSmartDeviceProject.localhost.WebService();
webSevice.Url = "http://10.67.32.24/2005/WebService.asmx";
string ss = webSevice.Openconnection();

Re: calling webservice funtion frm Smar Device

Not Active27-Jun-11 2:38