How do I localize a file DSN path (e.g. "C:\Program Files\Common Files\Data Sources\mydata.dsn" changes to C:\Program Files\Fichiers communs\ODBC\Data Sources\mydata.dsn" in French)

[wireman]

We use file DSNs in our LabVIEW application but have found that when the application is distributed to Windows XP configured for foreign lanugages (e.g. French), the C:\Program Files\Common Files is localized to something else (e.g. C:\Program Files\Fichiers communs).

How can we modify the installer to handle these issues? Or how can we programmatically determine what the correct (i.e. localized) Common Files path is so we can copy the DSN files to the correct folder when the application first runs?

[shew82]

I would query Windows to find out the current "CommonProgramFiles" path (i.e. C:\Program Files\Common Files) and copythe file at runtime.

The way that I find out special folder paths like this is to make the following .NET call to System.Environment.GetFolderPath:

Shaun

[waldemar.hersacher · Accepted solution]

You can also read out a lot of paths using the registry VIs.

The paths are in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders or in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folder.

[wireman]

I tried shew2's .NET solution and it seemed to work until I built the installer and tried it on a target machine. The executable ended up with a broken run arrow with no explanation. It may very well be that I have not included something that is necessary for the .NET, but I suspect the registry VI solution would be easier to contend with.

In the end, however, I've decided just to put the DSN file with the application instead of the Common Files folder thereby avoiding the whole localization issue of the Common Files folder.

Thanks to you both for answering so quickly with great ideas!

[shew82]

Just in case anyone else reads this thread - whenever you use a LabVIEW built exe that has at least one VI that contains a .NET call, you have to manually make sure that .NET runtime is installed on the target machine.

More often than not, modern PCs (especially those with Automatic Update) will have .NET, but some older PCs that are not connected to the internet may not have it installed.

Unfortunately there is no way to a: programatically detect if .NET is installed, or b: for a LV installer to check for .NET. In addition, the error message that gets generated by LabVIEW is very cryptic in that it does not say anything specifc about the .NET runtime not being installed.

Shaun

[smercurio_fc]

---

shew82 wrote:

Unfortunately there is no way to a: programatically detect if .NET is installed, or b: for a LV installer to check for .NET. In addition, the error message that gets generated by LabVIEW is very cryptic in that it does not say anything specifc about the .NET runtime not being installed.

---

Where did you read this? Of course there is. You can look for the registry keys or you can look at the file versions, as desribed in this MS KB article.

[shew82]

Sorry, I meant from within your program - if .NET is not installed your LabVIEW built EXE will simply not run - there seems to be no way to catch the error and handle it nicely (or even informatively) unless you wrap your LV application with another EXE made in a different language or a use a BAT file or something, neither are particularly nice.

The same goes for installers, you *can* create a little BAT file or something and tell it to run using the Application Builder advanced options, but it always feels like kind of a hack when a user gets presented with a shell window after running your installer.

Message Edited by shew82 on 08-14-2009 03:00 PM

[smercurio_fc]

---

shew82 wrote:

Sorry, I meant from within your program -

---

So did I. You do not neet .NET to check registry keys.

---

if .NET is not installed your LabVIEW built EXE will simply not run.

---

Not true. It will run, but the .NET stuff will error out. See attached example that first checks to see if .NET is installed. If not, you get an error. The app will still run, though. 

[shew82]

You know what, this is one of those things where I'm soooooo happy to be proven wrong!!! 🙂

Surprizingly no one else I had spoken to regarding this (including people in NI and a few LV Architects) knew this little nugget (well, either that or I was asking the wrong questions! 😉 ).

I'm going to give that method a try with one of our apps.

Thanks!

Shaun

[smercurio_fc]

Please note that the example is for demonstration. It does not check for a specific version of .NET, as sometimes this may be important. In this case, there are keys within that tree for each version of .NET.