We Keep Coding

Protecting user files after installation with ClickOne

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.

Create a cab without a folder

I am trying to create a cab file that composes of 3 files. I am using WiX dlls as recommended on another page. The problem I face is that I need the files compressed without creating a folder. When I use the below method and extract the files once again, the compressed files are now houses within a folder of the same name as the cab file.
Is it possible create the file without the folder?
Here is my code
CabInfo cab = new CabInfo(#"c:\cab\test.cab");
List<String> files = new List<string>();
files.Add(#"C:\cab\test.D");
files.Add(#"C:\cab\test.L");
files.Add(#"C:\cab\test.U");
cab.PackFiles(null, files, null);
extracted files
-test
-test.D
-test.L
-test.U

The problem comes from the program that extracts the .cab file. Nothing can be done at compression side.
If the decompressor is yours, it can be made to extract files directly. 7-Zip has the option to not create the folder too.
There is nothing in the format of an archive (.cab or anything else) that can prevent that folder creation.

C# Xml files when creating exe application

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.

System.IO.Packaging library does not read standard windows zip files

When reading a zip package using the System.IO.Packaging assembly, I have found that zip files created using the standard windows zip utility are unable to be read (the package parts (internal files) of the zip package show as not existing).
After doing some research it appears that this is because the System.IO.Packaging library adds a Content_Types.xml to the zip when it is created, which does not appear to be present in a standard windows compressed zip.
Example:
using (Package Zip = Package.Open(BundlePath, FileMode.Open))
{
Uri FileUri = PackUriHelper.CreatePartUri(new Uri("somefile.xml", UriKind.Relative));
if (!Zip.PartExists (FileUri )) //this fails even though the file exists in the zip
throw new ResourceException(String.Format("Zip {0} does not contain file", BundlePath));
...
Is there anyway to still use the packaging system provided by .NET to read standard zip files, or do they need to be created using the library.
Edit:
Adding this file (Content_Types.xml) manually, and zipping using the Windows compression utility, proves to be successful in allowing the package to read.
Thanks.

System.IO.Packaging isn't there to read zip files but packages. Use DotnetZip instead.

Unfortunately I believe you are correct there isn't a good way to get the System.IO.Packaging libraries to open up any file in a standard zip format that doesn't contain that [content_types].xml file.
I was working on this issue a few months back, and this is what I was trying to implement something that would inject this file before we just decided to initially generate all of our files from within .NET:
the format of the zip file is the following
(---file 1---)(---file 2---)...(---file x---)(table of contents)
Without a third party library you should be able to open up a zip file as a binary file, hop to the end and read that table of contents, add a [content_types].xml file at the end with the types/default extension info, adjust the table of contents entries, append it to the end of the file, and go. The problem I was running into when trying to implement this is there are various checksums on the file to verify that it hasn't been corrupted, I hadn't gotten them all by the time I needed to change directions on this.
I'm sure this is more info that you needed, but should you decide to implement your own solution hopefully this helps.

Unzipping on the fly in C#

I have built a console application that works okay when it references a .exe file from a Program Files, but my users may not have that .exe in their Program Files directory.
I would prefer to keep the package as a single .exe for simplicity, so I was wondering how I can combine the two .exe's into one package.
One thing I thought of is zipping the .exe from the Program Files directory to a temporary location, and I would store the binary data for the zip archive in my console applications source code. Is this the best way to do it or are there better methods?
Note I do not have the source code of the .exe I want to reference in my console application.

You can certainly store extra files in your .exe (or .dll) as embedded resources. Simply change the "build action" for the item in the project to "Embedded Resource". You can retrieve the contents of the file (which could be compressed, if you wished) by using the following:
System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceStream("stream name")
You could extract the file onto disk to be able to reference it, or you could load it directly with one of the Assembly.Load() variants, so you wouldn't need to ever store it on disk.
Note that if you do choose to extract it and store it on disk, you'll need administrator permissions on Vista and Windows 7 (and properly administered XP) operating systems in order to save the file(s) to the Program Files directory.

You can use GZipStream to compress and decompress files in C#. For more complex compression, you can use other Zip libraries like SharpZipLib.

Take a look at this link: Embedding assemblies inside another assembly
Basically, ILMerge will do what you are asking.