Deployment of Web Application Reference Problem

[Edna-S]

What is the service request number that you have with us?

I run your code, and it runs on my computer. The 13.0.40.188 in my computer is at  C:\Program Files\National Instruments\MeasurementStudioVS2010\DotNET\Assemblies. But if you don't have Measurement Studio VS 2010, you don't need to have the 188 version.

[Yltsä]

Dear Edna,

I do not have 188 in the develpment computer.. or in the computers which have DAQmx 9.7.5. But 188 is needed in the computers, into which I install the Setup.msi without DAQmx. That is the problem.. I do not like to install 188 separately. It should work without..

The Ni service request reference is #7392676.

BR,
Ilkka

[PTerro]

Hi Yltsa,

I just wanted to let you know that myself and one of my collegues are currently working on your service request, trying to recreate your issue on a fresh Windows 7 computer that we just reimaged.  We will let you know when we get more information.

[gremlm]

We are facing similar issue. Before installation of the f the NI Developer Suite 2013 DS2, we had some .NET dlls with version 13.0.40.242.

After install of the NI Developer Suite 2013 DS2 the  "newer" version became 13.0.40.190!

How come?

With what service pack the 13.0.40.242 version was associated?

Take a look on the directory structure represented on the attached picture. The recently installed directory is one related to the 13.0.40.190 version!

13.0.40.242 was installed in June!

[Yltsä]

Hi Gremlm,

Your case is not the same. Please check the content of your 190 and 242 folders; there are not the same assemblies.

You can see a collection of all the latest assemblies in the "Current" folder.

BR,

Ilkka

[Yltsä]

Hi,

I got help from NI customer support some time ago which solved the installation problem! 🙂 I share it here:

Dear Mr XXX.,

after  a while I got some news from the product  support engineer (PSE)
Even the assembly with version 188 isn't referenced. LabVIEW tries to load this one.
I quote his response:


I have tracked this issue down to an assembly loading error.  It appears Windows tries to use NationalInstruments.Common 13.0.40.188, doesn't find it, finds NationalInstruments.Common 13.0.40.190, and finally fails to load it.  I have confirmed that installing NationalInstruments.Common 13.0.40.190 to the GAC fixes this issue.  So, for the time being, we have the ability to run the deployed application.  However, we (R&D) need to do more investigation to figure out why the policy/configuration file combination is not successfully redirecting in this case.
 
If your customers are not opposed to installing assemblies to their GAC, they can actually modify the merge module .wxs files included in the All Libraries WiX examples.  To do this, you can follow the instructions in the comments at the top of each merge module's .wxs file.
 
The error the customer is receiving is referring to the NationalInstruments.Common assembly. To resolve this issue, we can have the setup project install the 13.0.40.190 assembly to the GAC. We will do this by editing the Common.wxs file.

You'll notice the comment above these WiX elements, <!-- Remove the ConfigurationData lines that do not have Value="$(var.RetargetableDir)" to install to the GAC.-->, which instructs you to remove <ConfigurationData /> elements to perform a GAC install.  If you follow this instruction, you will end up with the following set of WiX elements:

<?if $(var.Platform) = "x86"?>
      <Merge Id="MStudioCommon40" Language="1033" SourceFile="$(var.MergeModulesDir)\MStudioCommon.2010.msm">
        <ConfigurationData Name="_E1D16D911EAA4508BEFA56CB5FD44D63.039160C5A7A24C49AD122694436A47BB" Value="$(var.RetargetableDir)" />
      </Merge >
<?endif?>

Kind regards,
XXX