I have made a game and wish to distribute it online. I have spent years playing around with many Installers (InstallWise, InstallShield, etc, etc, etc).
They are very complex, require time and in most cases, a decent amount of money. So I want to write my own Installer, that will install my game for the user.
My game is comprised of:
DLL files (these will go inside the Game's folder, inside Program Files.
The application file itself (a single .exe file).
I will also need to create a shortcut on the Desktop (if the user allows) which will launch the .exe in Program Files folder. I can already do this.
I know how to copy and write files to folders. What I am asking is, how do I "pack" the files into my installer file, so that I can give a user a single file to download, which will then "unpack" the game's files into the appropriate location?
I have asked this question 2 years ago on SO and was met with hostility; the person claimed that this is not possible - but incase they haven't noticed, 90% of installers are just a single file, which unpacks its contents into a directory/several directories. So I know it is possible.
The only way I can think of that I can get this to work is by going over each file that needs to be packed, and reading the bytes into the app and storing it into an embedded file. And when the app is run, it will look for embedded files/bytes and write those bytes to new files in the specified locations. Please correct me if I am wrong.
Any help will be greatly appreciated.
You will need to either save the bytes in your installer, which means that you will need a builder for the actual installer which will use CodeDom.
Or you can download the files from a server, which seems faster in this case.
You choose.
To do so i would use a Self-Extract Zip. this is an exe that will unpack itself with all necessary files then you set the after extract command to call and exe of yours which copy everything where you want and then create yourself link on desktop and such. not very difficult.
In the Self-Extract file you can also specify that the content is extracted in the temp folder of the computer allowing you to find stuff using environment special directory
Related
We have an app we wrote deployed onto our terminal servers at work, and keeping it up-to-date is a bit of a pain.
What update mechanisms do people use for app on terminal servers? At the moment we manually copy the new exe + dependencies on witch is just rubbish.
I'm a bit concerned about files being locked by users when trying to update, i cant really just kill the process in case someone is in the middle of doing something. We would like to be able to handle the odd fat client update as well.
Ideally we'd plug something into teamcity/octopus but are open to suggestions
Create a script that copies the exe file to a user specific temp folder, then launches the copied exe. To make the script more efficient, you can have it check the dates of the files. If they are different, then you copy the file over the old one located in the temp folder, else you just launch it.
I am trying to make a custom launcher for Minecraft in C# but I have come across a bump.
I want to add something into it, Minecraft Forge, but the only way I could think of is to change the extension of minecraft.jar to minecraft.zip, extract the contents of the Minecraft Forge.zip and the minecraft.zip into the same folder and then zip that entire folder up into minecraft.jar.
However minecraft.jar has a file named aux.class so whenever my extract script (Made in java) tries to extract it, it simply says:
Unable to find file G:\Programming\C#\Console\Forge Installer\Forge Installer\bin\Debug\Merge\aux.class.
The only other way I can think of is to merge minecraft_forge.zip into minecraft.zip, I have spent around 2 hours looking on Google (watch as someone sees it within a couple of minutes) but it always shows me results for "How to zip multiple files", "How to make a zip file in C#" etc.
So I have come here looking for my answer, sorry if this is a lot to read but I always see comments on here saying "You didn't give enough information for us to help you with".
EDIT: The question in case it wasn't clear is: How am I able to put the contents of minecraft_forge.zip into minecraft.zip?
In your case, if you cannot unzip the files due to OS limitations, you need to "skip" unzipping temporary files to zip them. Instead, only handle input & output streams, as suggested in the answers found here: How can I add entries to an existing zip file in Java?
As you pointed out, "aux" is a protected keyword within windows and it does not matter what the file suffix may be; windows won't let you use it. Here are a couple of threads that discusses this in general.
Ref 1: Windows reserved words.
Ref 2: Windows reserved words.
If you are typing in commands to perform the copy or unzip, there is a chance you can get this to work by using a path prefix of the following \\.\ or \\?\. When I tested this, it worked with either a single or double back-slash following the period or question mark. Such that the following work:
\\.\c:\paths\etc
\\.\\c:\paths\etc
\\?\c:\path\etc
\\?\\c:\path\etc
I used the following command to test this. When trying to rename through windows explorer it gave a "The specified device name is invalid." error message. From the command line it worked just fine. I should point out, that once you create these files, you will have to manually delete them using the same technique. Windows Explorer reports that these text files which have a size of 0 bytes "is too large for the destination file system", ie... the recycle bin.
rename "\.\c:\temp\New Text Document.txt" aux.txt
del "\.\c:\temp\aux.txt"
As far as copying directly from zip or jar files, I tried this myself and it appeared to work. I used 7-zip and opened the jars directly using the "open archive..." windows explorer context menu. I then dragged-and-dropped the contents from forge.jar to the minecraft jar file. Since it is the minecraft jar file with the offending file name the chance of needing to create a temporary file on the filesystem is reduced. I did see someone mention that 7-zip may extract to a temporary file when copying between jars and zips.
7-zip reference on copying between archives
I should point out that my copy of minecraft jar (minecraft_server.1.8.7.jar) did not contain a file named aux.class. I also did not try to use the jar after the copy/merge. Nor did I spend too much time trying to figure out how well it merged the two contents since it appears like there may be a conflict with com\google\common\base\ since there are similar class name but with different $ variable suffixes on them.
I hope these two possible suggestions could give you some room to work with to find a solution for your needs... if you're still looking.
Not sure I have the best title for this question. Feel free to modify it or suggest a change and I will do the edit myself.
I have a standalone executable which wants to maintain a settings.bin file specific to the application. There are two obvious ways to do it:
1. Create/Read the file from the local directory where the executable resides
Positive: User can copy the exe and bin file to multiple directories and have multiple versions with different settings.bin files.
Negative: I don't want to polute executable directory.
2. Create/Read the file from a "hidden" location like the Local Application Data folder.
Positive: Not poluting the executable directory.
Negative: The settings.bin file will be shared amoungst any instance
of the executable regardless of where it is locaed.
I don't want to do either of these solutions because neither meet both of my requirements, which are:
Don't polute the executable directory (IE: don't create a local file).
The settings.bin file is different based on the location of the executable.
Any thoughts? I wanted to embed the settings.bin file as a resource but quickly learned you can't write to an embedded resource. I'm all out of ideas.
Use option 2 with a small modification that cancels your negative point (not shared)
You must have something that you can differentiate between exe files.
If all reside in different paths I would do the following:
1) Hash the location of the executable (md5 of the path)
2) Create a directory in the appdata with the hash
3) Store my files there
Else I would try to enumerate myself compared to other processes:
1) When starting check the app data.
2) Attempt to lock a file for writing at:[App Data]\1\sem.oi
3) If that failed attempt to lock a file for writing at:[App Data]\2\sem.oi
Use the settings in the directory that you were able to open the file in
Hope this helps.
Well, you can define your configuration data into the application resource file like a sequence key-value pairs. In this way that information will be embeded into the your binary file, so hopefully you will meet the both of your requeirements.
no file created specially for configuration
and every file can have it's own built-in configuration, which means you have to made different builds in this case.
What about do not creating a file, but having a flexible configuration on local machine based on the exe path, I think it's hardly possible, if not via some network acess, and some bizzar (in my opinion) architecture.
If you would explain why you have these kind of requirements, may be can give more suitable answer, in case if it's not as is now.
I have an app that has search functionality. The search algorithm is compiled to a separate dll. In the C# code for the search algorithm, I am using strings held in a settings file to point to the directory where the search index resides. But once the search code is compiled, the settings file is somehow incorporated in the dll. I want to have multiple versions of this code running on my server with each pointing to a different location for the index. And I want the operator to change a file to have each version point to something else as they find necessary. Both config files and settings files end up getting incorporated in the dll. How do I then accomplish this? What is the right industry standard way of doing this?
It's strange that the settings file is compiled... are you sure about that? Setting, config and resx files should be copied to the output directory, it's even a property you can modify on solution explorer. Then you should get it's values by doing
System.Configuration.ConfigurationManager.AppSettings.Get("YourKey")
But I think this won't know about user changes until app is restarted. If you want settings to be dynamic you should either store them on a database, or on a file that you open, read and close every time you need it.
Hope this helped!
I am planning to create a screen saver. Thinking of trying out some WPF as well. Anyways, I am not quite sure how I would organize the screen saver on disk in the file system. I have mainly two related issues that I am very uncertain on how to solve:
Normally an application lives, with all its 3rd party assemblies, static resources, images, etc., in the Program Files folder and is run from there. For example C:\Program Files\MyScreenSaver. But (if I haven't missed something) the executable of a screen saver in windows need to have the scr extension and to live in the system folder, for example C:\Windows\System32. How do you program the screen saver so that it can find the "rest of itself"? Would you use the windows registry? Or creat some sort of config file next to the scr file with the path to the rest? And would you make the scr to just be sort of a launcher of an exe in the application folder? Or would this be a bad idea?
I also want the screen saver to download new content from certain places on the internet. But where do I put it, and how does the screen saver find it? If I have understood correctly, an application is not to create new contents in its application folder, but rather in a user folder. How do I find that folder? Do you build it up from environment variables? And in what specific directory should things like this really be in? For example on Vista I see that you have one folder called C:\ProgramData. You also have C:\Users\username\AppData\Local, C:\Users\username\AppData\LocalLow and C:\Users\username\AppData\Roaming. Have also seen a lot of programs dump stuff in the my documents folder (although I hate programs cluttering up my documents folder, so I will probably try to avoid that :p).
What are some best practices when it comes to these issues of laying out your application in the file system? I am want it to be best and "most correct" for Windows 7, which means it will probably work the same in Vista as well (?), but it would also need to work in XP, since a lot of people are using that still.
I'm still using XP :)
System.Environment.SpecialFolders is what you want for these special locations.
Say,
System.Environment.SpecialFolder.LocalApplicationData
For a screen saver I'd try to put most of it in the .exe (.scr) file. It might make the executable quite big but I think it's worth it.
For the downloaded content use application data folder, or maybe allow user to set the location (put the path in registry). For example if you are downloading images, the user might want to put that in My Pictures folder.
You can put it in the System32 (or SysWOW64) folder, but you can also put it in just the Windows folder, which would prevent x86 vs x64 issues.
You can find some other hard to find, but important information about writing screen savers here:
https://github.com/steveniles/MandelZoom/wiki
(Disclosure: I wrote the above wiki as a companion for the source code of one of my own screen savers.)