Measurement Studio for .NET Languages

cancel
Showing results for 
Search instead for 
Did you mean: 

unable to find module dependency with signature

Solved!
Go to solution

Hello:

 

I am using Visual Studio 2008 sp1 and C#. The program works great in the development environment and as a stand-alone .exe in the development  machine and one other in which there is also VS 2008 sp1 installed. But if I try to run the program as a demo on another machine without VS2008, it gives me a module not found message as soon as it starts. If I delete references to AIChannelCollection and ChanType, the program loads without error. It does not matter if the target machine has MAX on it or not. All machines are Win 7. I am not actually using Measurement Studio, but it seems that the classes are somehow associated with it. It looks like the program generates the error as soon as it calls a method with ChanType or AIChannelCollection in it.

 

I do also get a warning on build of the setup project:

Unable fo find module dependency with signature 'Microsoft_VC90_CRT_x86.0138F525_6C8A_333F_A105_14AE030B9A54

 

In my C:\Program Files (x86)\Common Files\Merge Modules directory, I do indeed have Microsoft_VC90_CRT_x86.msm present.(589kb, 3/15/12)

In the Detected Dependencies, I have:

Microsoft .NET Framework

microsoft_vc90_crt-x86.msm

mstudiocommon.2008.msm

mstudiodaqmx.2008.msm

 

I tried adding policy_8_0_Microsoft_VC90_CRT_x86.msm, then policy_8_0_Microsoft_VC90_CRT_x86.msm to no avail. The warning persists no matter what I do and the program will run fine on a computer with VS2008, but not otherwise.

 

Please help.

 

Thanks.

 

Tom

0 Kudos
Message 1 of 7
(8,076 Views)

It looks like AIChannelCollection and ChanType are DAQmx functions. Have you to appropriate version of DAQmx installed? Also, does this build work on another machine? Perhaps try replacing the copy of Microsoft_VC90_CRT_x86.msm with one from a machine on which the error doesn't occur.

 

Regards,

 

Brandon V.

Applications Engineer

National Instruments 

0 Kudos
Message 2 of 7
(8,027 Views)

Brandon: Yes, they are DAQmx functions, and I do have the correct stuff installed so far as I know - otherwise it would not compile. My problem is that somehow the setup is not finding all the files to include in the msi package. Worse yet, Microsoft just did a bunch of updates and now there are two Microsoft_VC90_CRT_x86.xxxx warning messages! I am not even using C - I am using C#. This is being requested by NationalInstruments.Common, actually, but I have no way tell why it is missing something or what I need. The "signature" is gibberish to me.

 

To summarize the problem: When I try to make an .msi, NI's NationalInstruments.Common (2008 version) is calling for files neither I nor VS2008 can find.

 

Thanks.

0 Kudos
Message 3 of 7
(8,019 Views)

You should try to compile one of the DAQmx shipping examples and see if you get the same error. If that works, create a new project with just the functions you believe to be the culprits.

0 Kudos
Message 4 of 7
(7,946 Views)

I actually tried several files. They all compile fine. The issue is when I go to make an installer setup.exe + *.msi package. That is when the warning messages show up. The issue seems to be that the Microsoft_VC90_CRT_X86. ... files have the wrong signature. I have no idea how to check signatures or how to find a file with the correct signature. The files are present, but apparently with wrong signature. Then when I try to install on another machine without VS2008, the application crashes (apparently) due to the missing dependency. It looks like there is a problem with a relationship between NI supplied files and Microsoft supplied files. Note: There is an NI note about this, or something like it, caused if you are not using SP1. I am using SP1. Thanks.

0 Kudos
Message 5 of 7
(7,912 Views)
Solution
Accepted by topic author Tom98765

This issue was solved internally. For reference:

 

The Measurement Studio merge modules have a dependency on the Visual Studio merge modules. We (NI) have to give a specific signature and version of what our modules depend on (e.g., we can't say something like "we depend on this wildcard signature with this wildcard version; this is a restriction at the Windows Installer level). What sometimes happens is this: 

1. Microsoft rolls out an update that changes the module signature of the MSMs that we are depending upon (e.g,. this is bad to do since its breaks existing clients like use)¿ 
2. When Visual Studio goes to create a setup project, it looks at our MSMs ModuleDependency ¿and it tries to locate those MSMs. The problem is that the updated Microsoft Visual Studio MSMs have a different signature/version and thus Visual Studio can't locate those MSMs. Thus the Visual Studio MSMs don't get included in your setup project. 

So essentially, there was some sort of Microsoft update (probably to VS 2008 SP1) that updates the modules that our DAQmx merge modules depend on. As such, the old dependencies no longer exist, so the Setup Project creates a warning and eventually fails when we try to run it on a target computer. There's also a forum linked below that addresses this issue in case you'd like more information or need another version of merge modules: 

http://forums.ni.com/t5/Measurement-Studio-for-NET/Problems-building-InstallShield-installer-after-u...

 

 

0 Kudos
Message 6 of 7
(7,862 Views)

In light of this issue, I suggest the following:

NI should supply a chart with dependent files, names, dates and signatures. My suggestion is based on the idea that given a warning that a dependency does not exist, one can examine the warning message and simply select the correct file by name and signature. Without a signature, there is no easy way to know which file to use since there are simply too many VS versions, NI .msm versions, Windoze versions and general Microsloppy updates and upchucks.

0 Kudos
Message 7 of 7
(7,859 Views)