My app(windows 8 metro, using javascript) uses indexDb for database, i have seen when i modify manifest file indexDB database is deleted.
Is this a bug or a feature??.
Now my app is already in windows store I am afraid if i will modify manifest file (which i want to do) users database will get deleted and that will be a huge loss to the user.
So what is the work around for this problem.
You can try their official demo and you will find the same problem
http://code.msdn.microsoft.com/windowsapps/IndexedDB-sample-eb1e95af
This is not a bug - when you modify manifest and deploy app using Visual Studio local data is cleared. This behavior is the same for JS, C++ and C# projects.
It will not happen to your users when they will update the app through the Store.
Related
I'm trying to publish changes to a .NET Core 3.1 web app from Visual Studio 2019 using FTP, however the process doesn't update my .cshtml views.
The app works properly on my local machine, I deleted the contents of the 'bin' directory before publishing, and my publish settings delete all of the existing files on the server before copying new ones over, so this process appears to be somehow copying over views which are no longer available anywhere?! I've not changed any of the 'build action' properties and most of the configuration in Startup is the default MVC template.
Microsoft docs reference a NuGet package (Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation) and using AddRazorRuntimeCompilation() in Startup, but this didn't seem to have any effect.
I find it incredibly bizarre that views aren't updated during a publish by default. I also find it bizarre that in this day and age SFTP appears to be unsupported (wth). Hopefully I'm just doing something wrong rather than this process being silly. Any ideas?
Restarting the Kestrel service used by my server seems to have resolved it...there has to be a more obvious solution though as this method requires shell access.
I have a vb.net Windows Form that is launched from the .application file - no installing done. I have an issue on some users' machines where they can't launch the application unless they go into their C:\Users\%userprofile%\local settings\apps\ folder and delete folder "2.0".
How can I prevent the application from using/creating that cache? All user settings are stored server-side and pulled down on open.
I've found AN answer, maybe not the best, but it works.
Turns out, ClickOnce is the problem. I haven't been able to figure out how to deploy without it, however it can be bypassed. Within the deployment folder, you've got an Application Files folder, and a [Project Name]_[version] folder. Within that is the .exe for your application, within the ClickOnce wrapper.
If your application, like mine, doesn't use non built-in controls, you don't actually need ClickOnce, as far as I can tell. So having users run that .exe, rather than the .application file within the deployment folder will prevent the "2.0" cache folder, as well as preventing the ClickOnce install and loading form - resulting in a faster open.
Hope that helps someone.
I am using Visual Studio 2013. I have all components installed on my machine needed to run this application I am questioning. I have not completed the application to deploy for testing but some questions arose before completion that I need addressed now; to prevent overhauling later.
Here's how it should work when deployed to clients.
Client installs application which runs on desktop not windows store in WPF.
The application is per user and runs for all users on the local machine.
Each user needs to read and write data to a database file but it needs to be the same MDF being used. Therefore each process of the application, no matter the user session, on the same machine, all interact with the same database / same data.
Question: When adding the database to the project where will it be installed by default? In the applications program folder along with program? If so what restrictions exist to read/write to the database and are there any? I have added no extra security on my side. The info isn't private or critical.
Question: Would end users need to install any sort of SQL in order for the application to do this? If so I can package it with the install but this seems like alot of overhead during install.
If the MDF is installed per user how do I change this to install it once for all users?
Before saying so, yes this needs to be a database and not a file. Reasons I need not describe. I have considered alternative but this is by far the best solution so please no alternatives.
When you add mdf file to your project and set properly the value of Copy to Output Directory, it will be copied to the bin directory of your project whenever you build the project. When you create setup project for your app project, it will be by default copied to the folder where your app is installed. You can either specify different location in your setup project or copy the file to the desired location during the first run of your app.
There are several suitable folders in Windows, one possible choice is %PROGRAMDATA% C:\ProgramData folder, but it is by default read only for non-admin users. If you do not worry about security, go for %PUBLIC% C:\Users\Public. It is completely accessible for all users within interactive group.
I recommend to package LocalDB with your project. It can be installed silently with one line of code, though only with admin privileges. For non-admin click-once install you would have to use SQL CE, which is quite different and uses sdf files.
I think you should do it this way: include a seed database MDF file in the application and copy it to a %PUBLIC%\YourApp folder when the application first launches. Optionally include LocalDB install in your setup project.
I am working on a prototype for Silverlight OOB application. To modularize the application either PRISM or MEF or both will be used. When a new version of the application is available, CheckAndDownloadUpdateAsync can assist in downloading the latest version in OOB scenario.
How does updates work if only a new version of an application module is available? Is there a known functionality and/or strategy to be used to download new modules?
You can roll your own update detection, by having a small file on your server next to the XAP for your app, that contains the latest version. For example:
http://localhost/myawesomeapp.xap
http://localhost/myawesomeapp.xap.ver
When you want to check for updates without downloading them, you can always hit the .ver file, check the version listed in it and if newer then the current running app, show the Update button to the user.
Note that this approach also would allow you to create more advanced scenarios, like prompting the user to upgrade to a different version of the app (Pro for example) or that they need to upgrade their Silverlight to get the latest.
And if you have multiple apps, you can list all of them in that file and do cross-promotion between your apps.
I would like to make my windows form app self updating when it starts. Where can I find good information for that?
I am using Visual Studio 2008 VB.NET.
I like the click once approach. With this application I have an access db as the backend datastore. When the application self updates how can I be sure the mdb file is not overwritten?
What is the best way to self upgrade the mdb if their is a change to the mdb file but not loose the data?
If you deploy using ClickOnce, you get this functionality for free. I do not have any experience with this (yet), but I can point you to an article.
I have been using Click Once for years with very little problems.
I've written a custom automatic updater and basically, the way it works is this:
The whole application is essentially 3 parts:
A launcher .exe that's essentially like a bootstrapper
The launcher .exe has an embedded .exe resource that is used if the launcher .exe itself needs to be updated
The application dll's
When you start the application, the launcher app starts and checks via webservices if the dll's are up to date. If they are not, it downloads them to a temporary directory and then makes sure the checksums are all correct and overwrites the existing app libraries with the new ones. It's then loading the application's core assembly and calls a "Run" method via reflection.
Now, in our app we sometimes have the need to update the launcher itself and the way we achieved this is by embedding an .exe in the launcher .exe resources. If the launcher detects that there is a new launcher .exe available, it downloads it to a temp directory, then extracts the .exe and launches it. This extracted .exe simply shuts down the launcher process, copies the new launcher .exe over the old one and then starts the launcher process again.