Jump to content

Using VIPM to distribute drivers using an unsigned .NET framework

Recommended Posts

Hi all,


I have been trying to use VIPM to distribute drivers that rely on a .NET framework that is unsigned (i.e not in the global assembly cache).  My issue is that after the package is installed, none of the VIs will work because LabVIEW cannot locate the .net assembly.  However, if I launch labview by opening the library VIPM installed, all of the VIs will work, and LabVIEW is able to locate the the .Net framework and it appears in the main application instance.  I need to be able to use the installed vis all the time, not just when LabVIEW is launched in this particular way.


Here is a link to all the all the files I used: 




Here are the steps I went through:


1) We put all the .NET dlls and the LabVIEW.exe.config file in the Labview directory.




2) We installed the package on our computer.  




3)We closed everything and relaunched Labview from the start menu.  Then accessed the BioRobotics/Vicon palette.




4)We placed the Get Ref subVI on the block diagram, opened it up, and ran it it.


5) We got the following error:




We also get a similar error for any VI that uses a method associated with the .NET dll.


6) However, if we again start with everything closed and launch Labview by clicking on the VICON.lvlib located in the vi.lib




7) Then repeat steps 3 and 4.  We do not get any errors in the VIs on the palette, and the .Net assembly loads fine.  We can even close the library and everything still works.  Somehow opening the library first makes LabVIEW know to load the ViconDataStreamSDK_DotNet assembly when using functions on the Vicon palette.




If anyone does attempt to build a new package, it is worth noting that I included the dlls in the source files, and in the same folder as the vipb:









Edited by Callan
Link to post
Share on other sites

Are the .NET assemblies referenced in your project library in the source of the component prior to building a package? 


I have several components that use .NET assemblies - I have never copied them to the LabVIEW folder when changing source; they have always been in the source project folder or sub-folder. LabVIEW effectively adds this folder to the Fusion search paths when resolving assembly locations.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By dadreamer
      I want to remind once again that all this information is just to have fun playing with LabVIEW and not intended for real projects use. I believe you all understand that. 🙂
      Not that a big opening here and even not an opening for some ones, but I found this interesting enough to make a thread. As you may already know, when some library is being called using CLF Node, LabVIEW enters ExtFuncWrapper first to do some guard checks to prevent itself from a silent crash and output some error message to the user instead. I've always considered that wrapper boring enough to study, thus never looked inside. But when once again I faced that I can't call some function through CLFN and have to write my own wrapper library, I asked myself why we cannot call some code by its pointer as in almost any well-known text language?.. Therefore I decided to know how ExtFuncWrapper calls the function. It turned out that ExtFuncWrapper receives the function's pointer (along with the parameters struct pointer) and calls that pointer later as it is (i.e., not doing any manipulations with it). So we can use it to call any function and even any code chunk directly from the diagram! After further research I found ExtFuncWrapper not very convenient to use, because to bypass some checks the parameters struct should be prepared accordingly before the call. But there are many ExtFunc... wrappers in labview.exe and ExtFuncCBWrapper is much easier to use. It has the following prototype:
      int32_t ExtFuncCBWrapper(uintptr_t CodeChunk, int32_t UseTLS, void *CodeParams); Here CodeChunk is our func / code pointer, UseTLS is 0 as we don't use LabVIEW's Thread Local Storage and CodeParams is our parameters struct. When called ExtFuncCBWrapper runs that CodeChunk, passing CodeParams to it, so we can freely use it later to do what we want. Nuff said, here are the samples.
      This one increments a Numeric.

      As you can see, I'm passing a Numeric value as CodeParams pointer into ExtFuncCBWrapper and in the assembly I have to pull that pointer out to deal with my parameters. I'm not that excellent in asm codes, so I used one of many online x86 compilers-decompilers out there. It's even simplier in 64-bit IDE as the first parameter is already written into RCX. Okay, here goes a more advanced example - it calculates a sum of two input Numerics.

      Here I'm passing a cluster of three parameters as CodeParams pointer (two Numerics and the resulting Sum) and in the asm I'm grabbing the first parameter, adding it to the second one and writing the result into the third one. Pretty simple operations. Now let's do some really wild asm on the diagram! 😉 The latter example calls MessageBox function from user32.dll.

      This is what Rolf calls a diagram voodoo. 😃 I have to provide 4 parameters to MessageBox, 2 of which are string pointers. Thus I'm getting these pointers and writing them into my params cluster (along with the panel handle and the dialog type). When ExtFuncCBWrapper is called, in the asm code I have to use the prologue and epilogue pieces to prevent the stack corruption as I'm pushing 4 parameters later onto the stack to provide them to MessageBox. After the call I'm writing the result into the function return parameter. In 64-bit IDE the prologue/epilogue is somewhat simplier.
      Maybe you already noticed that I'm doing VirtualProtect before calling ExtFuncCBWrapper. This is done to pass through Windows Data Execution Prevention (DEP) protection. I'm setting execute and read/write access for the memory page with my code, otherwise LabVIEW refuses to run my code and throws an exception. Surprisingly it is thrown only in 64-bit IDE, but in 32-bit LV I can just wire the U8 array to ExtFuncCBWrapper, not going through that DSNewPtr-MoveBlock-VirtualProtect-DSDisposePtr chain. I did not start to figure out such a behaviour.
      Well, to be honest, I doubt that someone will find all these samples really useful for his/her tasks, because these are very low-level operations and it's much easier to use a common CLFN or a helper DLL. They are here just to show that the things described are definitely doable from an ordinary diagram, and that doesn't require writing any libraries. With a good asm skills it's even possible to realize callback functions or call some exotic functions (like C++ class methods). Some things might be improved also, e.g. embedding a generic assembly compiler to have a possibility to write the codes instead of raw bytes on the diagram. Ideally it's even possible to implement an Inline Assembly Node. Unfortunately, I have neither the time nor much desire to do it myself.
    • By javier_r
      VIPM.io now allows you to post LabVIEW Resources, Ideas, and Tools. For example, you could post a link to a video tutorial or blog article about a package. You can also post ideas, like feature requests or new tools. Best of all, package developers are notified when you post your ideas and resources, and you can comment and discuss posts with the community. Take a look at this video to learn more: https://www.vipm.io/posts/664960df-f111-4e13-989a-24be8207182d/

    • By javier_r
      Hello everybody!
      Wondering how many people have tried the new vipm.io site. We have added a ton of features to make it easy to Discover LabVIEW Tools and there are some cool ones coming soon.
      Check it out and let me know what you think 😀

    • By bartek618
      I know how to run .Net executable by MainWindow() constructor but I have some resources defined in App.xaml and MainWindow() doesn't run without them. How to run application starting with App() constructor? Also I need to pass some parameters into MainWindow().
    • By dblk22vball
      I am using the newest version (2020.1) of VIPM, but I had this same issue with the release of 2020.
      For two of the packages that I have created for internal repos, VIPM has decided that I need a System Package.   The posts I have seem from JKI indicate that this is a sub-package that is used internally to the main package, and should be automatically included.
      However, after I am seeing issues on any PC other than the PC where the package was built.
      Is there a setting I am missing?
      Showing the (System) package as a dependency:

      Package Configuration in the VI Package Configuration Editor

      Package installed, on the PC where the package was initially created (no issues, no exclamation mark)


      Package when installed on another PC (NOTICE: the System Package name has changed and there is a red exclamation mark, but there are no errors shown on install of the package).


  • Create New...

Important Information

By using this site, you agree to our Terms of Use.