Compile time library or module

[owinsloe]

Hi, I'm trying to achieve a few things at once and need some guidance or suggestion on the best path.

I want to create a product that has two execution modes, GUI and batch (commandline). However I want both products to share source code (functions) so I do not have to maintain parallel source streams.

The dual execution mode requirement is to allow users to perform manual execution of the product and be assisted via a nice GUI presentation and the commandline is to allow automatic scheduled task runs (user input in this mode is supplied via a series of parameters stored within ini files).

The other requirement is that I want the distribution of the product to be compiled. I do not want the ps1 source scripts to be distributed.

I would really like the ability to examine whether the compiled exe has been supplied commandline arguments and if so run in batch mode and if not fire up the GUI form, but this does not look possible, I'm guessing because of all the form assemblies that have been loaded.

I suspect that I will need to distribute TWO executables (the product is called "refresh") so I'm expecting that I will have a refresh.exe (commandline) and refreshUI.exe (GUI).

Is there a way to compile the same source as GUI and commandline? I'm happy to add additional checking to examine how I have been launched.

If this is not possible what would be the best recommendation to achieve the desired result?

Thanks in advance.

[Alexander Riedel]

The EXE headers of console applications and windows app are different, so one cannot act as both.

I would suggest to use two executable files as you already pointed out. Examine the command line in the Windows one and launch the command line program is warranted.

If you do it the other way around you get a flashing console window.

Put the common code between the two into a module.

[jvierra]

Alex is right if you bootstrap from a forms script but if you bootstrap from a standard sctipt that calls into either you can have only one EXE. Putting everything into a module is, of course, another approach but will not make teh scritp easily portable although I may be missing something.

[jvierra]

Just to clarify - it can be done in one EXE - I have done it but not with PowerShell Studio. Whether you choose to do it as one or two is up to your requirements.

[owinsloe]

Thanks for the responses guys. I have also done this before using Perl (which we're now replacing with PS) and wasnt sure how easy (if at all) it could be done in Primal Forms.

Ok, time for a dumb question...
If I use a module for common functions then the module file needs to be copied with the executable for importing (is this correct).

Or...is there a way that I can import common code at the time I compile the executable so the executable is totally stand-alone....ie. when I distribute to our various servers only the refresh.exe and refershUI.exe will need to be sent?

[jvierra]

I would maintain a shared source tree and compile the same common module into bot EXEs. (not compiled) A so called compiles module is really just a compressed version of the excluded files that is extracted when the EXE is run. You can place common script modules into a subdir of the EXE dir and the file will be shared but will have only one source.

[owinsloe]

@jvierra, thanks again......yes, I had pretty much came to the same conclusion.

[jvierra]

I tested it to be sure and it works as I would expect it too work.

It is the same with compiled projects. We place common code in a separate location and include it in the project. There are various ways to do this depending on the build and project environments.