We need to reboot a Windows CE device after installation of our CAB file. We basically created a smart device CAB project in Visual Studio 2008. We are developing in C#.
I have seen examples of modifying MSI properties in Stack Overflow question How can I prompt the user to reboot in a .NET installation?. So I was going to try setting this MSI property in Orca.exe. But CAB files don't seem to open in Orca.exe, so I assume it isn't an option for CAB files on smart devices.
I also see an example of making it happen in C++, Stack Overflow question Reboot on installation of .CAB WM, but we would rather avoid using C++. There isn't an option for C# custom actions for smart devices either.
Is there a setting or some way for us to do this in C#?
There's nothing you can do in C# for this, no. The CAB file is unpacked and parsed by wceload. If you need to do any custom actions, you must use a custom setup DLL, which must be written in C. That said, what you're after is not at all complex, so writing it in C really shouldn't be a problem. You simply need to add the soft reset call to Install_Exit (probably after checking that nothing failed).
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I'm looking to create a virtual printer that passes data to my .NET application. I want to then create an installer that installs both the printer and the .NET application. It would we really nice to be able to write it all in C#, but I have a feeling that this will require a printer driver to be written is unmanaged code. Does anyone know of a fairly clean tutorial or example of how to do this?
Did exactly what you are asking using the Github project: Microsoft/Windows-driver-samples/print/XPSDrvSmpl
https://github.com/Microsoft/Windows-driver-samples/tree/master/print/XPSDrvSmpl
Installer: http://wixtoolset.org/
Application: Listen to internal port
Flow: Install printer and application from a single installer. User prints something with your driver while the application listens to the internal port. When data is sent the application picks it up. This is for XPS, can be converted to PDF, but the flow is similar no matter what you are printing. If you need anything else check out Microsoft/Windows-driver-samples/print/ on GitHub or other sources specific to your needs.
Update:
A lot of questions about how to get the driver working so here is a quick example:
Start by downloading Windows Driver Kit (WDK) if you do not have it installed already. When installing choose to add the extension for Visual Studio as well in the final step. In your Visual Studio 2017 Install you need to have Desktop development with C++ to have the right SDKs. If you don't have it see the anser below on how to add it.
How do I add features to Visual Studio 2017?
https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit
Then download the .zip file for Windows-driver-samples master:
https://github.com/Microsoft/Windows-driver-samples/archive/master.zip
Navigate to the folder <UnzipFolder>\print\XPSDrvSmpl and open XPSDrvSmpl.sln in Visual Studio.
Then follow Microsofts own guide on GitHub. As you can see it is for Visual Studio 2015 but I think it is the same for 2017 (not tested yet):
To build a driver solution using Windows Driver Kit (WDK) 10 and Visual Studio 2015, perform the following steps.
Open the solution file in Visual Studio 2015.
Add all non-binary files (usually located in the \install directory
of the sample) to the Package project: a. In the Solution Explorer,
right click Driver Files b. Select Add, then click Existing Item c.
Navigate to the location to which you downloaded the sample, and
select all the files in the install directory, or the equivalent set
of non-binary files such as INFs, INIs, GPD, PPD files, etc. d.
Click Add
Configure these files to be added into the driver package: a. In the
Solution Explorer, right click on the solution and choose Add > New
Project. Choose Driver Install Package under Visual C++/Windows
Driver/Package. b. In the Solution Explorer, right click the Package
project and select Properties. c. In the left pane, click
Configuration Properties > Driver Install > Package Files. d. In the
right pane, use the ellipsis button (...) to browse to the set of
files that needs to be added to the driver package. All the data
files that you added in Step 2-c, except the INF file, should be
added. This configuration is per-architecture, so this configuration
must be repeated for each architecture that will be built. e. Click
OK.
Open the INF file and edit it to match the built output. a. Open the
INF file. b. In the Version section, add a reference to a catalog
file like this: CatalogFile=XpsDrvSmpl.cat. c. In the
SourceDisksFiles section, change the location of the DLL files you
are building, to =1. This indicates that there is no architecture
specific directory in this driver. If you ship multiple
architectures simultaneously, you will need to collate the driver
INF manually.
At this point, Visual Studio 2015 will be able to build a driver package and output the files to disk. In order to configure driver signing and deployment, see Developing, Testing, and Deploying Drivers.
https://github.com/Microsoft/Windows-driver-samples/tree/master/print/XPSDrvSmpl#build-the-sample
I think you will have to do a lot of WinAPI wrapping. Start researching
on Windows Driver Development Kit to find the things you have to do.
I also found this commercial Printer Driver Resource Toolkit for .NET...
You could simply have your app expose itself like an LPD type printer or monitor port 9100. You could then install any print driver you like, and point it a your app.
Was looking for an answer for similar question, and found this link through Wikipedia - http://www.colorpilot.com/emfprinterpilot.html (allows to create Virtual Printers in different languages)
Why not consider using an alternative approach. Like using an intermediate ready made printing program, such as those freely available Print-to-PDF application. Then all you need is to decode PDF using some 3rd party library (which has free and opensource variance too) instead of cracking your head to reinvent the wheel. There are other Print-to-XXX application which you could also consider depending on the format you see fit.
I don't thing interpreting PDF approach is any good either. I don't know why you want to do what you want to do. Maybe you're trying to write a PDF printer of your own.
I think you should really give the Windows Driver Development thing a look. If you want to develop a printer driver, I think you'll have to do it in C++.
Good Luck.
If I remember correctly Microsoft does not support .NET within printer driver development. I have yet to come across a pure .NET printer driver. You will be a very brave man to do so! The website "Printer Driver Resource Toolkit" does not say that the driver has been written in .NET
i created an application using c# language. this application is doing a task like report generation.i am using that application exe file directly to run the application.i never installed that application in my system. without installation of that application, i can use it in my system.then why people are installing a software/application in systems.please clarify me. so that i can differentiate the MSI installation and direct use of exe file.
Install in cs jargon means guided setup, so what you do is already, basically, installing. Installing may involve much more complicated steps than simple copy/paste of bin directory or unzipping in some folder. installation process may contain the below processes:
Controlling user license
Registry key control
Database creation
Com components registration
....
and much more.
But the core concept remains the same: guided setup of all necessary components of your program to run it properly. So, if the only thing your program needs is a binaries folder, copy/paste is your install.
What you are doing is called an "xcopy" deployment. It was all the rage when .NET came out but it has serious limitations.
Windows Installer (MSI) is a windows platform service / SDK that aimed to create a declarative framework for consistent installer behavior. Simply put instead of learning how to write script to automate install/uninstall (and making a lot of mistakes along the way) you leverage MSI to tell it I have a product named X with feature Y that has these files Z in these directories along with a shortcut and some registry entries and let MSI do the rest for you.
I need to create a simple installer of sorts for a different application. That other application already has it's own simplistic installer, and I don't want to meddle with it.
The reason for my own installer is to allow the user to install SQL Express if (s)he so chooses, and also to pre-install any other basic requirements for such a procedure.
At the moment, here's where I'm at:
I've created a single Windows form application, with big buttons (this is for a user which likely won't be very good with computers) to install SQL Server Express (using silent install with a predefined set of arguments) or the actual application, along with some helpful text to let the user know what's going on. Something along the lines of Visual Studio autorun window.
I've also added the standard set of pre-requirements to the application (.NET, Windows Installer).
Everything works OK if I run the app by using the executable. HOWEVER, if I publish it to create a ClickOnce application (so the pre-requisites are installed when needed) and run it, it stops running other installers.
EDIT: Apparently the problem with not being able to run other application from a ClickOnce application is only on my end, and probably deserves a new question, not necessarily here on StackOverflow (perhaps on MSDN forums?).
In your program before launching the installer you can check if .NET is installed. Its pretty easy to check if a particular s/w or a version of s/w is installed. Write a program that will check HKEY/LocalMachine/Microsoft/Windows/CurrentVersion/Uninstall and in that there will be list of programs that have been installed on that machine. If you find then go ahead with your install else suggest user that he needs to install pre req.
When you create a setup project you can right click on the setup project, go to properties, and click on pre requisites. In that you can mention which version of .NET framework is needed and then give the location of the framework. In this link look for Huggy Bears response eggheadcafe.com/community/aspnet/2/10131905/setup-project.aspx
I've settled for a "Click Once" application. It can install all required .NET components needed for it to run, thus becoming an "sure-to-run-non-native-C++-code-splash-screen".
Granted, there ARE issues with Click Once, but this is far better than nothing. It's also better than running C++ or unmanaged code applications. ;)
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What are the specific differences between .msi and setup.exe file?
I am working on an installer for a new version of my project (C#).
Previously, I've used Inno Setup to create .exe files for installing my projects on other computers in the workplace. While reading through some tutorials, though, I came across Windows Installer XML, which uses XML files to build a .msi installer.
My project will be available on a network share that all the employees have access to so they can install the software (I'm currently working on an update checker as well)
What are the major differences between .exe and .msi installers? Why would I want to chose one over the other? Would either make more sense given my specific environment?
I found some of the information at this question, but there was not a lot of information.
I wouldn't use WiX for a new project. I'd use an 'Installer Project' in Visual Studio to build an MSI. An installer project is much, much easier to put together.
Many exe installers are actually stubs or containers that hold an MSI, btw.
I guess you've checked out http://en.wikipedia.org/wiki/Windows_Installer?
MSI's give administrators the ability to restrict installs, rebase installs, change or add custom actions, automate installs/reinstalls/uninstalls, standard logging and switches. It just really integrates into a corporate IT environment ( http://technet.microsoft.com/en-us/library/bb742606.aspx ).
A custom installer may have many of those features, but that would depend on the installer package.
Most EXE installers available today are simply stubs to verify that the target machine has just enough support to launch an MSI stored within the EXE. They do basic windows version checking and Windows Installer version checking, then essentially invoke msiexec and let Windows Installer handle the rest.
For a very basic installation, the Installer Project in Visual Studio can get you by, but for just about any kind of real customization or tweaking you'll need a real MSI editor. We use WiX and love it - but it's a bear to learn. If you've got the cash you can invest in InstallShield - but that has it's own set of quirks.
MSI is configurable while EXE is not. I know this doesn't answer your question directly, but I thought I should point towards the ClickOnce technology.
MSDN: See example here.
Simply stated, a ClickOnce application
is any Windows Presentation
Foundation, Windows Forms, or console
application published using ClickOnce
technology. You can publish a
ClickOnce application in three
different ways: from a Web page, from
a network file share, or from media
such as a CD-ROM. A ClickOnce
application can be installed on an end
user's computer and run locally even
when the computer is offline, or it
can be run in an online-only mode
without permanently installing
anything on the end user's computer.
For more information, see Choosing a
ClickOnce Deployment Strategy.
IndigoRose's MSI factory is extremely powerful and much, much cheaper than InstallShield.
It uses WiX internally and allows you to modify the XML files in any way you like. The bootstrapper (.exe, if you add one) has a powerful scripting engine based on Lua to do... well anything.
I have .NET exe, I want to create a setup for this and after any login or restart this exe should be called automatically.
As you are deploying a .NET application, there are multiple ways in which you can approach this challenge.
There are many questions you have to consider when choosing an installer strategy. These include:
How do I plan to distribute this software?
Is the software supposed to be connected to the internet in any way?
What users is the software targeted towards?
Do these users have specific computer installations, such as all having .NET Framework already installed?
How should I approach the problem of updates to the software?
After answering some of these questions, you can get a general idea of how you should distribute the software. Then, you need to consider the various installers, and Wikipedia has a convenient list that compares them, which might help you.
Below are some examples of what might work for you:
ClickOnce deployment built into Visual Studio - my current favorite way, as this is the most easiest for users and for developers because updates and interaction is extremely simple
NSIS (Nullsoft Scriptable Install System), an open source scripting system for such installers. A great tutorial on packaging and checking for the .NET Framework with NSIS can be found here.
InstallShield (from Macrovision) - a heavily used installer system, but this one is not free, unlike other solutions
DreamShield - I haven't tried this one, but it appears to be a viable solution.
WiX (with Visual Studio plugin)
Deployment of applications is a very tough part of software development, especially in .NET, because how can we know, for example, whether the potential user already has the .NET Framework installed on their system or not? Or what version is installed? Thus, we must use tools like ClickOnce and NSIS to help.
To your question about how to start your application immediately at login, there are four ways to approach this:
Add registry key to start at login/bootup - MSDN explains that very well here. However, most installation systems allow you to automatically configure the registry key for bootup addition.
Use the Windows Task Scheduler to schedule a "task", in other words, to create a task that runs at startup. There is a .NET library for that here, I've used it in two of my applications that run on a specific schedule, it works great!
Adding the path to your executable into the Startup folder located at C:\Documents and Settings\All Users\Start Menu\Programs\Startup(that is for all users - for single users you can customize the username in that path). By the way, that location is in Windows XP, it may be different in other version of Windows.
If your application is a Windows Service, you can already automatically start at bootup, through svchost! There is a simple service configuration that will allow you to accomplish this.
Hope I helped!
You can use Inno Setup for the specific tasks described in the other answers.
By setup, I'm going to assume you mean the conventional installer. A good open source solution is NSIS. If that does not work, here is a more complete list.
As for having it start whenever the computer restarts/you login, that is platform specific (the installer can be platform specific if the program is). On windows, the installer needs to add a shortcut to your program in the folder
C:\Documents and Settings\All Users\Start Menu\Programs\Startup
(that is the easy method, there are surely more complicated registry settings).
This blog post lists a few useful links to info about Setup and Deployment projects using Visual Studio.
You could also google with the keywords ".net deployment project".
Although not .NET specific, you can try InstallJammer. Its open source and multiplatform.