For example .sqlite files, or use custom files.
How can I protect use files after update? ClickOne every update deletes these files. This is very unreasonable.
You could put any files that need to change separate from the click once files. Probably in the %LocalAppData% folder.
If you have default values you want to keep, you could manage it by creating a copy of the downloaded file in the localAppData, if such a copy do not already exists. If you have a server you could download other files separately if needed.
Related
I have one git repository where I have to modify one file under that zip folder.
I'm looking a way to modify file over repository only. I know below one options:
download zip file and make changes and push it back [this is not working because my zip file is 11 mb and administrator not allowing me to increase the size which is currently 10 mb from the project setting in devops]
Is there any other way I can follow and modify the zip file content.?
Thanks
Under the hood, git will compare multiple versions of files, work out the differences, then compress everything.
By storing a file that's already compressed you are preventing git from storing multiple similar versions efficiently.
If you need a zip file, create it in your build script, not your source code.
I've got a csv file stored in my solutions's assets folder. Every now and then a copy of the csv is updated on a shared drive. Is there a way to copy this file and replace the version in the assets folder automatically. (I'd just reference the shared file rather than an internal one but occasionally the network plays up. I guess I could just have it copy to a location locally but I'd rather do it this way if possible)
I've added something to copy the file over on app launch but don't have permissions. I've guessing that assets are read only during runtime? Is there a way around this?
This is the line of code that triggers the error. File.Copy(sharedPath, assetPath, true);
Error: Access to the path 'C:\Users...AppX\Assets\file.csv' is
denied.
Update an assets file (C#/UWP)
During checking the path, and it looks a apps installation folder, unfortunately, the installation folder is read-only, we can't write data into. we suggest you use app' local folder that with full permission.
For your scenario, you could copy the csv file where in the assets folder to app's local folder when app fist launch. when you want to update csv file you just need to replace local folder's csv with shared drive.
For more detail please refer this document.
I have a situation, where html files are embedded as resource files in console WebApp and are sent to another app, that hosts them.
I managed to create file change procedure, so that the WebApp is reset and will resend resources, when I edit my html files.
The problem is, embedded files doesn't change.
Is there a way that I can update embedded files at runtime?
No, but you could save the updated files to a folder, and use those files.
When the applications starts, it first checks if the folder with the new files exist. If they do, the application will use them else the application will fall back on the embedded files.
I'm planning to build my winform into a .exe file. I'm just wondering what to do with the XML files that my application needs?
I did some research and found out that I can add the XML files in the Resource folder before creating a .exe file.
Or I need to create a setup file? When the user runs the setup file, the XML files will be installed into their pc.Now I wonder which one is the best way to go for,
Note: XML files might get modified by the user.
If you want to ship the XML files as seperate to the .EXE then you can set the Copy to Output Directory to Copy if newer. (click on file and then go to properties).
OR if you want it as part of the .EXE I think you can change the Build Action to Embedded Resource.
I personally would create a Setup as per your edit and include the XML files. I usually just add everthing from the bin/release folder that is needed when I create a setup file.
You could either deploy the necessary files along with the executable in the same folder or embed them as resources (if they are read-only). If you need to modify them do not embed them as resources into the executable.
The correct way depends on how you intend to use the files. If the files always are deployed together with your application, the application never writes to them and they are never upgraded without upgrading the application, you can go with them embedded as resources.
If you need to update them separately from the application, you need to have them as physical files.
You don't necessarely need a installation package, unless you need to apply some logic during setup, such as updating the content of the setup based on user input or to check preconditions. The application can just be copied into place regardless of if you have embedded the files or not.
On uninstallation, the installer removes the installed folder and all its subdirectories. However, we want to retain some log files regarding the uninstallation. How do I make the installer not remove the installed folder?
My recommendation would be for the log files to be stored under a folder in %APPDATA%, that is created when required by the application, rather than the installer. As the folder would not be created by the installer, this would resolve the problem of the installer removing it.
It's also worth mentioning that if the installer is creating a folder under %PROGRAMFILES% for your application and you're keeping the log files there, you're doing the wrong thing, as it's not the correct place to store log data because:
%PROGRAMFILES% is not writable for standard users
%APPDATA% is the "correct" place to store things such as logs (it's all in the name! =)
Have you written files to the folder at this point, or just assuming the directory will be deleted since you see it being deleted today (without an new files in it). From my experience, the MSI will not remove a folder that is not empty. So the MSI will remove its own files, but the log files will be in there, thus it will not remove the directory.
I agree with #Rob though, this is most likely not the best location to be writing the log files.