Split WPF .exe Resource in to multiple files

[Aleksa Djordjic]

Hi, i have a quick question which i couldnt find an answer for:
 

My current WPF app has a lot of images which makes the .exe over 10mb bit (which is too big for me...)
Most of those images wont be changed during updates so i would like to somehow exclude them from the .exe...

 

I would still like to keep that stuff as a built-in resource and i dont want it to be an actual .png/.jpg/some_other_format file, i was thinking of an API approach, app downloads those images from an API but that would cause much more load on our servers since, again, i dont want to store those images in a easy to access file so no caching would be implemented ... probably

Thanks ... i hope i was clear enough , if i wasnt, tell me ... please ... idk how to write this stuff ...

(Im giving images as an example here, but it should work with any file that is set in Visual Studio to build with the app)

[Aleksa Djordjic]

Just wanna add something without editing ...

 

Here is the current file structure:

-Program.exe (~15mb, includes everything)

-someDependencies.dll

 

What i would like to do is something like this:

-/Program_Data - img_1.data (all images that wont change during updates)

                          - img_2.data (images that might change)

                          - ... and for other file types the same, or maybe even combined in to a same file

-Program.exe (just the XAML, Scripts and WPF data)

-someDependencies.dll

[mariushm]

If you want smallest number of files, bundle the images and other static resources in a zip file , or TAR file (whatever's natively supported

Otherwise, just have them in a folder.

 

You can make an Update tool that downloads a json or xml file with the files your latest version has along with crc32 or md5 hashes of the contents, and you can have the update tool download only the needed files.

Or you could make DIFFs between versions using xdelta or some other tool and have the update tool download only the differences then patch the software in-place.

 

 

[MisterWhite]

I'm not sure about it, but have you tried creating a class library and putting those "files" in there? That would essentially create a .dll. Also about the:

On 7/31/2019 at 1:53 AM, Aleksa Djordjic said:

i dont want it to be an actual .png/.jpg/some_other_format file

why don't you?

[Aleksa Djordjic]

On 7/31/2019 at 12:23 PM, mariushm said:

If you want smallest number of files, bundle the images and other static resources in a zip file , or TAR file (whatever's natively supported

Otherwise, just have them in a folder.

 

You can make an Update tool that downloads a json or xml file with the files your latest version has along with crc32 or md5 hashes of the contents, and you can have the update tool download only the needed files.

Or you could make DIFFs between versions using xdelta or some other tool and have the update tool download only the differences then patch the software in-place.

 

 

Im on vacation, sorry for not responding in a looooong time...

That isnt really what im looking for...

 

On 8/11/2019 at 3:53 PM, MisterWhite said:

I'm not sure about it, but have you tried creating a class library and putting those "files" in there? That would essentially create a .dll. Also about the:

why don't you?

I was actually planning on doing it like that, but does that work ...?

I know that it can for images, just reference that assembly in XAML but what about accessing it trough code for rendering with D3D .... im guessing the same way?

Anyways, tnx for the suggestion

 

Idk, looks ugly and we dont want it easily accessible to the end user, altho there will be a (kinda) web version so ehhh .... idk

 

Im coming home on 18th and then i will test it, if it works imma mark that as "Answered"

[Franck]

13 hours ago, Aleksa Djordjic said:

 

On 8/11/2019 at 9:53 AM, MisterWhite said:

I'm not sure about it, but have you tried creating a class library and putting those "files" in there? That would essentially create a .dll. Also about the:

why don't you?

I was actually planning on doing it like that, but does that work ...?

I know that it can for images, just reference that assembly in XAML but what about accessing it trough code for rendering with D3D .... im guessing the same way?

Anyways, tnx for the suggestion

 

Idk, looks ugly and we dont want it easily accessible to the end user, altho there will be a (kinda) web version so ehhh .... idk

 

Im coming home on 18th and then i will test it, if it works imma mark that as "Answered"

If you put it in a dll it will be accessible to anyone. Resources cannot be protected that way. It's is called security by obscurity. The only way to secure resources are either embed them in the compiled application, which create humongous executable or the best solution is to encrypt them.

 

I highly suggest the later. Encrypting is the best way to go. I would also make a zip file, uncompressed simply for single file access reasons and you can retain a tree structure in it. The way the resource is stored has no bearing on how to use it even if you are doing XAML. You can always have parametric control which load from a file in the background.

[Aleksa Djordjic]

On 8/13/2019 at 1:45 PM, Franck said:

If you put it in a dll it will be accessible to anyone. Resources cannot be protected that way. It's is called security by obscurity. The only way to secure resources are either embed them in the compiled application, which create humongous executable or the best solution is to encrypt them.

 

I highly suggest the later. Encrypting is the best way to go. I would also make a zip file, uncompressed simply for single file access reasons and you can retain a tree structure in it. The way the resource is stored has no bearing on how to use it even if you are doing XAML. You can always have parametric control which load from a file in the background.

I think that i would go with the DLL route, when i mean not accessible to the end user, i mean just with file explorer ... most of our demographic are kids ... which like to steal ... but know nothing about programming or how .dll-s work and how to extract files from them so we are safe

 

Altho, tnx for the info

[mariushm]

You could just rename a zip or 7zip file and give it a .dll extension, or some other random extension ... optionally encrypt it with a password you hide inside your executable.

even if kids determine it's an archive, they'll waste days trying to recover a password?

 

See https://archive.codeplex.com/?p=sevenzipsharp