I ve just looked at the developers stuff. And its all VS6.
Does or will megplus support .net assembly. Cuz coding vb 6 when youre used to C#.net2003 is like going back to the stoneage.
If there isnt dotnet support I would really like to see it included in the next version. I think most programmers dont code a plugin for msplus cuz the VS studio used belongs in a musium

I code in VB.net and a little bit C# .net too, but as far as I am concerned, I think few people have .net framework redistributable pack (i.e. the CLR) which is over 20MB installed...And I don't think people will download it only for a 100kb plugin

You can always make a poll here in the forums anyway

well patchou codes in c++ so its not easy to translate it all

quote:

---

Originally posted by jackass_wanabe
well patchou codes in c++ so its not easy to translate it all

---

not excatly but hey........ you learn a new thing every day

Since you respond within 2 secs:
how does msgplus include the plugins. I use plugins, but they are loaded by a someone elses plugin-framework so i dontknow how assemblies are loaded, but i think the dotnet assembly needs another load-protocol then the 'old' assembliestypes. The only thing i want to know is IF it can be done, without having to force people to include the .net-framework. isnt there some sort of small lib for C++6 to check if there is a .net framework and depending on that load the .net assemblies?

quote:

---

Originally posted by Mnjul
I code in VB.net and a little bit C# .net too, but as far as I am concerned, I think few people have .net framework redistributable pack (i.e. the CLR) which is over 20MB installed...And I don't think people will download it only for a 100kb plugin

---

quote:

---

You can always make a poll here in the forums anyway

---

quote:

---

Originally posted by Choli
people can vote here and btw it should be in poll center to avoid duplicate replies

---

quote:

---

Originally posted by BWDuo
does anyone know if patchou can add .net support.

---

quote:

---

Originally posted by BWDuo
btw what is the poll center?

---

quote:

---

Originally posted by Mnjul
I code in VB.net and a little bit C# .net too, but as far as I am concerned, I think few people have .net framework redistributable pack (i.e. the CLR) which is over 20MB installed...And I don't think people will download it only for a 100kb plugin

---

well 20 MB THATS NOTHING!!. 20MB gives you ALL the stuff. I am happy VS uses a .net framework cuz i prefer one 20MB pacage above 200 1Mb-Applications. .net IS the future. If Micro$oft sais it will be it will use it$ minopolic po$ition to enforce it. I wouldnt be suprised if the .net frameworks are included in windows. cuz they will, eventially be made with and for the .net framework. Even more conserning is the fact that .net isnt a simple runtime library. But a assembly. This will also mean micro$oft can enforce people to buy certain Processors which use that kind of assembly as their standard, (so effectifly removing the Just in Time-stuff). I don't think they'll strike now or if they'll do it in the near future, but the smell for power is too big for Micro$oft.

Concluding: .net should be at least posible with M$N-Me$$enger

quote:

---

Originally posted by BWDuo
certain Processors which use that kind of assembly as their standard,

---

quote:

---

Originally posted by BWDuo
.net isnt a simple runtime library. But a assembly.

---

quote:

---

Originally posted by BWDuo
.net IS the future

---

quote:

---

Originally posted by Choli
no no  Processors have thier assembly code and mothing more. No processor will include the .net.

---

quote:

---

Originally posted by Choli
.NET is the same as Java but done by M$.
.

---

I may very well be missing the point, but isnt the key fact here that any plugin, to be usable by messenger plus! hs to export certain functions (and if it shares the same properties as VB, have a registry key defined to help messenger plus! find the exports)

I am aware of the existance of at least one c# plugin api loading around the net, so it you want to use c#, google it, im sure ull find it. VB and c/c++ we already have plugins for

There are several Delphi coders on the forums, and there is at least one plugin framework on this board, and short of that it should be possible to make a plugin in practically any other suitable language.

If a language can make dlls and thereby export the proper functions to messenger plus!, theres no reason u cant make a Plus! plugin in it.

But as i said, im probably missing the point of this discussion as i code in c/c++

Well you are missing the point:

