01-24-2014 07:23 AM
I am attempting to write a small C# program to open a TDMS file, read in the contents, do a little manipulation, and then output the result to an Excel file. I've been successful in writing it, but I'm having a little more trouble distributing it to my client. The problem appears to be that the TDMS resource I'm using (NationalInstruments.Tdms.dll) was put together with the .NET 4.5 framework, whereas I need to build this for .NET 4.0 in order to run it on the client's computer.
The obvious solution is clearly to upgrade my client's computer to .NET 4.5. Unfortunately, that's not possible. They do not have admin access to install anything, and neither do I. (Which is why I'm writing this program for them in the first place instead of just installing the TDMS to Excel importer.) My only path forward is to obtain a copy of the resource that is compatible with .NET 4.0. Is this available anywhere?
Thanks.
Sara Johnson
01-27-2014 08:32 AM
OK. Since posting my original question, I've realized that the problem is that the .NET 4.0 version of the resource file only works with Visual Studio 2010. I can't even figure out whether VS2010 is available anymore, and I expect I'd have to restart my project from scratch, so this doesn't seem like a viable solution.
Am I just SOL here? Surely I am not the first/only person to have this problem. Anyone have any ideas?
01-28-2014 06:55 AM
Hi,
Have you tried adding the references according to the Using .NET 4.0 Measurement Studio Assemblies in Visual Studio 2012 help topic?
There is some similar information at this forum post.
If these don't work what versions of Measurement Studio and visual Studio are you currently using?
01-28-2014 07:57 AM
Thanks for the reply.
That was exactly what I was trying to do, but could not find the appropriate version of the resource to add. It appears that I didn't have all the VS2010 support installed that I had thought I did; going back and reinstalling that without trying to add integrated support did get me the version of the resource that I needed and I was able to build my application successfully.
Unfortunately, it still won't run on the client's computer. When they run the .exe I give them, nothing happens; their computer tries to start the process and then just stops it without ever getting as far as even displaying the UI. After a little more poking around, I think I've found out why. It's because I had overlooked the very important words "Client Profile" in the information about their installed version of the .NET framework. Per the referenced help topic:
"Measurement Studio assemblies reference Microsoft assemblies that are not part of the .NET Framework 4.0 Client Profile. Because of this reference, Measurement Studio assemblies do not work with the .NET Framework 4.0 Client Profile."
Is there really not even any kind of a work-around for this? If the Client Profile is all that's available on the client's computer and I have no access to install anything else, I can't use Measurement Studio in my application?
I should have given versions before, sorry. Measurement Studio 2012 for Visual Studio 2013. The older resource I found appears to be MS2012 for VS2010.
01-29-2014 10:06 PM
Hi,
There are a few possibilities that I have found that could be related, but some additional details might help. You said that the "problem appears to be that the TDMS resource I'm using (NationalInstruments.Tdms.dll)", did you receive an error or do you have a different reason to suspect it? Does the executable run on your machine outside of the development environment? What operating system are both computers (and x86 or x64)?
Based the behavior you are getting, are you setting the project and installer properties to AnyCPU? By changing it to x86 in that properties page for the installer through the Configuration Manager, it may allow the executable to work. Change it for the project itself, too, if they don't match. This may solve the issue as some of the NI DLLs are platform-specific.
01-30-2014 07:45 AM
I am able to run the built executable file on the computer I use for development outside of the Visual Studio environment. My development computer has .NET Framework 4.5 installed. I also have another computer without development tools installed which is configured the same way as the customer's computer. On that computer, my results are identical to theirs (see below).
Backing up and describing the problem as I found it originally:
I first built the project using the deault settings, which were to build it for .NET 4.5. The build was successful, but when I tried to run the executable on the customer's computer, the application process would start and stay active for a couple of seconds before closing without ever having even displayed a user interface.
Guessing that it might be a .NET compatibility issue, I tried building the project for .NET 4 (but still using the same version of the TDMS DLL). This time, I got a warning: 'The primary reference "NationalInstruments.Tdms, Version=13.0.40.242, Culture=neutral, PublicKeyToken=dc6ad606294fc298 processorArchitecture=MSIL" could not be resolved because it was built against the ".NETFramework,Version=4.5" framework. This is a higher version than the currently targeted framework ".NetFramework,Version=4.0".' That was why I thought that I needed a different version of the DLL.
As mentioned above, I did wind up finding the older version of the DLL (for Visual Studio 2010) after going through the Measurement Studio installation process again. I changed my reference to point to it and tried building for .NET 4 again. This brought me back to the original behavior: the project built OK, but when run on the customer computer the executable didn't do anything besides try to start itself.
This was when I double-checked the customer's version of .NET and found that it was version 4 Client Profile, not just version 4.
At this point I was going to try building for .NET 4 Client Profile using the VS2010 DLL and report what error that gave (I know it did give one, just can't remember what), but I've just discovered that my 7-day trial period for Measurement Studio has run out. (My company hasn't gotten the full license purchased yet, so I'm running on evaluation versions of everything until they can get the full software ordered.) I've successfully obtained an extension code to take the evaluation period to 45 days, but can't find where to enter it for Measurement Studio--unlike LabVIEW, it's not something I actually *launch* so there's no handy little pop-up dialog for this as all the help for extending evaluations describes. So... I suppose I'm sort of stuck until I figure that out. 😞
01-30-2014 08:52 AM
OK. With that little headdesk of an issue out of the way...
I've now tried to build for .NET 4 Client Profile using the VS2010 DLL. I get an error and a warning, both of which seem like they might be relevant.
The error is "The type or namespace name 'NationalInstruments' could not be found (are you missing a using directive or an assembly reference?)"
The warning appears to explain why the namespace would not be found even though my assembly reference and using directive are firmly in place: 'The currenly targeted framework ".NETFramework,Version=v4.0,Profile=Client" does not include "System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which the referenced assembly "NationalInstruments.Tdms, Version=13.0.40.242, Culture=neutral, PublicKeyToken=dc6ad606294fc298, processorArchitecture=MSIL" depends on. This caused the referenced assembly not to resolve. To fix this, either (1) change the targeted framework for this project, or (2) remove the referenced assembly from the project.'
To address your other question, which I totally overlooked the first time (sorry): Yes, I had been setting the properties to AnyCPU. I tried changing it to x86 and re-building, but the program still executes (or, rather, doesn't) the same way as it did when set to AnyCPU.
01-30-2014 08:53 AM
Whoops, one more answer--both machines are x86.
If there's anything else I didn't answer, please poke me about it and I'll provide the info. Like I said, one of those mornings...
02-04-2014 10:35 AM
Evan (or anyone who's listening),
Do you have any other suggestions?
Thanks.
Sara