.NET assemblies & linking to new ver.

[Norm Kirchner]

When I bring up the list of available assemblies in LV 7.1 it does not show the newest versions of the assemblies. So I browse to the updated ones, and find the one I need, select it and go back to the browse window which still points to the old assembly.

Anyone w/ experience in accessing the updated .NET assemblies from LV??

[lorinkundert]

When I bring up the list of available assemblies in LV 7.1 it does not show the newest versions of the assemblies. So I browse to the updated ones, and find the one I need, select it and go back to the browse window which still points to the old assembly.

Anyone w/ experience in accessing the updated .NET assemblies from LV??

4743[/snapback]

I use .NET assemblies all of the time, If you are constructing the reference from a file you should remove that reference from LabVIEW before adding the new one, keep in mind that by registering it that way you will probably need to place a copy in every directory any VI that uses it resides in to use it properly. The best thing all around is to give the assembly a strong name if you are the author or have the source or ask the author to do it for you, this will allow you to place the assembly in the GAC by moving the file to C:\Windows\Assembly, LabVIEW will handle it better and maintaining the correct revision is easier.

[lycangeek]

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.

[Norm Kirchner]

Ahh, but the problem in my case is that I am not trying to load .NET dll's that I've created.

I want to load the system assemblies from windows/microsoft.net/Framework/v1.1.4322

Where to go in this situation

-Norm

[lycangeek]

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?

[Norm Kirchner]

I want to use System.Drawing.dll

It looks as though the newest version is v1.1.4322, but in LV it still references 1.0.3

I did find the GAC under admin tools, and it still ref's the 1.0.3 for all assemblies

If I go to c:\windows\microsoft.NET\framework it shows 2 directories

v1.0.3705

v1.1.4322

My LV list and the GAC still looks at the 1.0.3

This is my problem :headbang:

[lycangeek]

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.

[Norm Kirchner]

Where the 1.0.5000.0 is the .NET 1.1 version. If you don't see that one, I would recommend

Now I see the light.

Silly me, I was expecting the version number to start w/ something like ohh I dunno 1.1.

In anycase, I don't know for sure what the version number was before I started kabitzing with everything, but it is now the correct 1.0.5

I am now back on the track of :headbang:, trying to get an image into a print preview window and a page setup/print dialog available to the end user.

[lycangeek]

Good Luck!

[Norm Kirchner]

SIDE NOTE: Lycangeek kicks arse w/ .NET

On the matter of the print capabilites, I am finding that the page setup and print dialogs keep popping up behind my app and I don't see a method/property to bring/force those specific dialogs to the front.

Any direction? :arrow: :question:

[lycangeek]

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.

[Norm Kirchner]

I'm going to ask Mike A. to start an External Code section under General, we'll see what happens.

For now, the overloaded method "Show dialog" has an instance that takes an owner as an input.

Now I have all the planks for the bridge but I just need the rope to tie them together

I can get a windows HWND from the user32.dll calls,

On any form there is a Handle property that can be read but not set.

And the owner is of class IWin32Window.

Now here's the question of the day. Is it wrong to try to typecast the HWND to the IWin32Window type :question:

[lycangeek]

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."