|
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.
|
|
|
|
|
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.
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
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
|
|
|
|
|
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
|
|
|
|
|
good idea but I rather call it workaround. thanks
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
|
|
|
|
|
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 
|
|
|
|
|
True, but I don't have any other choice.
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
|
|
|
|
|
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();
hi
|
|
|
|
|
Do you need to pass any credentials?
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
i have created
dynamic column width in crystal report asp .net 2008
want dynamic width for the column how to do this?
|
|
|
|
|
Hi All,
I am new to .NET. I recently developed a windows service using VC#.
During installation of this windows service I point to .NET 4.0(I am talking about the "installUtil". Not sure if this makes any difference.)
Whenever there is .NET 3.5 and .NET 4.0 present in the system on which it runs my service runs perfectly fine. But whenever .NET 3.5 is not installed but only .NET 4.0 is present my service fails to run and it gives me the following error:
Could not load file or assembly 'System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
Does not .NET 4.0 contain everything that .NET 3.5 contains and more?
Can anyone please help me with this situation? I definitely cannot ask everyone using my windows service to install .NET 3.5 and 4.0 on their systems.
Can someone please provide a solution?
Thanks in advance!
Regards,
Lydia
|
|
|
|
|
The .Net Framework 3.5 is installed with Windows 7, so for users who have already upgraded to Win7 you only have to add the .Net 4 package to your distribution. For the rest, you will definitely have to have them install both versions. As far as I can determine, the .Net 4 features are only distributed with VS 2010, and are add-ons to the .Net 3.5 set, not a complete, backward-compatible package. That surprises me a bit, as I'd expect each version to include all previous versions, but apparently that's not the case.
Will Rogers never met me.
|
|
|
|
|
Roger - the rewrite of .NET 4 meant that they distributed a completely new version because they put a lot of effort into making the runtimes smaller, reducing memory bloat. If you installed .NET 3.5, it was merely an extension to .NET 3 which, was an extension of .NET 2 - so they merely added new DLLs in those versions.
I hope that this clears any confusion up.
|
|
|
|
|
Pete,
I am still a bit confused.
Are you saying .NET 4 does not have all the dlls from the previous versions?
Thanks in advance!
|
|
|
|
|
That's exactly what I'm saying. While it has all the functionality, some of that functionality was moved between DLLs. Remember that the DLLs also have security in them to prevent them being tampered with, so each new version of the DLL gets a new security ID.
|
|
|
|
|
As I explain to Roger below, you may just need to change the reference from a .NET 3.5 DLL to a .NET 4 DLL to get it working OK.
|
|
|
|
|
I'm not criticizing the .Net 4 distro, but it still leaves Lydia hanging - she needs stuff in 3.5 that was left out of 4, apparently. As much as I dislike Microsoft's way of doing business, they have been really good about including all the dependencies in previous rewrites, and it seems that they didn't do so this time. Of course, I'm relying on adubious source[^] and could be entirely confused.
Will Rogers never met me.
|
|
|
|
|
Take a look at the criticism section which show that Microsoft were damned if they did and damned if they didn't:
"Some developers have expressed concerns about the large size of the .NET Framework runtime installers for end-users. The size is around 54 MB for .NET 3.0, 197 MB for .NET 3.5, and 250 MB for .NET 3.5 SP1 (while using web installer the typical download for Windows XP is around 50 MB, for Windows Vista - 20 MB). The size issue is partially solved with .NET 4 installer (x86 + x64) being 54 MB and not embedding full runtime installation packages for previous versions."
Basically, the issue they are addressing here is the user experience when somebody has to download code written for .NET 3.5 SP1 which resulted in a whopping 250MB download. What it sounds to me is Lydia has code that is still using a .NET 3.5 reference (in VS2010 you have the option just to choose .NET 4 references). The fix could be as simple as removing the reference to the old DLL and adding in the appropriate .NET 4 version.
With .NET 4, it's not a good idea to mix with previous versions.
|
|
|
|
|
Pete O'Hanlon wrote: The fix could be as simple as removing the reference to the old DLL and adding
in the appropriate .NET 4 version.
Good point; removing functionality that is dependent on a previous version and replacing it with more current versions might remove a lot of challenges.
Will Rogers never met me.
|
|
|
|
|
Thanks for your replies and useful tips Roger and Pete!
|
|
|
|
|
You are welcome, and good luck.
|
|
|
|
|
You're quite welcome! 
Will Rogers never met me.
|
|
|
|
|
Actually, if you are compiling against .NET 3.5 so that your code works with 3.5 AND 4.0, then the issue is likely that you are using server-side components.
.NET 4.0 is broken up into a Client Profile and Extended versions.
.NET 4.0 by default only installs the Client Framework when installed on a client machine. Server-side (defined by Microsoft) components are not included (to keep the install size down). You can install them with the .NET 4.0 EXTENDED Framework, after which I would expect your service to work.
If you set your compile target to .NET 4.0 Client Profile, you can discover which components are missing (because they are only in extended in 4.0), and possibly remove them if you want it to work with the 4.0 Client Profile.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
