As of May 2, 2022 the LabJack forums have been set to read-only.
If you are in need of support, please contact us via one of the methods described on our contact page.
I am not very familiar with nuget. What would be the advantages to packaging this way in contrast to having our typical installer? Note that our installer requires some driver and DLL installation beyond the .NET assembly, and we currently support minimal installers with silent installation options.
What LabJack device are you using? Unfortunately, we are not doing new development for UD devices, so we most likely will not create a nuget package for UD software. We could consider adding support for T-series devices if there is a reasonable advantage over calling our installer.
The nuget package wouldn't install the device drivers, just the needed components for development in one excellent version-controlled package.
As things are not with.NET, you have to install the LabJack device drivers/libraries on the machine to build your software to get it to compile.
If you are using Azure DevOps or another build environment (Jenkins etc.), you now have to do a bunch of additional work to install the needed libraries to get the build to run. depending on your configuration, this means installing/uninstalling the lab jack software on a VM hosted by Azure (I haven't tried it, but not sure it will work as its doing a device driver install as well)
Using a nuget package published on NuGet.Org, the build only needs to reference the nuget package. The build system will download the package references (it provides version control for the packages, too), so older stuff will build and upgrade to newer updates). The device drivers don't need to be installed on the build machine, but compilation can still happen as the project will have everything it needs to compile (not run) the product/project being compiled.
It's convenient, and I could build a nuget package for my consumption, but it's always better to have it supplied by the manufacturer. Most .NET components for .NET apps are provided this way.
We recently created a test NuGet package. I attached the package in a zip below. We have not published anything yet, but we will most likely do this in the near future.
This package just provides the LabJack.LJM.dll assembly so that it can be used in build systems without all of the other LJM resources that are necessary to run. Is this all you had in mind or is there anything else you would like to see?
.png%3Fitok=PHGBxf6M "EEV Blog Reviews LabJack T7-Pro & Software Tools")
.jpg%3Fitok=B1YcuDFK)
.png%3Fitok=Ybt-OlgU "LabJack + JEDI One Can Create a Powerful Distributed DAQ Ecosystem")
I am not very familiar with nuget. What would be the advantages to packaging this way in contrast to having our typical installer? Note that our installer requires some driver and DLL installation beyond the .NET assembly, and we currently support minimal installers with silent installation options.
What LabJack device are you using? Unfortunately, we are not doing new development for UD devices, so we most likely will not create a nuget package for UD software. We could consider adding support for T-series devices if there is a reasonable advantage over calling our installer.
The nuget package wouldn't install the device drivers, just the needed components for development in one excellent version-controlled package.
As things are not with.NET, you have to install the LabJack device drivers/libraries on the machine to build your software to get it to compile.
If you are using Azure DevOps or another build environment (Jenkins etc.), you now have to do a bunch of additional work to install the needed libraries to get the build to run. depending on your configuration, this means installing/uninstalling the lab jack software on a VM hosted by Azure (I haven't tried it, but not sure it will work as its doing a device driver install as well)
Using a nuget package published on NuGet.Org, the build only needs to reference the nuget package. The build system will download the package references (it provides version control for the packages, too), so older stuff will build and upgrade to newer updates). The device drivers don't need to be installed on the build machine, but compilation can still happen as the project will have everything it needs to compile (not run) the product/project being compiled.
It's convenient, and I could build a nuget package for my consumption, but it's always better to have it supplied by the manufacturer. Most .NET components for .NET apps are provided this way.
More info here: Install and manage NuGet packages in Visual Studio | Microsoft Docs
That makes sense to me, thank you. We will mull over the option to add a NuGet package and follow up when we make a decision one way or the other.
We recently created a test NuGet package. I attached the package in a zip below. We have not published anything yet, but we will most likely do this in the near future.
This package just provides the LabJack.LJM.dll assembly so that it can be used in build systems without all of the other LJM resources that are necessary to run. Is this all you had in mind or is there anything else you would like to see?