EXE with new DLL is unable to run on runtime machine

[rolfk]

---

@christoph84 wrote:

With LabVIEW there is so often something that doesn't work. This is one reason why we now start most new projects with C# or Python and want to get rid of LabVIEW in the long term.

---

Good luck with that. C# or Python have exactly the same problem!

[christoph84]

---

@rolfk wrote:

---

---

Good luck with that. C# or Python have exactly the same problem!

---

Of course, like every programming language. But none of them have the same high licence costs as LV.

Community support is also better. You can find a solution to most of your problems on the internet, which is more difficult with LV.

But enough off-topic. I would still be happy if someone had a solution for the .NET DLL problems.

[rolfk]

---

@christoph84 wrote:

---

But enough off-topic. I would still be happy if someone had a solution for the .NET DLL problems.

---

We still don't know any specifics other than that it is "some" .Net DLL. With that much of information it is absolutely impossible to give any more advice besides the generic advices you already received.

What is the build setup for the DLL?

Visual Studio version used?

Windows system and version?

3rd-party dependencies?

Pure IL assembly or mixed mode? 

What .Net Framework version is targeted when building it?

When was the assembly originally developed, what Framework did it target at that point?

[christoph84]

The only things I definetly know is that it targets .NET Framework 4.8 and that it is shipped with a single dependency that is also a .NET 4.8 DLL. And this has not changed since the first version of the DLL.

LV 2023 can load it, LV 2025 can't. And this is independed of the version of the DLL. We get a new version every few months and none of them are working with LV 2025.

I would like to understand what has changed between LV 2023 and LV 2025 so that it no longer works.

Unfortunately I am currently not allowed to share the files so that someone else could investigate that issue.

[Yamaeda]

Didn't LV2025 change to .NET8 or something?

[rolfk]

---

@Yamaeda wrote:

Didn't LV2025 change to .NET8 or something?

---

No! It started supporting .Net 8 assemblies, but the default is still to target .Net Framework assemblies. The selection if LabVIEW should invoke the .Net 8 system or rather target the .Net Framework when trying to load the assembly is an option that you have to select on the Constructor Node through a popup menu choice.

And .Net 8 support is still under development, meaning it may work for some .Net 8 assemblies but by far not all.

So yes there is a chance that LabVIEW does now have a slightly different code path even when targeting the .Net framework and that that might for instance disable certain depreciated features. Or that there is a real problem there, or that the difference is something entirely different. Without knowing more about the actual assembly and being able to do some low level debugging, this is not likely going to be solved other than by chance.

[BlackSupra · Accepted solution]

The problem is that on the other macine the DLL is blocked therefore the LV can't access it which results in error durion application (exe) startup. The solution is simple:

1. Right click on DLL

2. Select properties

3.On th bottom below the "Attributes" section is new section "Security".

4. Click on the checkbox and apply the settings.

DLL is no longer blocked and the APP wil now work as intended.