Currently I have a VBScript 'application' for support to send to clients to run, and then the client sends back an HTML file with the results. To put it into perspective, the output is similar in nature to Syscomp.exe from Absolute Dynamics except mine is a single .vbs file and there is no 'comparison' feature.
The problem: requirements for this support tool are constantly changing and its scope/purpose is getting larger - too large, I am finding, for VBScript to be the right tool anymore. Ideally - my new tool would have a mechanism for being customized. For example, instead of me having to hard-code all of the requirements / what to look for, there could be a configuration file such as an App.config, or better yet, an XML file with my own markup schema, which can be shipped as part of the application on a per-client needs basis. Note: I require "no installation" because this will constantly be changing, and an installer will make it much less agile; we're not going to ask clients to install every time we send this out.
my desired solution: I need to move to a more general purpose platform. .Net is ideal because we're already a .Net shop. Although if with .Net I cannot come up with a solution to distribute in the same manner as I already am with the current VBScript (a single entity), then I will consider other general purpose programming frameworks if they are mentioned.
What I have tried:
DotNetZip, thanks to Cheeso's help on this SO question: Running a .Net application from a compressed “zip” file. I was able to use this to ship a .Net EXE with supporting DLL's and an App.config, all wrapped up in a self-extracting ZIP. Unfortunately, this doesn't work in Windows XP, unless I'm missing something. EDIT: confirmed this is limitation of Windows XP and Windows Vista, not of DotNetZip. I need my solution to work on XP (many clients have XP or farms of Windows 2003 Server)
7Zip - does not meet my needs because I cannot add a .config to a .7z archive after I have "built" my solution. I was able to do add files to SFX's created in DotNetZip just by renaming it to ".zip", adding the new .config, then removing the .zip extension.
NBox will not work because the packing of any config file (e.g. app.config) would need to be part of my build process. I need a config that I can simply 'drop in' after/outside of the build process at any point and have that be part of the end product that gets shipped
Coffee Cup's Zip Wizzard Does not have a way to unpack the files without user intervention. Also doesn't allow to run an EXE post-unpack
Zip Installer by NirSoft. Does not meet my requirements because it still prompts the end user where to install the files.
ZIP 2 Secure EXE. Unfortunately, this didn't work out either, although I cannot recall what the shortcoming was
NAR. this didn't work because it requires an installation to be run. Other than that, it probably would work out.
the questions:
- Is it possible, given my requirements? If so, where do I start e.g. with a third-party such as one mentioned above, or maybe one I missed?
- Has anyone encountered a similar situation that I'm in, but chose a different route other than a single file/entity application, and would like to share?
Requirements:
- must be a single entity (e.g. EXE, or ZIP)
- must be able to support at least one configuration file, supporting DLL's, etc. A 'robust' application. Edit: for example, after my code is built, it can be zipped as a Self Extracting ZIP. Anyone can 'customize' it via an XML config, then rename the .exe to .zip, drop in their config, and send it along.
- Must work in XP and forward. Edit: We assume .Net runtime has been installed (v3.5 at least)
Fundamentally you can't support XP with a .net application without some external "stuff" - XP does not come with any version of .net installed as standard, so you might have to require users to install .net runtimes before your app can work. On the plus side, if you use .net 4.0 then when you run the program it will tell the user they need the .net 4 runtime, rather than simply crashing as earlier .net applications did.
If we assume that pre-installing .net once is ok, then there are many options:
You can put all your code into a single project and thus build a single standalone assembly (.exe)
Alternatively, if you have many dlls, you can use a tool like ILMerge to merge them all into a single .exe before you ship it, or you can embed the dlls as data resources within the .exe and then use the Application's AssemblyResolve events to allow you to load the dll data from resources as it is needed by the system. Or embed the dlls as data files and then "auto install" them (save them to disk next to your .exe or in the GAC) as the first thing your program does before it makes calls to any of the dlls it ships in this way.
The other part of it is that your application must be standalone - any settings/preferences/resources needed by it need to be set up by the application itself - for example, you can read a preference setting from the registry and if it is not present, use a default value. If you have an XML config file, then embed it as a resource and either read it directly from the resources, or auto-install it on startup, so that your application is "self installing" and totally self contained.