Messenger plus uses API and C# uses .net only.
There must be a sort of API-Compliant stuff. but since the API must load the dotnet assembly and not reversed the API must be able to read dotnet (In other words the .net framework must be suported). And If i google I'll find stuff. But if msgplus doesnt have that stuff, its not worth looking for. The big problem is that I cant downgrade to VB6 or VC++6, cuz I program object orientated and not linear/modulair (whatever the oposite is called), which is extremely slow and barely supported in CS6.

(LP: Best: In the End / With You / Numb )

I'm sorry I don't have time to read all the posts in this thread, however, Messenger Plus! totally accepts C# plugins... just use the COM Interop to produce COM entries in the registry, register your plugin in Plus! as if it was a VB one, et voilà!

Oh... and btw.. .NET rules and Java is /$%(*/$%*("/$/&"$()*&"*(&CRAP/$%/$%*&/$%*&BS/$%/$%/$. If you have a higher opinion of this language, that's because you never tried developing any tool with it .

Finally!

Thanks that was what I wanted to know!

But Jave does control all the satalites. and you see what happened with some Mars landers

i do believe i made it clear u could develop plugins in c#.. some ppl never listen/read

quote:

---

Originally posted by optimism_
i do believe i made it clear u could develop plugins in c#.. some ppl never listen/read

---

Go google it and find the framework im thinking of and read it and see if that helps you then

.NET Managed Plugins (and Source)

I just wrote a .net version of the vb plugin, it works like the other code, but mine should have support for the notifacation dialogs, but im still testing it.

Regarding the notifcation support, just tested it and it works perfectly.

I will post a link or download as soon as i prepare it for release.

Ok, the file is attached, it's a rar with two rar files in it, they are:

1.MessengerPlus.Plugin.VB.rar - Plugin Base
2.MyMessengerPlugin.rar - Sample Plugin

The plugin only does 3 things, 3 random quotes, shows a message box, and show a notifcation box that links to http://www.neowin.net

The plugin base was made under Visual Studio .NET 2003 and XP SP1

the commands that were in the MPPlusDefs file are now referenced as a variable called PlusUtilities

the COM stuff in the plugin are to over come a problem that surfaces when using com and inheritance, the compiled file picks up the Class ID on it's base, so those variables and atribute are so messenger plus can read more than one plugin of this type.

Please, if you use this file to build your own plugins, reference me. (my real nick is The_Decryptor, this forum wont let me register it)

Note: This was only done in about 1 hour, so if there are bugs, ill try to fix them

There is one bug, i think if you dont put the plugin base in the gac, it  wont appear in Visual Studio if the file is updated.

Hehe,

I totaly agree with BW_DUO, c# is the future.. but c++ and managed c++ is the current..

It is easy to just write a little wrapper in managed c++ which will load a .net dll which is its own name .net

So the same assembly renamed to wee.dll will load wee.net.dll, and renamed to rrr.dll it will load rrr.net.dll..

That is the easiest way for n00bs to do it.. or just make the whole plugin in managed c++ (AND before n00bs get complaining!! NEVER USE MANAGED CODE IN THE DLL OFFSET FUNCTION (dllmain) (m$ bug ))


Ow and i think plugins should be revised

There can be a lot of enhancements:

• Dont use the stupid ->nBlah = 5 and then ->aBlah[1] = 3.. as used for example exporting the info about the commands of plugins.. But make a simple add function which takes care of that (and use a vector) so that you only have to use ->add(3, "blag", "gfgg");
  
• Make it possible to put multiple plugins in one dll: In other words.. Let a module be a class which implements IMPPlugin class (which has all the virtual functions which have to be overwritten). And let there be only one function in the dll that has to be exported (except dllmain), that is getplugins(/*[out]*/ cPluginCollect PluginCollection); , where you just add plugins by using PluginCollection->Add(new SomePlugin);.. It makes things so much more easier (And the patchou doesnt need to keep all the dll`s loaded in the memory )
  
• And a lot more, but i`m lazy, and people tend to just avoid the main issue by attacking 'a' little flaw in my concepts

I know in my plugin stuff, you can have multiple plugins in one dll, but it's all com, not exports

Read carefully I use a BASE class IMODULE and a EXPORTED function which returns an array of IMODULE derived instances of plugin classes.. READ BEFORE YOU WRITE