I'm trying to build a LabVIEW plug and play instrument driver project for a device we sell. I followed the instructions to create a project, and it created the project in with the LabVIEW program:
C:\Program Files\National Instruments\LabVIEW 2011\instr.lib
I suppose I could connect that folder to source control and just do all the work there, but it feels weird to be working under Program Files. When I tried to move the project folder out into my regular workspace folder, it broke all the subpalette files (*.mnu). I could recreate them, but I'm afraid they wouldn't work for our customers when they install the driver from the LabVIEW web site.
Is it possible to move a driver project around, or does it have to stay in the default location? If one of our customers has installed LabVIEW in a different location (say on drive D:) will the driver menus not work for them?
I'm not in favour of user.lib for SCC'd items. using several LabVIEW versions at a time is a big problem.
Here is my routine:
Create the instrument library and save all code in a folder starting with an underscore ('_') (_foo)
Create an .mnu file in the parent folder of '_foo' Mylib.mnu, add the icons you need.
With OpenG package builder I create an installer routine that placed the the mnu file and the folder in instr.lib
After a restart of LabVIEW the instrument driver shows up in the instruments palette.
If you keep the code in the same relative position to the mnu file there is no problem with missing VIs.
Ton
Instrument drivers are always located in the 'instr.lib' folder in the current LabVIEW version folder. There is an environmental path set up in LabVIEW for this intrument driver folder so it will always point to the correct drive for the installation of LabVIEW used.
You should keep the folder in the location used by the wizard to ensure that when distributed to your customers the sub palette menus point to the correct location and all the VIs link correctly.
I use source control for user.lib which is in a similar location and have no problems.
Related
I currently working on an Altera FPGA. In this project, we were given only the soft software source code using Nios II Software Build Tools for Eclipse I like to run and build the original code before making any changes to it. However, only a .pof programming file and a .cdf file was given to us, so when setting the Hardware design setup, please correct me if I’m wrong, I need the SOPC file and .sof file to configure the hardware?. I tried using the .pof or .cdf files in some way but with no success. Is there a way I can compile and build this application somehow using the .pof file or other way and thus be able to create a bsp project and load the .elf file to the FPGA. Or do I need this .sopcinfo and .sof files. Thank you.
I'm currently working through some Machine Learning tasks using Eclipse and PyDev.
This requires access to some large datasets of ~10K images. I didn't want to copy these large folders into the workspace, so the 'neat' solution seemed to be to import them as Eclipse 'virtual' folders (i.e. a link).
Several hours of processing later, this seemed to have worked...however, when I then try to access the virtual resources I generate:
FileNotFoundError: [WinError 3] The system cannot find the path specified: '\\default\\training_set'
After stepping through, it became clear from using os.listdir() that whilst Eclipse may show virtual resources as being locally addressable, Python does not (shattering my vague assumption this would all be automatically handled by Eclipse).
My question is, within the PyDev environment, is there a way of using this functionality - or do I have to either fully import all my resources or use absolute file paths
I have a Java rich client desktop app. that I want to distribute on some computers at work, but I've never done something like this before. People aren't too computer-savy at my workplace and since it is a student job, I won't be there for much longer and I'd like it if I could make my program easy to run by making it runnable when people double-click on it.
I also don't want to have to manually install a JRE to have it run. Basically, what I'd like to know is how to make my java application runnable easily by double-clicking (even if it's only on windows, it's okay). I'm pretty sure I'm going to need to package the correct JRE version alongside, but I don't know what's the correct way of doing this.
I read on some sites that you should not package a JRE along with your program because it makes people have multiple different versions, some of which are outdated, and it causes security issues, but this is not a problem in this case since the computers that are going to run my application are not connected to the internet and are only used to run this program anyway.
Somewhat related question: Since my application is currently an Eclipse project, I get my resources such as icons, images, SQLite database (for read and write), etc. using relative paths (e.g.: img/test.png).
Am I going to have to change any of those paths to have them keep working even while packaged?
What you're looking for is a JAR file. In eclipse, it's quite easy to make a Jar file. Specifically, you'll want to right click on your project, go to Export, and then select "Runnable Jar." Be careful with paths to folders. You may need to keep a resources folder next to the Jar file. You may need to provide some more specifics to get an exact answer on that. Typically, a Resources folder is located in the same spot as the JAR file (in the same folder on your computer).
A better option for easy install of a Java app. with a GUI is to launch it using Java Web Start. For the user, JWS is the 'one click' installation option that can (install & launch the app. then) add desktop shortcuts and menu items. A JWS launch would mean some more work for you, but it is a breeze for the end user.
To ensure a suitable JRE is present to run the app., use deployJava.js (see the JWS link for more details). The script would need to be reconfigured to get the JRE installer from your local network - the default is to get it from Oracle.
Most of the resources should be packaged in Jar files and supplied along with the app., but for the DB, use the JNLP ExtensionInstallerService to call the DB installer.
..Java Web Start is kind of a link (or I can make it a shortcut on the desktop) that the users will click to either install the JRE and run the program if the JRE isn't installed, or just run the program if the JRE is present on the computer.
The way it would work is to have a web page on the local intranet. When the user visits the page, the script checks for a suitable JRE.
If it is present, it writes the link to the launch file.
If there is no JRE, or the version is too low, it will guide the user through installing it (just a matter of them clicking 'OK' when prompted). Then it will put the link to the app.
I can then configure the link to grab the JRE from the server on our network.
That's the part where you need to reconfigure the script. AFAIR the script exposes an URL at which to look for JREs - that can be changed to point to a place on the intranet.
..So "Web" is only just in the name, the computers don't have to be connected to the internet to have this work, right?
Yes. JWS is a great launch technology for Java rich clients, but is a poorly chosen name.
To make the problem run by double clicking it you can distribute it as a jar file or a batch file to call the jar file.
For the installation part you can make a batch file that checks if java is present and then call the installer if it isn't.
Edit:
The batch code:
IF DEFINED JAVA GOTO ok
java-installer.exe
GOTO end
:ok
your-application.jar
:end
If you are finding it tough to implement the above mentioned methods. You can proceed with this simple approach.
Create a folder lib at a location. Place all the jars that your application uses into this. If you are able to create a jar for your application, you can very well place your application.jar into the lib folder too. Create a batch file at the same location that will contain the java command for your main class in it. The text within your batch might look something similiar to this :
set path="\lib\"
java -cp %path% package1.package2.MainClass
If you have any other dependencies, for ex: if you use images in your code under img/icon.jpg. Then you just have to shift the img folder to this location too.
Just zip these files using winrar and share it across. Running the batch file after extracting the zip would launch your java MainClass irrespective of the location in which it is placed in the client system.
PS : If you are unable to create a jar for your application and placing it in lib folder, just copy your bin folder with class files and paste it in the location and change the batch file accordingly to look for classes inside bin.
I'm trying to port my entire 'workspace' to a USB key (including the Eclipse executable) so that I can carry my work anywhere with me and work off the key directly.
My directory hierarchy is similar to this:
/workspace/eclipse - Where my current eclipse binary is stored
/workspace/codebase - Where I keep the root of all my eclipse projects
/workspace/resources - Where I keep all project files (images, docs, libs, etc.)
It all works perfectly fine on one system. But when I change over to another system, the USB key gets mounted on another drive. For example, on my laptop, I get 'E:\', on my PC, I get 'K:\' and at work I get 'F:\', etc, etc.
This means that because Eclipse (for 'some' reason) seems to only use full path names (including driver letters) in every single one of its configuration files (such as .classpath), nothing ever works when I want to work on another system.
I put a 'libs' directory in the base of every project and populate it with its dependent JAR files. Why doesn't it use relative names instead, so that I could specify something like "../../libs/log4j.jar"?
Anyone know how to fix this problem? Does anyone know of a workaround for this?
Update: 2010.11.09
I've recently discovered Dropbox, which allows you to sync your files online and across your computers automatically with extreme ease. It includes 2GB of free space and you can upgrade to much more if you want (for a yearly fee).
I installed it on my two laptops, my two PC's, my Linux server and my Android phone and then I created a 'workspace' directory within the 'My Dropbox' folder. From the 'workspace' directory, I then installed Eclipse and created/configured all my projects as usual. I can literally work from any computer and everything always stays perfectly in sync. This is way better than any USB key functionality and its hassle!
Have you tried using Eclipse Portable?
The only thing to keep in mind is that when switching the workspace, you need to remember to give it a relative path (like ../../Data/workspace).
You could use the dos command subst to get a consistent drive letter by creating a new virtual drive letter (say x:) that maps to your Eclipse folder on your usb drive, and then make all the config paths reference the drive x:
You could make a little batch file on the usb drive that you click on to create the drive x:
C:\>help subst
Associates a path with a drive letter.
SUBST [drive1: [drive2:]path]
SUBST drive1: /D
drive1: Specifies a virtual drive to which you want to assign a path.
[drive2:]path Specifies a physical drive and path you want to assign to
a virtual drive.
/D Deletes a substituted (virtual) drive.
Type SUBST with no parameters to display a list of current virtual drives.
You could also remap letter for your USB stick in Windows Disk Management (subitem in Computer management) to be smth like 'U:'.
Once done, it will be re-assigned to same stick every time you plug it. Not very universal, since your user need rights to access this setting first time, but it could help in some different scenarios.
You can always use Ant to build your programs, with Ant you can have relative paths... Plus you can also use Ivy to track dependencies in Ant, I do that in every project that I have.
Another alternative is to manually edit your .classpath files to contain relative paths.
It is a bit of a hassle, though, as you'll have to manually update the files whenever Eclipse changes them.
My team is developing a new DotNetNuke web application and would like to know what is recommended to setup a development environment with source control and automated builds? We would like to keep the DNN source code separate from our custom modules and extensions source code.
The DotNetNuke Compiled Module template for Visual Studio wants us to store the source code in the DesktopModules directory of the DNN source code and output to the DNN source code bin directory. Is this the recommended structure? I would rather keep the files in different locations, but then it becomes more difficult to run and debug locally as it would require an install of the module for each change. Also, how should an automated build deploy any changes?
How have others set this up? Is there a recommended best practice?
For my source control, I develop modules in their own project. This contains the module code, test code, data provider code (if applicable) and anything else. This is checked into source control like any other project. Note that the module project contains no links to a specific DNN website, and DNN references are made in the project to a common "bin" directory that references your target build. For example, in my projects folder, I have \bin460 , \bin480, \bin510, \bin520 etc. Each of these folders holds a set of binaries for a specific DNN version. That way you can build against a particular version but test against any version you like.
The problem with source-controlling a module in place in a dnn install is
- sometimes not all of the module code is easily isolated under a single parent directory
- doesn't lend well to a PA module approach
- not easy to shift the project to a different DNN Version for development or testing
- easy to inadvertently source control parts of the DNN solution, particularly with integrated VS source control solutions.
This approach compiles quickly because you're not trying to compile the entire project. For test deployment I have a build script that copies the various parts of the module into a target website. This can be done via the compile (link the build script) or just run after you've had a successful compile in a cmd window. My build script has a 'target' environment switch, so that I can say 'dnn520' to deploy the build to my test dnn520 install. Note that you need to manually create the module configuration first before this will work, but this is a one-time effort, and you can use the export feature to create your .dnn module manifest.
To build your module package, invest the time in a comprehensive script which will take the various parts from your source directory, and zip them into an install package. Keep all of the parts in your source control folder, and copy them into a temp directory, then run a command-line zip utility (I use an ancient version of pkzip) to pack it into an installable file.
The benefits of this approach is :
- separation of module code from installed code
- simple way of keeping only the module code in source control (don't have to exclude all the website code)
- ability to quickly test out modules in different dnn versions
- packaging script allows you to quickly and easily build a new version of a module for install testing/deployment
The drawbacks are
- can't use the magic green 'go' button in VS (have to manually attach debugger)
- more setup time than developing in-place
We typically stick to keeping the module code in a folder under DesktopModules and building to the website's bin directory.
In source control, we just map the individual modules, rather than the entire website. Depending on what we're working on, a module may be an entire project in source control, or we may have multiple related modules in the same project, living next to each other.
Automatically deploying changes is somewhat difficult in DNN. It's highly recommended to have a build script that packages your module into an installable form. You can then copy installable packages into the website's Install/Module folder, and get the URL /Install/Install.aspx?mode=InstallResources, which will install any packages in that folder.
In response to bduke's answer. You should, and don't want to build projects in the DesktopModules folder.
That's where all of the source code for the site out of the box goes.
That's where you modules will be "installed" and thus if someone "updates" or re-installs one, then it will be overwritten
It can make upgrading your Application far more difficult. Many developers don't understand that the idea of not touching the original source code files to modify their behavior. BECAUSE it will just be overwritten when you perform an upgrade.
If you want to build modules, create a solution folder called Modules and place your seperate project modules there.
If you want to debug them, make the target debug output point to the web\bin folder.
If you want to install/deploy them. Build it in release mode and install them through the Module/Extension filter.