I've created set up file using IS in C# with the data base. But when I install it I had following error.
Failed to update , because data base is read-only.
How can I solve this issue??
it is difficult to fully understand the issue with the very few information you have provided, what I think I understand is that the initial setup goes well and when you run Inno Setup again to update your application the local data base file is in use and does not let you overwrite it... well, good luck it is because if not what would happen to user data entered with your app since the first install of the application?
in general for data based applications following updates of the application binaries should not simply overwrite the whole database files with an empty one included in the setup, you should find a way to update database schema or add / update reference data by including some update scripts execution within your installer, when you detect that you are doing an update rather than a first install.
Hope it helps.
Related
I am trying to make an application for managing a small store, which will be offline. I am considering using SQLite for my data handling needs. Once I create the installer for this project, does the database get attached to the installer or will have have to take additional steps to make the application work.
Also is SQLite the best way to approach this or should I consider something else?
Since SQLite needs a file to work with you can include a file which contains empty schema of your SQLite database in your setup project and copy it to working directory. Or add your empty db file as a resource to your application. And in your connection string builder/provider check existence of the file if it doesn't exists read it from resource and copy to the target location. And also SQLite is good option for that kind of usage.
I'm developing a simple Windows Phone 8 game and suddenly a question popped up in my mind? What happens to files (ex: Score.xml) when i update the app. Update overwrites all the files or keeps them or what?
Say you have an xml (Score.xml) file which keeps the scores. This is the orginal file:
<Score>
<LevelOne Score="0"/>
<LevelTwo Score="0"/>
</Score>
User keeps playing the game, as you guess those Score attributes increases. After few months later, think you will gone update your game with new xml file (Score.xml):
<Score>
<LevelOne Score="0" HowManyTimesPlayed="0"/>
<LevelTwo Score="0" HowManyTimesPlayed="0"/>
</Score>
What happens in this situation? Now we have old Score.xml that keeps users current score information and we have new Score.xml in the update that starts from scratch with new attributes? I made my apps with database before but in this game i don't need it. I need simple xml files. Very confused right now and don't know how to search even this situation in holly google. Did i misundestood something? Guys i really need your help :/
Your data will be preserved during the update procedure - MSDN:
When you update your app, any data in the isolated storage is preserved. However, data in the isolated storage is deleted if the user uninstalls and then reinstalls your app. For more information, see Data for Windows Phone 8.
It's your responsibility to correctly handle all old files.
I would advise you to publish (after succefull testing with deployment via VS) a beta version (for example limited only to you) and test updating procedures. From my experince it is very important thing to do - there may be many pitfalls and there is nothing worse than the app that fails after the update - so check as many times as possible.
As Romasz said, you have to handle all old files in IsolatedStorage yourself. I just wanted to add a few suggestions/hints about how to do it:
Know when the version has changed.
Keep the app's previous run version in a file. When you run the app, check if the new version is higher than the one from the file and if so - update what you need and then update the version stored in the file.
In some cases it's good to know by which version of the app was a file last modified. You can store the app version in that file and add some logic when the file is deserialized and the version in it is old.
In some cases you may need to make changes that will make the new class incompatible with the old file. Of course, you will still want the data from the old file, so here are two ways (I can think of at the moment) that you can handle this:
On update, open the file as XmlDocument/XDocument and modify it accordingly to make it compatible with the new class.
If there are a lot of changes, create a completely new class with the new data that you want to serialize, and leave the old one untouched. Then, on update, convert the old files to the new files. (You'll be deserializing the old file as the old class and then saving a new file with the new class.)
Triple check everything in the update. Deploy the old version, use it for a little and then deploy the new version to see if the update is handled correctly. (Okay that's not about handling but it's very very important.)
I hope this helps someone. :)
Update //Thanks to Romasz
You should keep update code for previous versions. Someone may for example update from version 1.3 to version 1.6, without going through versions 1.4 and 1.5. In this case, you may have several things to do on update.
Basically the code for update ends up being something like:
if (oldVersion < new Version(1, 4)) {
//update what changed from version 1.3 to version 1.4
}
//no need to update anything from version 1.4 to 1.5
if (oldVersion < new Version(1, 6)) {
//update what changed from version 1.5 to version 1.6
}
So, when someone updates from 1.3 to 1.6, both update procedures will be executed, with the older one being first, as it should be.
It really depends on where and how you are storing the XML file. But because you are modifying the file at runtime I am assuming you are storing it in the isolated storage. In that case the file will not get overwritten when you update the app.
If you want to be 100% sure,
- deploy the debug version of the app, using Application Deployment tool, to your test mobile/emulator
- use the app for a while so that the xml file gets updated
- recompile (not Rebuild) and redeploy.
If the changes remains intact after redeploy, you are good!
So I've created a simple msi-setup for my application using a setup project and added a couple of custom actions that take care of stuff like extracting files from archives. Now, there are two extra files in my program files -directory which means that the MSI won't remove the directory at the uninstall by itself. My solution to this was to create a custom action that removes the rest of the files.
Now this works just fine and dandy, as long as the default directory is used at installation. But what if the user chooses to change it? I'd assume there has to be a very simple way to read the directory at the custom action, but I'm not quite sure what that is.
As far as I've found out by googling, there are properties such as TARGETDIR related to the MSI-package. However, some sites also say that I should be setting this property by myself, at the installation stage.
All this has left me quite confused. Basically I see two ways to resolve this:
1) Make sure the application does not create files by itself, and the MSI will take care of it. This would mean a bit more work because I'm not responsible for those extra files.
2) Find out the installation directory at the custom action while uninstalling the application, and remove the last bits by myself. This is the quick-and-dirty way as I see it, and would definitely suffice for now. But how to accomplish this?
Also while I'm here I might as well ask this one more related question. As I mentioned earlier, I extract some files at the install. Now, I'd like to get rid of these archives once I've extracted them. The problem is, if I do this, MSI will think my installation is broken and copy them back each time I launch the application. So how to avoid this?
There is no need to use a custom action to remove the files. MSI has built in support for this scenario in two steps:
Use a search to locate the files you want to remove. Here is a tutorial
http://msdn.microsoft.com/en-us/library/aa371564(VS.85).aspx
Then you can schedule a file removal operation to actually delete the files.
http://msdn.microsoft.com/en-us/library/aa371201(VS.85).aspx
Regarding your second question:
Don't add the archives to the File table. Instead create some self extracting archives and use binary custom actions to unpack them.
http://msdn.microsoft.com/en-us/library/aa368085(VS.85).aspx
I'd like to release some updates for a WinForm program, but to date I have simply released an all-new compile. People have to un-install the old version and install the new version.
EDIT: I'm using an auto-generated InstalWizard. It preserves my file strucutre and places the [PrimaryProgramOutput] in a particular directory. I forget what this is called.
I bet there's a way to get around this, but I don't know what it's called. As you may guess, searches for "updates" "new version" "install" and the other obvious things I've tried have generated an impressive number of irrelevant results. >_<
I suspect this process has a particular name, which should point me in the right direction, but if it doesn't please link to a tutorial or something.
I see from the tags you are using C#. Visual Studio can create Setup projects for these kind of tasks. The setup projects als contain a property RemovePreviousVersion, which will remove a previous version if the versioning of your setup is correct and the GUID of the application stays the same.
See this link for more information:
http://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/
ClickOnce deployment is a great solution most of the time...
You can deploy to the web and when ever your users start the application it will check for updates and automatically update the application if there is a new version available.
It can also be configured not to update automatically but only to notify the user that there is a new version available and allow the user to control the update process.
I'm writing an application using windows form and c# 3.0. I was wondering if there is a recommended way of persist data across time. However, i do not want to touch the machine it is running on, as a result, i would like to store the data in the binary executable (preferably, due to the need not clutter up the user's folder with random config files).
So if anyone have any ideas of how to do this, it would be much appreciated!
Jason
If you're looking to store configuration information - app.config or a settings file is probably the way to go.
If you are storing user data - you should really allow the user to control where it is saved - and prefer the \User\Username folder on the machine.
As for what format to store it in ... you can certainly use something like SQLLite - but there's nothing wrong with XML either, if you're not storing true binary data. .NET offers a number of APIs to transform object graphs into XML representations - which you may want to look into.
If you don't want to store anything on the local user's machine, you probably want a network database - or a webservice - to which you upload the users data. Just make sure your users understand this - many don't like their private data being sent somewhere on the web without their consent.
You really don't want to go about modifying the executable file. Many virus scanners quarantine executables that are constantly changing in content or size - as a way to proactively prevent viruses and malware from infecting the machine. You don't want to go there.
Do not modify the executable. Adding a single SQLite database is a much better solution.
Isolated storage is another alternative.
Doesn't clutter install directory
Doesn't cause issues with AnitVirus software
Part of the OS including .Net objects, don't need to install anything else
Already works with the Windows security model
Exists on a per user basis, so saved settings are separated for each user
Can serialize/deserialize obects directly into it
SQLite is what your looking for and is compatible with c#
If you dont want to store data in a SQLite db on the end users PC you could call out to a web service on another server which stores it's data in SQL Server or something else.
I don't believe a windows form project can modify itself like that (I've tried to find a way to do this myself some time ago). Some form of hosted application such as a silverlight application (where the application is essentially a zip file) may be the way to go. Silverlight applications would require the silverlight plugin though (and I'm still not sure if a silverlight application is allowed to modify itself).
I would think that one config file of some sort would be prefereable, and not leave much clutter.
One way to ensure that your applicaiton is entirely self contained would be to use a program like ThinStall after you have compiled the project. This virtualises the application and could give it it's own file system or registry internally to the .exe file.
One way for an executable to change itself would be to put another executable inside it, (embed as a resource then extract it to a file when needed). This executable could then modify the first, however I don't think ther'es any framework for it to do that, so it would require knowing excatly what to change and where.