I know this question was already there. But either the answer is for 32bit(as I used) or suggesting "Access/Modify Registry". I failed in the first option. Second option is not good for me. I myself don't know about the testing machine and registry entries vary for 32 bit and 64 bit. I am trying to list out all the apps installed and uninstall the specified one(ruby). I used wmi class with the query
ManagementObjectSearcher managementObjectSearcher = new ManagementObjectSearcher("SELECT * FROM Win32_Product");
But, it does not returns all the applications. The "ruby" is missing but it shown in the Control Panel\Programs\Programs and Features as below. Can anybody say how to access all the installed programs irrespective of their bit(32/64)?
Note: I am using VS2010, .Net 4.0, C#, Windows 7 Enterprise Edition.
There is not really any such thing as "All the installed programs".
A program could be:
A simple executable file on the desktop.
A collection of executable and DLL files which co-operate together. Usually these will be in Program Files.
A DLL registered as an add-in or shell extension
something else
So "A Program" is not a single thing which can be conclusively identified.
Installation could be:
Installed with Windows Installer. You can get a list of these using the Installer API.
Installed with another setup program which does't use Windows Installer, but just places the files where it wants them. They usually supply an uninstaller of their own. THese are often recorded in the Registry for the Add/Remove programs tool.
Just unzipped into a folder. These may not be recorded anywhere in the registry, they are just files in folders. Maybe they put an "uninstall" shortcut on the desktop or in the start menu, or maybe not.
So "installation" is not a simple thing which can be conclusively identified.
Related
I am working on a application which is Windows Form Application and performs the CRUD operations in Microsoft Access Database (.mdb).
Old application :
The application was developed in C# with Microsoft .Net Framework 4.0.
The previous developers used Visual Studio installer projects to create the setup file.
The default installation path is "C:\Program Files (x86)\MyProduct".
This folder will have the MyProduct.exe executable and dependent dlls and also and Microsoft Access database file (.mdb). The shortcut will be created on desktop. When you run the MyProduct.exe it can access the database without any errors and can perform the CRUD operations.
New Application:
Now I have upgraded the .Net framework to 4.5.2 and used Installshield to create the installer. Installation path will be same "C:\Program Files (x86)\MyProduct".
Now the problem is, when I execute the exe and do any insert/update/delete operation it throws the error that "operation must use an updateable query". This means the database is not accessible. I tried running the exe as an administrator user and then only it is working fine.
My operating system is Window 10.
Note : I modified the database.mdb properties and provided FullControl to all the users for both new and old versions. But new version is not working without the admin user.
For the newer version I changed the installation path to "C:\My Folder\MyProduct" and it is working without any error. Only C:\Program Files is giving the error. The strange thing is older version is also installed in Program Files but it does not throw any errors.
Other difference between old and new application is, Older version uses Microsoft JET engine driver to use Microsoft Access database, while newer version uses Microsoft ACE OLEDB driver to use Microsoft Access Database.
I am not sure why this is happening. Older version is working but newer is not.
Can any one help me with this?
I would move the install to %userappdata% or some folder that does not require elevated rights. While you can place the .exe in program files, ANY data file in those locations tends to have VERY limited rights these days (they continue to lock down windows more and more).
Also, be carefull. Even if you say installed to my docuemnts? If you REQUIRE elevated rights during that install, then of then often DURING the install then the files and folder you create ALSO will have elevated rights.
So, don't place ANY data files or files that your code has to read in program files. These days such system folders tend to be restriced and have locked down rights.
%appdata% is your best bet. That will in most cases translate to:
C:\Users\AlbertKallal\AppData\Roaming
This ALSO means that your code better not have hard coded path names either. (you get/grab your path from the executing assembly. If you have a lot of code, and paths are hard coded? Then you can bite the bullet and say install to c:\MyCoolApp or some folder you create in the c:\ drive. However, with so many people doing remote work, then even c:\SomeFolder can be a bad choice, since on terminal services, all users share the same c:\ drive.
So, move the install out of program files, or at the very least move out the data file parts to a known read/write folder that all users by default will have rights to, and not require elevated rights to use such folders. So, be very aware of any data file parts you have as part of your install. As noted %appdata% is a good choice, but then keep in mind that the path names to the executable and the data file location will be dynamic (the users name will be part of the path name). And if you don't think you ever support terminal services or remote desktop? Then you can use/risk a hard coded c:\MyApp folder approach here.
At the end of the day, you REALLY need to avoid elevated rights DURING the install, and this is especially the case if data files are part of the install - since those files will ALSO inherit the elevated rights during the install. And for sure using program file which was common 10 or 15 years ago for programs AND data? Well the program part is still ok, but any data files now can't for all practical purposes be placed in program files.
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 am a software developer and currently I am having requirement to develop such data management software for one retailer that doesn't require installation. Means client want software that should be pre installed in pen drive and while my client access that pen drive from any pc then he must be able to access whole software without any kind of cause or installation.
How could I develop such software? Is it possible to develop such software in .net (I am familiar with it)?
If the machines that you're working with already have the .NET framework installed that you required, then no problem. You can just run the .NET code from your pend drive.
However, if you can't guarantee that the .NET framework is already installed, .NET is not going to work in this scenario. A solution that comes to mind in that scenario is a bare bones Win32 C++ solution.
Yes, you just put the exe (and dll) files onto the pen drive. You don't need to build an installer.
This is not a problem at all, as long as you don't try to use the registry, or any local folders on the PC without expecting problems.
That's not an install.
An install is where you tell the operating system about the software.
.net out of the box is XCopy deploy. ie Build, open File manager click on the exe and it should just work.
So it you copy the build files to a clean machine, pen drive, cd, of just a foklder and it works, then job done.
No permanent registry, no appdata folders, no shortcuts.
Of course you can. For instance, if you develop a software that does require installation, and you want to ask a co worker to test the app for you, you could go into your debug folder (or release) and give him the .exe + eventually the DLLs. He will be able to run it without any problem.
Just remember to keep all save files, ressources and dll's in the same folder.
The only thing is, without an installer, you wont have access to all the features an installer has, such as checking for prerequisites, installing prerequisites, inserting keys into the registry etc ...
You will have to do without these "integrated" functionnalities
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.