lycangeek

QUOTE Everything is a copy - but primatives at least are on the stack. .NET is very fast at memory allocation, but nothing beats the stack The main problem here is that you are dealing with a lot of string data, which really gets expensive copying back and forth. QUOTE I take it your MS project is still secret? Kinda yes, kinda no - I'm the tech lead for the project system in Visual Studio - at least for the upcoming (after VS2008) release, which isn't really announced yet. I'm going to roll out a new blog on MSDN when we can start talking publically about it (maybe mine, maybe a team blog), but it'll be of more interest to folks that want to create or extend project types in Visual Studio. I've thought about firing up detritis again, but I have to say I've got so little time it's not been top of the priority list. Partly that is due to work, and party it's due to the pacific NW - there is so much to do up here

Hey guys, tis I, Brian - John contacted me and ask that I look at this thread. There is cost involved in calling .NET that is just a fundamental issue w/ a non-.NET application calling .NET. We also have some additional issues based on the way LV is designed versus a text language. However, let me explain what happens when you call out to .NET...Note, this assumes you've called .NET before: I'm not going to go over the startup cost for the very first method to .NET. 1. The Invoke node takes each input parameter and converts it to .NET data. a. If the type is a primative, such as an int, this is a very trival operation. b. If the type is larger, such as a string, then we must make a copy of the string. The reason is that we can't pass a C character point to memory to a .NET routine expecting a .NET string. This can be very expensive depending on the types. c. If the type is a .NET refnum, then the "copy" is just an integer of the refnum value. 2. We jump across to the .NET app domain. The app domain is a .NET concept - kind of like a process within a process. In earlier versions of LV, this was very, very expensive. One of the last things I worked on before I left NI was to make this much, much faster. I believe that would have shipped in LV 8.5, but can't say for certain...but I would be suprised if it didn't. 3. Any .NET refnum needs to be "unpacked". Basically whenever we return to LV w/ an object reference, we ask .NET to give us a "cookie" that represents the .NET object (a GCHandle for those that are curious). Now that we are coming back in, we have to ask for all such cookies to be converted back into the .NET objects themselves. This should be fairly fast. 4. We now need to invoke the method. We use reflection to do this - a fairly standard mechanism for a non-.NET language to call into .NET, but unfortunately it isn't very fast. If you have any experience w/ COM, it's equivalent to using IDispatch, like VB of old used to do. 5. When the method returns, we reverse direction and do steps 1-3 in reverse order for the return data. Overall, the execution process is fairly good given all the translations required, but it's not free. This is especially painful for lots and lots of little calls where the overhead of calling the method really dwarfs the method you are calling. In the past, I've always recommended to treat calling .NET the same way you treat machine-machine programming - avoid chatty interfaces. Obviously this isn't always possible w/o writing extra .NET code, but there you go. Hopefully this helps explain, although obviously you've already done the work to get the concrete data. Brian

Well, the regsvr32 is for ActiveX/COM, so that shouldn't be an issue. It could be that the .NET assemblies you are using are expecting to be in the GAC, but from your comments, it doesn't sound like that's the case. The .NET assemblies (DLLs) should be in the same directory as the EXE or in the /data or /bin subdirectory. Let's get some information.... 1. What version of LabVIEW? 2. What versions of .NET are installed on your dev machine and the other PC? 3. What version of .NET was the .NET assembly you are using built against? I've got some other possibilities, but let's start with this. Brian

I'm pretty sure you can't case an HWND to anything - it is an unmanaged pointer and .NET will throw a fit if you try. Past that I can't give much guidance. BTW - regarding the new thread, I simple mean starting a new thread on this discussion group with a new title reflecting the direction this thread is taking. Others that have worked with Win32/.NET windows and LV don't know we are talking about it under a thread called "Replying to .NET assemblies & linking to new ver."

