I need to know how to make a software in Visual Studio(VC++ or VB) that can be run from a USB pendrive?
Is there anyway i can create this standalone software that doesnt need any installation in the PC in which the USB is plugged into?
Just save the executable on the drive. All referenced dlls also need to be stored there. If you have code access active you also need to make sure that the drive is allowed to provide executable code.
One more thought: If the system is linux ore mac then you should consder to switch to Java to be platform independend.
Yes, any native code application can run from a pen drive (so long as any dll's or associated files are also stored with it). .NET apps can also run... if the machine has the necessary run times installed.
Related
I have a W2K8 box running some automation software.
Once of the drivers that I need to load for it adds a dll into a sub-folder of the program (in Program Files (x86)).
When the program tries to load the driver it spits out an error that it can't find the file. The location that it is looking for the file is correct and if I browse to that location the file is definaelty there.
Other drivers that use similar techniology (i.e. dll's in that same folder) are working fine, in that they find there dll and load up.
If I install the software on a XP/Win7/W2k3 OS it all works fine for the driver in question.
Is there something funky that the OS is doing that is not making the file visible to the program. The account that the servive for this program is running under is an admin account, the same account that I am loggedin with on the console.
I am told that the drivers are all C++ based drivers if that makes any difference.
Thats for any leads
Mick
Just off hand, it sounds like a permissions issue. That the application in question doesn't have access to the Program Files folder. Is this something you have checked? If not, I would start there.
I have program that uses a dll to make my device work. The driver for this device is installed on other computers.
My program works properly on my computer, but if I try to install it on another computer the dll no longer functions correctly (dll method can not find device).
But!, If I'm rebuild the program on the failing computer it works well.
What the reason of this behaviour?
Why it start work properly only after rebuilding ?
It could be binding to a different set of dlls that it is dependant on one one computer but these could be different (but compatible) on the other target machine, a recompile would mean that this code then linked against a different library version and functioned.
This is however a best guess as the question is not reall answerable in its current form
The application I'm working on has simple functionality, but has one requirement that's giving me trouble. The application will be run from a thumb drive, and requires access to write a file to said thumb drive, so browser-based javascript/html is out.
My ideal goal is to have a single script that can be double clicked from mac's finder or windows explorer that will kick-off the update of this file that is stored on the usb drive. Is this possible?
I've come across similar questions (OK Programming language from USB stick with no installation), but everything I've found would still require separate starting points for each script. For example, if I put Lua binaries on the usb stick I will have to have a separate script for each platform I want to support.
i really think it's not possible. otherwise, JAVA, Adobe Air and other platforms wouldn't have been created in the hope of a cross-platform language. besides, mac, linux and windows have different "executable" file types.
how bad can 3 (mac, windows, linux) start-points be? they could operate on the same file anyway.
It is possible to create Java jar-files which are startable with a double click. No platform specific scripts are required. See this question and its linked stuff.
This works of course only, if a JRE has been installed correctly on each computer.
I'm using Powerbuilder to call an external function from a DLL created in C#
If I generate an executable it works fine, it call the web service perfectly well, but when I'm trying to run it in "development" mode it don't use the "application_name.exe.config" file.
I tried to set "app.config" file hard coded in the DLL, but I was unsuccessful
Clues to resolve this issue?
I think you described it yourself: you're looking for it to use something used by the EXE when you're running from development mode. When you run from development mode, there is no EXE generated or used, so Windows won't be leveraging functionality linked to the EXE. (PB starts your application so quickly because it is only loading the application to the virtual machine and running its Open event.) If you need this, it sounds like you'll have to include Deploying of the EXE and running it as part of your testing cycle.
Good luck,
Terry.
When you compile and run from the exe you're using your exe. But when you run from the dev environment you're actually using pbxxx.exe (pb115.exe, pb110.exe etc.). You may be able to copy the "application_name.exe.config" into your pb directory and rename it something like pbxxx.exe.config. At least that's the way it works with manifest files -- I had two, one called appname.exe.manifest and one called pb115.exe.manifest.
Just curious but how many libraries/objects are in your application?
I have some very large applications and the longest any of them takes to do a full build is about 30 minutes. Something odd about your aapplication for it to take 2 hours to do a full build.
DLL's dont have config files. Only EXE's.
I have a Windows CE device that we are deploying, but we have complete control of the software installed on it.
This is not a typical Windows Mobile device, this is a headless device that the user will not interact with. I know that on PDA-style WinCE devices, the .cab file is the preferred application distribution method.
However, on a headless device, we will be writing some type of upgrade/patch server that will ping a server for updates, download them, and auto-install when they are available.
Do I still want a .cab file, or is a .zip (or even something else) better?
What are the requirements for a .cab file - what kind of restrictions / requirements might get in the way and be an annoyance? What are the benefits?
I'd stick with CAB as a package since even headless devices can use the CAB extraction tool. If you ZIP it, then you have to add a ZIP support library and app. CAB also has the ability to add registry entries and define far more disparate target locations than a zip (I want x.dll in \Windows but prog.exe in my program folder - try that with a ZIP).
One thing to keep in mind is that wceload (the CAB extractor) uses a UI by default, so you're going to want to use things like the /noui switch for it.
If you're true headless this may not be an issue (not done that in a long while) but a fairly common "headless" configuration has display support and either the display simply isn't hooked up or is something like a NOP VGAFLAT driver. This allows you to run a shell and have access to all the nice shell APIs, but adds to the challenge that GWES will render dialogs onto the non-existent display.
OpenNETCF also has a CAB Installer SDK that you can use to completely remove any UI with by creating your own installer app. This may or may not be useful depending on the how and when the install happens (through HKLM\Init or otehr for example).