Cannot see all methods in the class hierarcy

[AndrazS]

I want to use .NET Load Assembly method that is defined as method from Application Class:

In this article, I also see defined methods for manipulating .net assemblies

https://labviewwiki.org/wiki/Application_class

When I open VI Class Browser in VI I cannot se this methods? Why is that? Where is .NET Load Assembly method? 

[TheQ]

That method is a Private method. See:

https://labviewwiki.org/wiki/VI_Server#Private.  If you don’t have these methods visible through the INI file flag they won’t show in the Class Browser. 

Be sure you actually want to use it as it is not meant for public use. 

[AndrazS]

In my opinion, loading .NET assembly from defined path is totally basic function and it should be public for every developer that is using Labview. 

[billko]

---

@AndrazS wrote:

In my opinion, loading .NET assembly from defined path is totally basic function and it should be public for every developer that is using Labview. 

---

To expand a bit on the TheQ's post - and to repeat what you would've read had you followed the provided link - the private stuff is private because:

They are not always fully vetted or documented. They also could change from one version of LabVIEW to the next and they might not be in the LabVIEW Run-Time Engine, (meaning they cannot be used in built executable). Use at your own risk.

To give you an example of what could happen, LabVIEW has support for Unicode as well, but it is private as well because there are some bad things that can happen to VIs in your project that are irreversible once you enable Unicode support.  Sometimes the issues can even jump to projects that you never intended Unicode support for.  So it's there if you want it, but use it at your own risk.  And that risk is now super-huge because official support is imminent, and there is every likelihood that the official Unicode support will not be compatible with the private, unsupported version.

[AndrazS]

Thanks for info.

But if I use .NET assembly without knowing from where Labivew pulls it, this is also very risky. 

Is there any way for Labview developers know from whitch location exactly Labivew takes .NET dll? In TestStand for example you can specify absolute path to dll. How this can be achieved in Labivew?

[paul_cardinale]

---

@billko wrote:

---

@AndrazS wrote:

In my opinion, loading .NET assembly from defined path is totally basic function and it should be public for every developer that is using Labview. 

---

To expand a bit on the TheQ's post - and to repeat what you would've read had you followed the provided link - the private stuff is private because:

They are not always fully vetted or documented. They also could change from one version of LabVIEW to the next and they might not be in the LabVIEW Run-Time Engine, (meaning they cannot be used in built executable). Use at your own risk.

To give you an example of what could happen, LabVIEW has support for Unicode as well, but it is private as well because there are some bad things that can happen to VIs in your project that are irreversible once you enable Unicode support.  Sometimes the issues can even jump to projects that you never intended Unicode support for.  So it's there if you want it, but use it at your own risk.  And that risk is now super-huge because official support is imminent, and there is every likelihood that the official Unicode support will not be compatible with the private, unsupported version.

---

Unfortunately, some of us will be stuck with the old Unicode support: Since the subscription model is not compatible with the way we operate, we cannot go past LabVIEW 2021.

[billko]

I'm fairly certain that my company will be frozen in time as well.

[billko]

---

@AndrazS wrote:

Thanks for info.

But if I use .NET assembly without knowing from where Labivew pulls it, this is also very risky. 

Is there any way for Labview developers know from whitch location exactly Labivew takes .NET dll? In TestStand for example you can specify absolute path to dll. How this can be achieved in Labivew?

---

Yes, but I think you're not seeing the corporate side of it.  If they hide it and tell you that you shouldn't use it, then they don't have to help you if you use it and something goes wrong.  😉