Is there a way to properly access the isnetworkdeployed property from a complied EXE (using Quest PowerGUI)?

Question

I have a small PowerShell script wrapped in an exe (using Quest Power GUI). This exe is then deployed to a UNC path using mageUI.exe (i.e. through a 'ClickOnce' deployment).

Now, there is a namespace available to us:

System.Deployment.Application

This namespace allows us to figure out if the tool is network deployed + the originating download URL/UNC of the exe.

So I added the following lines in my PowerShell script (which was then compiled into an exe by PowerGUI)

# Line 1. Load the assembly
[System.Reflection.Assembly]::LoadWithPartialName("System.Deployment")

# Line 2. Utilise methods in the assembly. Below line will give either false or true, depending if the caller is deployed as a 'ClickOnce' app.
[System.Deployment.Application.ApplicationDeployment]::IsNetworkDeployed

After publishing this exe as a 'ClickOnce' application (using mageUI.exe), putting it on a network share, and then executing from some other server (which has access to previously said share), I still get the following output:

# Output of Line 1 (This signifies the assembly was loaded successfully)
GAC    Version        Location
---    -------        --------
True   v4.0.30319     C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Deployment\v...

# Output of Line 2
False

Not sure what I'm doing wrong. The property IsNetworkDeployed (Line 2) should have returned true.

Answer 1

Seeing that there is no solution using PowerGUI (since the script is extracted into a temp folder during execution), I had to do the following:

 1. Create a 'caller' / 'wrapper' executable using [PS2EXE](https://gallery.technet.microsoft.com/scriptcenter/PS2EXE-Convert-PowerShell-9e4e07f1)
 2. This executable becomes the 'entry point' while deploying as a clickOnce application.
 3. Since the 'wrapper' is executed 'in-memory', the deployment methods/properties from System.Deployment work (if it's deployed through clickOnce).
 4. There is some logic written in the wrapper exe which calls the second (which contains the actual working) executable. Ex:

IF ISNETWORKDEPLOYED, THEN:
    PARSE THE URL ARGS / PREPARE THE ARGS AND PASS IT TO THE SECOND EXECUTABLE (which was compiled using Quest PowerGUI previously)

I am open to any other solutions.

Answer 2

As it appears that the concerned script does actually runs locally (as suggested), which appears to be caused by the exe wrapping, Instead, you might want to browse (C:, CD \Path) to your exe location and use the current location:

(get-location).Path

General Note
I would reconsider the overall design knowing that this wrapper is probably (mis)used to cover sensitive information (as hardcoded passwords), called Security through obscurity. If that is indeed the case, a (legal) hacker will easily shoot a hole into this. There several ways to deal with sensitive information in scripts by e.g. limiting the shared credentials and/or using the credentials of the current user instead.