From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Measurement Studio for .NET Languages

cancel
Showing results for 
Search instead for 
Did you mean: 

Compile error LC : error LC0000: 'Could not load file or assembly

I get this error when I try to compile:

LC : error LC0000: 'Could not load file or assembly 'file:///C:\Program Files (x86)\National Instruments\MeasurementStudioVS2005\DotNET\Assemblies\Current\NationalInstruments.UI.WindowsForms.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format.'
Done building project "InternalCommon.csproj" -- FAILED.

I tried to uninstall, reinstall, update the licenses, etc with no avail.
0 Kudos
Message 1 of 42
(23,414 Views)
Hi dtorg,
 
Are you running on a 64bit processor?  This error can occur when doing so.  Refer to the Measurement Studio help under the heading: Licensing Measurement Studio .NET Class Libraries on a 64-bit Operating System  This will give insight into getting rid of this error.
 
Regards,
jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 2 of 42
(23,401 Views)
Also check out the help topic "Using Measurement Studio on 64-bit Operating Systems" in the Measurement Studio help. We'll make sure that these two topic cross reference each other in a future version of Measurement Studio and we'll make them easier to find if you search for them based on the compile error that you reported.
0 Kudos
Message 3 of 42
(23,397 Views)
I have been successfully compiling my application on my 64bit OS using 8.0.0. I have removed the "Any CPU" configuration from my project and made them all x86. So the 32bit LC.exe should run in all cases. But at some point after I reset the licenses after switching to 8.0.1, I am no longer able to compile. I am about ready to give up and switch back to a 32bit OS.

Any other suggestions?

Thanks,
Dave
0 Kudos
Message 4 of 42
(23,390 Views)

Did you do the following, as suggested in the topic that Sam referenced?

To work around this issue call C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\ldr64.exe setwow in the prebuild step of your Visual Studio 2005 project, and call C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\ldr64.exe set64 in the postbuild step of your project.

0 Kudos
Message 5 of 42
(23,386 Views)
I didn't try this because I have the only 64-bit developer WS in our team. The rest are 32-bit. I am not sure how to make sure they can still compile.

I still don't understand what has changed as I had been working well before and it should work ok in the x86 configuration without these pre-post commands.

Regards,
Dave
0 Kudos
Message 6 of 42
(23,389 Views)
Our testing has shown that lc runs as a 64-bit application when Visual Studio executes it on a 64-bit OS, regardless of the target platform of the project Visual Studio is building. That is, even when you are building a 32-bit application, Visual Studio runs the 64-bit version of lc. We worked directly with Microsoft support and they confirmed that this is how lc and Visual Studio behave.
 
We think that this is a bug and have been encouraging Microsoft to fix it in a future version of Visual Studio.
 
I don't have a theory as to why it worked on your machine before and doesn't work now. Did something else change on the system or with the project you are building?
 
To make it so that you can build the project on a 64-bit OS or on a 32-bit OS, use IF EXIST to conditionally execute the pre-build and post-build steps, based on whether ldr64.exe exists on the system. So, your project pre-build step would be:
IF EXIST C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\ldr64.exe C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\ldr64.exe setwow
Your project post-build step would be:
IF EXIST C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\ldr64.exe C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\ldr64.exe set64

 

I tried this on my 32-bit OS and was able to build without error.

0 Kudos
Message 7 of 42
(23,373 Views)
Any plans on scrapping that legacy unmanaged code so you can provide native 64 bit and clickonce support?
0 Kudos
Message 8 of 42
(22,979 Views)

We have plans to provide 64-bit support. However, we have not seen a great deal of demand for it to date. Additionally, we plan to support 64-bit Vista and not 64-bit XP. This is mainly due to the differences in driver requirements and also due to the fact that we have not seen adoption of XP x64 by many of our customers. We believe we will see greater adoption of 64-bit OSs in the future (when XP will not be readily available for new systems). Hence the decision to move forward with Vista x64.

It would be useful for us if you could provide some information about your needs.

Do you see yourself moving to Vista x64 in the future?

Which components/class libraries/drivers in particular, do you want 64-bit versions of?

Why do you want to write 64-bit applications? Does your application demand the additional memory space? If so, can you briefly describe your application?

I think I mentioned this in another thread, but we don't consider all of our unmanaged code to be legacy. There are good reasons to have some unmanaged code. The best example is the analysis library. We get huge performance improvements by relying on the Intel Math Kernel Libraries, which are by nature unmanaged.

0 Kudos
Message 9 of 42
(22,961 Views)

Hi,

I met the same problem. Actually, I added the prebuild and post build command. But it produced an error as I ran the commands. It returned an exited code -1.

Then, I used a DOS prompt in Vista x64 and went into the folder to run the 'ldr64 setwow' directly. It is also failed.

My system is running Vista x64, Visual Studio 2005 , updated to SP1 and also installed the VS2005 upgrade for Vista. I'm running Measurement Studio 8.1.1.

Any idea on what happened?

Michael

0 Kudos
Message 10 of 42
(20,858 Views)