Actually, such a call will work if you take something into account that I forgot to mention (sorry). If the data object implements System.Windows.Forms.UnsafeNativeMethods.IOleDataObject, it does work. Unfortunatel, it is a nested interface of an internal class, but the System.Windows.Forms.DataObject does. You can use reflection to set the FORMATETC and STGMEDIUM structs. Calling Clipboard.SetDataObject does, in fact, call OleSetClipboard. You should try downloading .NET Reflector and take a look at how Clipboard.SetDataObject is done. Like I said, everything you need is already there. You may have to use Reflection to do get at it or you could redefine your own structs and interfaces in the same way it does (except that your IOleDataObject won't be the same Type as theirs, but you can at least make your call to OleSetClipboard work the same). With that, I can understand how your interface methods aren't always correct. This happens often. I had a custom IClassFactory method with the same params. When I tried a trick where you write IDL, compile it with midl.exe to a typelib, then use tlbimp.exe to import that, the method had a mysterious third parameter. Using Reflector (that can disassemble in a much easier-to-follow way than ildasm.exe, and can also decompile), you can see how MS defined their interfaces and match them. Once you get your IOleDataObject interface defined correctly (remember, don't forget the GuidAttribute), you can pass the object directly into a correctly imported call to OleSetClipboard. -----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----

Alex Kucherenko wrote: Have anyone idea how to spend weekends? I always want to ask other developers how they spend there weekends... In my case this often looks like: - I meet with my friends from other developers firms and we drink beer and talk about programming.... Coding? That works for me. (My wife for some reason disagrees) Thanks, Wes

OK first some easy stuff: There is a few good articles in April 2003 MSDN on sidebyside execution. What is happening in your case (afai can figure it out): 1. Server defines an interface 2. Client implements interface 3. Client send inteface to the server 4. Server loads implemetation class. KABOOM!!! How can this be? Simple, the client has made a reference to the culprit assembly (OleDB in your case, that is new in 1.1). This is however not desirable. Like I said, installing 1.1 on the server, should automatically resolve these issues. Not doing this, leaves with 3 options: 1. Prevent the client from using "new" libaries. This not however desirable either, although I think the 1.1 compiler can compile for 1.0 compatibilty (this would be nice). 2. Use Remoting. This will be painfull, but will allow you to do more. 3. Compile any source at a single point, e.g. the server. So I guess its back to the drawing boards for you ;P Hope it helps :) leppie::AllocCPArticle(Generic DFA State Machine for .NET);

If your control library is strongly named (sounds like it is) then by default if the runtime can't find that specific version number it will fail to load. To get around this you can include a publisher policy which tells the runtime that when version a.b.c.y (or a range of versions) is asked for to use version w.x.y.z. You can also use a configuration file which does the same thing, but requires that whoever controls the .exe put some entries in the .exe.config file. Publisher Policy Sample[^] by Mike Woodring. James "I despise the city and much prefer being where a traffic jam means a line-up at McDonald's" Me when telling a friend why I wouldn't want to live with him

Thanks... Not realy what I expect, but it can work without strange exceptions Good Luck Alex Kucherenko

I don't know yet if it's good or not, but a translator[^] was posted on CodeProject a few days ago.

I don't have answers for all of your questions, but here something to get you started If you are creating COM objects then you can force their release by doing MyObject=null; System.GC.Collect(); System.GC.WaitForPendingFinalizers(); System.GC.Collect(); Be carefull when looking at memory usage in the Task Manager it isn't telling you the whole truth.:eek: To determine the real memory usage of an application you could: ' Visual Basic .NET Dim NotepadMemory as Integer Dim component1() as Process component1 = Process.GetProcessesByName("Notepad.exe") NotepadMemory = component1(0).PrivateMemorySize Console.WriteLine("Memory used: " & NotepadMemory & ".") // C# int memory; Process[] notepads; notepads = Process.GetProcessesByName("Notepad.exe"); notepadMemory = notepads[0].PrivateMemorySize; Console.WriteLine("Memory used: {0}.", notepadMemory);