We Keep Coding

attempt to write a read-only database sqlite Wpf inno setup [duplicate]

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.

what is the difference between publish project and setup project

I have a project in c# VS2010 and I want to make .exe file and make a setup.Here I will make it with add setup and deployment project. But I have one more option of publish project.
I don't know
what is the meaning when I create the .exe with Publish project.
What is better and why & where I can use Publish project.

When To Use Click Once Deployment:
ClickOnce is a new deployment technology that Microsoft developed to
address several problems with deployment namely
Difficulty in providing regular updates The inability of
nonadministrative users to install applications
The dependence of multiple programs on shared components
Installation folder will be isolated storage
ClickOnce deals with
all of these problems and allows you to create a deployment strategy
that is easily updateable, isolated from other applications, and
installable by nonadministrative users.
When to use the Setup Project:
Although ClickOnce provides simple and easy deployment for a variety of applications, you
might need a more configurable environment for complex programs. Setup projects allow you to create highly confi gurable deployment plans.
Allows you to create the directories on the target computers
Windows Service installation
Registry Modifications during installation
Execute Custom Actions during installation
Copy files to target machine
Hope It Helps :)

I guess what you're talking about is ClickOnce technology. ClickOnce allows you to publish the application and all accompanying files to a location (for example a network share or a web site) and users can just install it by navigating there. You can even publish your application to a shared hosting provider and people can just install your application.
The application will then be installed in the user's profile.
The advantage of this is: You can publish updates easily if you configure your application to automatically check for updates - just publish the new version to the previous location. Every user will get the update upon the next start of the application. Users don't need admin rights to install your tool!
The drawback is: Every user (even on the same machine) will need to install the application in his own profile. There's no common installation for all users.
The advantage of creating setup projects is of course that you follow the traditional approach of installing an application on the system, making it available for all users. The drawback is that installing updates is far more difficult, and users need admin rights to install it!

Problems with ClickOnce deployment (to me, it's so annoying)?

I've just tried ClickOnce for the first time to deploy my SQL Server Compact application. I think this kind of deployment is very unprofessional:
The output setup is a folder including 3 objects, one folder named Application Files, a setup.exe and a .application file which I've never seen in a professional product setup package.
Plus, clicking setup.exe seems to help user install the application so quickly but user has no chance to select what location s/he wants to install the application. It's installed by default at somewhere in the target computer. And even I tried looking for its location after the installation, I couldn't find it.
The last, after the installation, there is a folder named "Microsoft" in All programs menu, and the installed application shortcut is located in there. I wonder why it is always Microsoft? I even tried editing my Company info in Assembly info through Project Properties window. The application shortcut is something strange when I can't find its target executable file in its properties window.
With all the above ClickOnce can bring to me, I consider it as a funny job for testing the application only not for publishing a commercial application.
Could you please correct me if there is any wrong in #1, #2, #3 and please give me a better solution for deployment, I'm interested in SQL server (service-based and file-based) application only?
Your help would be highly appreciated. Thanks.

A ClickOnce install is a per user "sandboxed" install, not a normal install you think about when installing normal applications. The .application file is used by the server as a manifest and to determine if it needs to update the install when clicked.
The reason you can't find setup.exe is because it isn't there. Once the files are installed, it isn't kept. The user isn't supposed to know where the files are, the system manages the location and updating of the app.
So, with all that, it appears you need a more normal install, not a ClickOnce. ClickOnce isn't intended to install services or other per machine files.

What are the differences between MSI and EXE installers, and which should I choose? [duplicate]

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.

How can I deploy my C# project?

How can I deploy a C# Visual Studio 2005 project so that I can run the application in another system? My project has a few dependencies and files that have to be integrated while deploying the project.
What is the best way to handle this?

You need to know what dependencies you have.
you need to have .Net framework installed
you have to explicitly install all dependencies that you used from the GAC on your target machine (some 3rd party components)
and then you just need to copy files from your \bin\Release folder
install all services, etc. if you have any
In the simplest cases only copying files should be enough.

Have you looked into ClickOnce deployment?
It's far from perfect, but for projects without a huge amount of overhead, it's generally good enough.

What kind of project?
Assuming it's a regular winforms application, just copy everything from either the obj\debug or obj\release directory to the new computer. Then run your executable

You can right click on the project file in visual studio and publish to a different location. This will build the site and copy it to the specified directory.
Also, if you need to do anything extra during the build, you can specify custom build actions on the build tab of the project's properties.
EDIT: now that I see you added that it's a windows application my answer doesn't matter. I'd try adding a setup and deployment project in visual studio to handle installing/deploying your windows application.

You more or less have three options (maybe 4?) as I see it.
Windows Installer
ClickOnce
Just distribute
the exe itself
In your particular case I would suggest ClickOnce as long as the project is not massive with too many dependencies.
For other alternatives.

The right answer depends on many criteria.
The simplest way to deploy is by copying files. Just put your .exe, the dependent .dll's, and the .config file in a directory and copy it onto the target machine. It's simple, but there are many restrictions to this approach:
It assumes that the target machine has the right version of the .NET framework installed
It assumes a certain technical competence on the part of the person installing the software.
The installation won't do basic things like create start menu items.
Publishing the program for ClickOnce deployment addresses a lot of these issues, but it's got its own set of limitations. I haven't used it much, so there are probably more than these, though these alone are pretty significant:
Programs are installed into the ClickOnce cache, not the Program Files directory.
If your program does anything outside of the ClickOnce sandbox, you have to deal with security elevation and code signing.
You can create a VS Setup and Deployment project and build an .msi file to install the program. The most obvious drawback to this is that it's complicated: .msi files can do many, many things, and the Setup and Deployment object model is complex, with documentation that is, let us say, fanciful. But there are things you can do with .msi installation that you can't readily do with other approaches, including (and certainly not limited to):
Cleanly uninstall the program through Add/Remove Programs.
Provide an actual UI for installation that lets the user decide where to put the program.
Support scripted installation via MSIEXEC.
Install components besides the program, e.g. databases, COM objects, etc.
Put components in the target machine's GAC.