I am developing desktop database application. Using rdlc report and reportviewer. Everything was fine in developing process, reportviewer was showing all data smoothly. I deploy app with Inno Setup. But when I install the app, the reportviewer is not showing data. While data is correctly inserted in the tables.
For applications that work incorrectly or fail completely, when installed by Inno Setup to Program Files folder, the first thing to test, is to try to deploy the application manually to the same folder.
If the application fails even after a manual deployment, the most usual problem is that the application requires a user to have write permissions to application folder. As on modern versions of Windows a user typically does not have write permissions to the Program Files folder, the application does not work. So the problem usually has nothing to do with Inno Setup, but it's a problem of the application itself.
To solve the problem:
The best solution is to redesign the application so that it does not require write permissions to its folder. Windows applications should not require write permissions to their folder. That's against Windows guidelines. The application should write data to a user profile folder (C:\Users\username\AppData) or to a common data folder (C:\ProgramData).
A dirty workaround is have the installer grant a user(s) write permissions to the installation folder. Do that only, if you cannot get the application fixed (e.g. it's 3rd party application).
See Inno Setup - How to set permissions of installation folder.
Even more gross workaround is to configure the application to be executed with elevated (Administrator) privileges.
See Inno Setup desktop shortcut (link) which has "Run as administrator" advanced property set
or How to set 'Run as administrator' on a file using Inno Setup.
Another solution is enabling legacy compatibility mode that makes Windows redirect all application write attempts to a virtual store. See also Application installed with Inno Setup writes files to unknown location instead of its installation folder.
There are numerous other possible reasons, why the application might be failing when installed, including:
You omitted some dependency:
DLL library
.NET assembly
.NET Framework
Java Runtime Environment
other runtime
COM/ActiveX object, etc.
The application requires some configuration:
a file
a registry key [including COM/ActiveX object registration]
an environment variable, etc.
The application is not designed to be executed from a folder that has a space in its name (Program Files).
The application gets confused by Windows File virtualization (though it's unlikely). See Application installed with Inno Setup writes files to unknown location instead of its installation folder.
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 have created a windows service application in C# which uses an SQLite database file to store data it receives. I want to be able to allow the user to select the directory the SQLite database file is stored on their PC during installation. How can I do this, and how can the main application obtain the file path chosen by the user?
The only folder that Visual Studio Setups (and most others too) let you choose is the Application Folder that defaults to Program Files.
It really isn't worth doing what you ask because:
Why make the user choose a folder and complicate the setup with stuff to tell the app where it is?
What if the user chooses a folder that apps cannot access if you want to allow limited users to run the app? Or a location that makes the install fail?
It's better to just choose the most reasonable working location that you can thoroughly test with the app, and that's AppDataFolder if it's private to the app. That's User's Application Data Folder in the setup project file system view.
https://learn.microsoft.com/en-us/windows/desktop/Msi/appdatafolder
Then the app automatically knows where it is and everything just works.
VS setups don't support what you're asking, other tools do, but, again, usually setups just install files to the appropriate folders that make the app work. By the way, custom actions won't do this because all VS custom actions run after the files are installed.
I had created a windows form application and used setup project to create installer. But after installing my application the application is not opening from the location it is installed("c:\Programs Files(86x)\"). But the application runs fine if i copy the entire installed files to another drive. Actually my application is creating some folder inside the installed directory when running. so i thought it is some problem related to windows permissions. I had set app privileges as "requireAdministrator" and still not working. Can anyone help me with a solution?
Actually my application is creating some folder inside the installed directory when running.
Don't do that!
The Program Files folder is read only to standard users, and has been since Windows 2000. And since Windows Vista even Administrator users will require elevation to get write access into this folder.
Use the All Users Application Data folder instead (Environment.SpecialFolder.CommonApplicationData).
The alternative is an advanced installer product (meaning purchasing the full version of InstallShield or similar rather than the version included with Visual Studio) which supports adding an action to your install process that both creates the folder and sets new permissions, and does this at install time. But that's really a cheat, anyway. Just use Application Data.
I'm a web developer building my first production grade console application (C# .NET 4.0). I have a question about creating a settings file that the user can edit before running the console app (to customize output folder paths, etc).
I'm a little confused -- when I publish my console application and install it (by clicking on on the generated setup.exe file in my target publish folder), all I get is an entry to my start menu. Nothing gets installed to C:\Windows\Programs, and there doesn't seem to be anywhere else on my system that files get installed to. Essentially, I'm just trying to find the app.config xml file so that I can edit it after the program has been installed. (btw, when I click on the start menu entry, the program executes properly).
Is what I'm trying to do possible?
For a clickonce deployment, the files will be installed under the profile of the user who installed the application (by default).
For windows XP this should be:
C:\Documents and Settings\username\LocalSettings\Apps...
For Windows 7 (and Vista?) this should be:
C:\users\username\AppData\Local\Apps...
An installation program for your software is a separate piece of software.
You can definitely make one but when you compile your console app it doesn't create an installation executable. It just makes it's own executable. You can copy that executable alone and run it. If you need more resources to go along with it and therefore decide you want an installation program, you have lots of options.
The two that spring to mind in this case though, are setting your project to use "ClickOnce" from the project properties, or adding a "Setup and Deployment" project to your solution from the "Other project types" section of the add project dialog box.
I have developed a C# windows form application.
How should i create an .exe file in Visual Studio 2008 so that it can be installed in other machines?
A Simple "Setup and Deployment" project would work for most cases. WiX if you want to learn a powerful installer, or any of the other OSS installers out there. You could even zip up your release dir if that is all you needed and didn't want the app in the start menu or any such thing. Your question is somewhat vague.
I suggest you take a look at ClickOnce deployment. There's a video here: http://windowsclient.net/learn/video.aspx?v=14105
If you just want the .exe file, it is located in the bin\debug or bin\release folder of your project's directory depending on the current configuration setting.
My advice would be to use ClickOnce technology to deploy your application. There are details in this previous question. But here is an excerpt:
Directly from the words of MS, ClickOnce overcomes three issues in deployment:
Difficulties in updating
applications. With Microsoft Windows
Installer deployment, whenever an
application is updated, the user must
reinstall the entire application;
with ClickOnce deployment, you can
provide updates automatically. Only
those portions of the application
that have changed are downloaded,
then the full, updated application is
reinstalled from a new side-by-side
folder.
Impact to the user's computer. With
Windows Installer deployment,
applications often rely on shared
components, with the potential for
versioning conflicts; with ClickOnce
deployment, each application is
self-contained and cannot interfere
with other applications.
Security permissions. Windows
Installer deployment requires
administrative permissions and allows
only limited user installation;
ClickOnce deployment allows
non-administrative users to install
and grants only those Code Access
Security permissions necessary for
the application.