I'm all out'ta bubble gum... But now after that nice compliment I have to claim ignorance. I'm a system guy myself so I have never really worked with the UI components much. However I would guess that this is related to the fact that .NET popping up UI components inside the LV process results in having two different UI threads. This isn't a problem - Windows is designed to handle this. But it means you probably need to play around with some other Win32 or .NET APIs to bring windows to the front. Another thought - you can also try to have the VI that calls the .NET routines configured to run on the LV UI thread of execution (see VI Properties->Execution). This might help work out some issues also. Just throwing ideas to the wall to see what sticks. Another suggestion - create a new thread of discussion on this forum if you post back so that others might be able to help out. Not sure that the right people are going to see this question under this thread.

Good Luck!

Hmm. When you bring up the list, you should see two System.Drawing (1.0.3300.0) System.Drawing (1.0.5000.0) Where the 1.0.5000.0 is the .NET 1.1 version. If you don't see that one, I would recommend a. Making sure that there is no System.Drawing dll in the same directory as LabVIEW or your VI. b. Make sure that your .NET Assembly Reference dialog doesn't refer to anything in the Framework directory or other place with a System.Drawing DLL. c. Then restart LV and check again. d. If that still doesn't work, go to C:\WINDOWS\ASSEMBLY\GAC\System.Drawing and make sure you have something like this: C:\WINDOWS\ASSEMBLY\GAC\System.Drawing>dir Volume in drive C has no label. Volume Serial Number is 9CC6-3FBF Directory of C:\WINDOWS\ASSEMBLY\GAC\System.Drawing 04/19/2005 08:34 AM <DIR> . 04/19/2005 08:34 AM <DIR> .. 04/19/2005 08:34 AM <DIR> 1.0.3300.0__b03f5f7f11d50a3a 01/12/2005 02:50 AM <DIR> 1.0.5000.0__b03f5f7f11d50a3a and in the 1.0.5000 directory, C:\WINDOWS\ASSEMBLY\GAC\System.Drawing\1.0.5000.0__b03f5f7f11d50a3a>dir Volume in drive C has no label. Volume Serial Number is 9CC6-3FBF Directory of C:\WINDOWS\ASSEMBLY\GAC\System.Drawing\1.0.5000.0__b03f5f7f11d50a3 a 01/12/2005 02:50 AM <DIR> . 01/12/2005 02:50 AM <DIR> .. 08/11/2004 06:23 PM 466,944 System.Drawing.dll 08/11/2004 06:23 PM 282 __AssemblyInfo__.ini And in the INI file (make sure not to modify it in any way) [AssemblyInfo] Signature=3309eb682d18af9cfe8a78dd01333e8ad8d8163a MVID=98d8256d97bd2248b50c08c90f269a44 URL=file:///C:/WINDOWS/Microsoft.NET/Framework/v1.1.4322/System.Drawing.dll DisplayName=System.Drawing, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a If not, then uninstall and reinstall the .NET 1.1 framework.

Ah, system assemblies are already in the GAC (Global Assembly Cache). We display those for you automatically. For example, when you drop down a Constructor Node, that dialog allows you to select any .NET System dll (except for mscorlib). I am confused then by your comment that it isn't showing the latest ones. If it is a .NET framework DLL, then there is only the one 1.1 version to work with. Are you trying to use .NET 2.0 beta or something?

All, versioning in .NET. This topic is kind of like... :headbang: I've got some material on my blog regarding the issues of assembly versioning and LabVIEW - if you are interested in the various details you can check it out there. The short answer is that LV 7.x relies on the ".NET Assembly References" to tell it where to find the DLLs when you are programming the VI. What it sounds like is that your reference was pointing to the v1 assembly. When you tried to browse to the 2.0 version, LV saw that it was the same name (say foo.dll) and simple reverted to the one it already had loaded. So you need to update your reference in the ".NET Assembly References" and restart LabVIEW (you need to restart because we've already loaded v1 into our reflection domain and .NET doesn't let you unload a single assembly). HOWEVER Due to the way the 7.x code works, you should keep all your assemblies either in the GAC or in the same directory as the VI. Failure to do this can result in runtime errors b/c it can't find the assembly (or binding to the wrong DLL if the older DLL is in the same directory as the VI). This is all based on the rules .NET has about finding assemblies (See my blog for the full details). I'm going to stop there because I don't want to overload anyone. If you are interested in more, or have questions from my blog material, please let me know.