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).
Related
I’m creating an installer for a software application that interfaces with a hardware device. The hardware device uses an FTDI USB serial interface. I need to install the FTDI USB drivers (if the user doesn’t already have them) along with the software, and I’m using WiX and the DIFxApp extension to accomplish this.
So far, so good. That all works fine. I have separate MSI packages for my software and the 32-bit and 64-bit flavors of the drivers, and I’m using Burn to bundle them all up into a single installer. The driver MSI packages deploy the driver files to a subdirectory of my application installation folder, and then DIFxApp installs the drivers to the appropriate system locations from there. (Which seems silly – they’re only used during install; why keep them hanging around after that? A copy is kept in the system driver store, after all. It would be preferable to extract them to a temporary folder, install the drivers, and then clean them up. But evidently, that’s the way DIFxApp works.)
But the FTDI chipset is used by a lot of different devices, and it is likely that a user will own other devices that also require the FTDI drivers. In testing, I have found that DIFxApp uninstalls the drivers when the software is uninstalled. This is undesirable, because it will break any other FTDI-based devices the user owns, requiring the user to reinstall the drivers to get those devices working again.
I would like DIFxApp to leave the drivers installed on the user’s system when my software is uninstalled so that removal of my software does not affect the user's other devices.
I could do this by setting the Permanent attribute on the MsiPackage or Component that installs the drivers, but that will prevent the driver files that were deployed to a subdirectory of my application installation folder from being cleaned up. I want those removed along with my application; I just don’t want the driver removed from the system driver store, etc.
It also looks like I could accomplish what I want by installing the drivers with a DPInst custom action. And it looks like the DPInst approach would support installing the drivers from a temporary folder and not require the driver files to hang around in my application folder for eternity. This would seem to be the pragmatic solution, but evidently DPInst is discouraged in favor of DIFxApp in MSI-based installers.
What is the “right” way to handle this?
I have dealt a little different with the same issue.
I consider the drivers and the application as separate pieces of software so they should not share any directories or files.
I install the drivers with difxapp and also copy them to program files/common files as they could be shared/common.
The application is installed to it's own directory in program files.
Then you can mark the driver msi as permanent in the bundle and keep the drivers when the application is uninstalled.
We have a native, stand alone Win32 application that we use to generate .PDF files. It is command line driven to take one of our data files in and generate a PDF file. It works in conjunction with a print driver that is installed on the computer.
I know there are libraries for generating PDF files in .NET that we can use in Azure, however, there is specific type layout being carried out in our App that we must support, and that logic is not yet on the server side. This is a short term cheat, before we port (or rewrite) our 20 year old type layout engine out of C/C++. There is alot of code here with alot of complexity.
I see that we can now run native apps in Azure (yay). However, my issue seems to be that this native application requires a print driver installed. I have not been able to find any information about installing print driver in Azure worker role.
I found this discussion: https://stackoverflow.com/questions/9125385/printing-to-pdf-from-azure-worker-role. The end result of this is to use a PDF library on Azure, which is not something that will work for us.
Also, I am aware that it is not the best use of a server to fire up a process to generate a PDF file everytime somebody wants to preview their data file in our web site. We are planning on cheating by showing the user the PDF, when they want to preview our proprietary data format in a browser. This is Phase I of a project, and rewriting our 20 year old type layout engine in C# is going to take alot longer to accomplish, and we are talking about this (admitted hack) as a short term (in the bigger sense of things) measure.
How do I install a Print Driver in Windows Azure worker role? Is it possible? Are there any other options?
Many Thanks.
If you can do a command line, silent install of the Amyuni software that yms mentioned then you could run that as part of a startup task on your worker role, probably with elevated permissions. People use startup tasks to do all sorts of things and many of them have written blog posts about it or answer questions about them here on SO, but a good place to start would be the official documentation.
This may help: Amyuni PDF Converter is a PDF printer driver with an API exposed as a COM interface and as a net. assembly that allows you to silently install and uninstall the driver programmatically. This can be done by using the methods PDFDriverInit and DriverEnd from your application.
Once your application installs the driver, you can print to PDF using a memory stream as destination and upload it to a Microsoft Azure Blob Storage.
There are 2 ways of installing Amyuni PDF Converter:
1- Using the installation program provided with the package.
2- Copying the dll files to their corresponding folders and then calling the method DriverInit.
The complete process is explained here:
Using the Developer Version of the Amyuni Document Converter
About your specific scenario, if you have an application that uses Amyuni PDF Converter, then there is indeed a printer driver that should be installed with it. Your application could be installing the driver every time it is launched and removing it when it is closed, or it could be installing it only during the installation of your program.
If you do not have the source code of this application but you still have the license information of the library provided by Amyuni, you could try building a small application or batch script that just takes care of the installation process. You can contact Amyuni support for a link to the latest build of the version you are using.
You mentioned that you are using Windows Azure VM, so I am assuming that you have administrative rights on the virtual system and that you can connect to it using remote desktop and run any kind of applications.
Usual disclaimer applies
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 looking for a way to manage application upgrades for my compact framework app.
let's say i have v1 of the app installed on my device, and v1.1 has been released. I want the app to make a call to my server to see if there is a new version. since a new version is found, i want to send down the new version of the app to the device and have it installed, replacing the old version.
my first thought was just to have the app download the .cab file and kick off the cab file just before exiting the app. this would mostly get the job done but it would prompt the user to pick the installation location if they have a storage card or other partitions on their device. i would like to prevent any user input and just have the new version of the app installed, replacing the old app.
i'm certain that there are others doing this already and i don't want to reinvent the wheel, here. what application management tools and systems exist for this type of process? how can I facilitate this type of process?
...
EDIT:
in spite of my previous searches before posting this, i just now found this question: How to Auto-Update Windows Mobile application
When I wrote one I relied on launching the .cab file. It was definitely the path of least resistance.
Otherwise, I'd write a simple "upgrade.exe" executable that gets distributed with your app. When upgrading, you'd download the new package, launch your upgrade.exe just before exiting your app, then have that program copy over the new files to your app.
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.