# .Net ClickOnce deployment not working as RemoteApp or Citrix XenApp on Server 2008 / Server 2008 R2

### Question

• We are attempting to deploy a commercial application that chose to use ClickOnce as the deployment model. Due to network latency issues we would like to deploy the application onto a Windows Server 2008 RDP server as a RemoteApp published application. After working with application we found that we can easily install the application for a single user by running the ClickOnce installer from a full RDP session on the server, however when we attempt to start the application by publishing the deployment startup through a RemoteApp, the found that the application won't start and that no ClickOnce deployment error log file is created We have confirmed this behavior exists on Server 2008 and Server 2008 R2 but ClickOnce operates correctly when running as a published application on Server 2003 running Citrix Presentation Server 4.5. We found that we could easily duplicate the issue by publishing Internet Explorer as a RemoteApp and attempting to run a ClickOnce sample application available on the Internet. Attempting to find information on this limitation has been difficult. Is this a known issue or limitation with .Net ClickOnce deployment on Server 2008 (and higher) that would prevent ClickOnce from working as RemoteApp?

Duplicating the issue is very easy. Simply publish Internet Explorer in Server 2008 (or 2008 R2) and visit the website below. Attempt to launch the sample ClickOnce application. It will fail to launch and will not generate any information on why it failed. Now logon to the console of the server, open Internet Explorer, and try the operation again. This time it will succeed and you can launch the ClickOnce application. This appears to be a bug in the .Net framework when running a ClickOnce on Server 2008 (and higher) and is only present when running the ClickOnce application as a RemoteApp or as a Citrix published application (on XenApp 5.0 or higher).

Is Microsoft aware of this issue and when will it be resolved?

Click-Once Sample Application
http://www.lescasse.com/ClickOnce/plus/plus.aspx

• Moved by Monday, March 07, 2011 9:14 AM move to clickonce forum for better support. (From:Common Language Runtime)
Monday, March 07, 2011 1:29 AM

• Hi Wendell W. Pinegar,

Unfortunately, I have not found any document discussed this issue as a known product issue. Maybe it is not a product issue, I think.

And I think the root cause is the clickonce cache feature. Clickonce would need to store its data in a special user's folder called clickonce cache. Then the clickonce cannot access this folder in terminal services, since the terminal services settings(There maybe some security considerations, I think, since I'm not the expert of windows server OS).
And you can copy the clickonce application from the user settings folder to the public place.

And the following thread also discussed this question, and given the solutions and opinions, you can look into:

If there's any concern, please feel free to let us know.
Best wishes,

Mike [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Wednesday, March 16, 2011 1:07 PM

### All replies

• the clickonce forum is under the windows forms category. you may want to try that one instead.

The following is signature, not part of post
Visual C++ MVP
Monday, March 07, 2011 2:53 AM
• Thanks. I'll re-post in the WPF forum.
Monday, March 07, 2011 3:30 AM
• Hi Wendell W. Pinegar,

I think you has got the answer:

This is due to a limitation within the Windows Terminal Server remoting functionality. This is a limitation regardless of how the ClickOnce deployment is initiated include clicking on the deployment URL from within a standard Terminal Server session or using the Start a program on the Programs tab within the Remote Desktop Connection (MSTSC).

Currently, there is no supported solution yet to use ClickOnce in terminal server.

If there's any concern, please feel free to let me know.
Have a nice day!

Mike [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Wednesday, March 09, 2011 7:45 AM
• Mike,

Thank you for replying. We did review Alan's answer on the Technet forums and I'm not sure we are talking about the same issue. As I pointed out in my other post the first reports of this issue online appear to be dated back to September 2008. It's troubling that 2.5 years later we are still dealing with this limitation. I wanted to clarify some of the information we posted and will attempt to state what that we know so far.

1. We've been able to trace the first appearance of the problem to Windows Server 2008 and the problem has been propagated in the most recent code, Windows Server 2008 R2 SP1. So the limitation was introduced in Server 2008. ClickOnce runs just fine in Server 2003 and Citrix published applications.

2. ClickOnce deployment works properly through a full RDP session (on Server 2008 and 2008 R2) so if this was a general terminal server issue then the issue should occur equally on both a full RDP session, RemoteApp or Citrix published applications.

3. We don't have any issues starting up a ClickOnce application that is already in "All Programs" as long as it is run from a full RDP session. So if this were a general limitation in terminal server then the issue should occur always not simply with RemoteApp and Citrix published applications.

4. We setup a custom log file (http://msdn.microsoft.com/en-us/library/ms404265.aspx) for ClickOnce deployments and no log file is generated. The deployment is failing even before it starts.

What we appear to have is a bug that was introduced in Server 2008 that affects ClickOnce applications that are published through RemoteApp or Citrix. Using the sample ClickOnce web site that was provided in the original post we developed a batch file that executes "rundll32.exe dfshim.dll,ShOpenVerbApplication http://www.lescasse.com/ClickOnce/plus/plus.application". The batch file works properly from Server 2003 Terminal Server, Server 2003 TS as a Citrix published app, Server 2008 RDP with full desktop, and Server 2008 R2 SP1 with RDP full desktop. The batch file does not work properly from Server 2008 - 2008 R2 SP1 as a RemoteApp or as a Citrix published application. The batch file also does not work properly on Server 2008 - 2008 R2 SP1 when started through the Programs tab with the RDP client. With this being said it appears that the issue is most likely a bug in ClickOnce deployment code triggered by limitations imposed in Server 2008 (and higher) when running RDP without a full console.

Is there a KB article that has been published that addresses this issue? Is there potentially an open bug report that we could be added to? Is this issue something that is scheduled to be addressed at some point in the future or do we have to wait another few more years before it becomes a priority?

Hi Wendell W. Pinegar,

I think you has got the answer:

This is due to a limitation within the Windows Terminal Server remoting functionality. This is a limitation regardless of how the ClickOnce deployment is initiated include clicking on the deployment URL from within a standard Terminal Server session or using the Start a program on the Programs tab within the Remote Desktop Connection (MSTSC).

Currently, there is no supported solution yet to use ClickOnce in terminal server.

If there's any concern, please feel free to let me know.
Have a nice day!

Mike [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Tuesday, March 15, 2011 7:40 AM
• Hi Wendell W. Pinegar,

Unfortunately, I have not found any document discussed this issue as a known product issue. Maybe it is not a product issue, I think.

And I think the root cause is the clickonce cache feature. Clickonce would need to store its data in a special user's folder called clickonce cache. Then the clickonce cannot access this folder in terminal services, since the terminal services settings(There maybe some security considerations, I think, since I'm not the expert of windows server OS).
And you can copy the clickonce application from the user settings folder to the public place.

And the following thread also discussed this question, and given the solutions and opinions, you can look into:

If there's any concern, please feel free to let us know.
Best wishes,

Mike [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Wednesday, March 16, 2011 1:07 PM
• Mike,

Thanks for the reply. Since a RemoteApp runs under the user profile who launched the app then the RemoteApp would have access to the files in AppData the same as a standard user. It's interesting that Server 2003 doesn't have an issue. This definately cannot be the intended behavior of ClickOnce technology and would need to be categorized as a bug.

Do you know which team at Microsoft is responsible for issues with ClickOnce deployment technology? What would be the best way to notify them of this issue?

Thanks!

Sunday, March 20, 2011 1:42 AM
• Hi,

File a bug in http://connect.microsoft.com under Visual Studio / .NET and post the link back here, and I will send it to the ClickOnce team.

I'm pretty certain this has to be some kind of permissions problem. Make sure that the folder you set to write the logging errors is a folder the user has permissions to access.

Also, I've noticed that with Windows Server 2008, the security is set very high, and you can't use the browser unless you pretty much turn off or modify the security on the browser. CLickOnce uses IE to install and run, so have you tried turning that off and seeing if it helps?

RobinDotNet

Microsoft MVP, Client App Dev
Wednesday, March 23, 2011 9:17 AM
• Robin,

Thanks for following up. To eliminate security issues all of our testing was performed with a Domain Admin account. We have also eliminated Internet Explorer security settings since the same Internet Explorer security settings work just fine when running under the same user on a full RDP session. We've even attempted to run a local ClickOnce application that was deployed through a UNC share with the same results -- it launches on a full RDP session but it doesn't launch as a RemoteApp. A bug report has been filed on this issue. I would be delighted to discuss this issue in-depth with an engineer on the ClickOnce team if they need any additional information. Have a GREAT day!

A link to the bug report follows:

https://connect.microsoft.com/VisualStudio/feedback/details/653362/net-clickonce-deployment-not-working-as-remoteapp-or-citrix-xenapp-on-server-2008-server-2008-r2

Thursday, March 24, 2011 5:57 PM
• Hi,

You're welcome.

And I think this is not a clickonce technical "bug" as you said in your post, but a windows server 2008 access permission problem.

I mean it is the system not allow you operate the data in a special user's folder.

The clickonce technical is just a deployment way, it just take the application and then put it into a special folder in a system, it will not change the system permission.

And have you tried the suggestion as I mentioned in my last post?

I think you can try to copy the application to a public place, and then operate it, to see if it can work.

If there's any concern, please feel free to let us know.

Have a nice day!

Mike [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Friday, March 25, 2011 6:26 AM
• Hi,

After perusing this thread again, and with my own experience with Windows Server 2008, as I stated in my previous post, there is a huge difference in the security of that over Windows Server 2003. Even the Azure team had problems with it -- version 1.3 of the Azure Tools totally broke the IIS logging transfer to blob storage, because the Windows Azure processes didn't have access to the folders where the logs were written!  So I am betting this is a problem with the permissions on the folder structures on the server.

ClickOnce apps do not have any admin or system privileges, so if the folders don't have user-level permissions, it won't be able to create them.

I don't know what you mean by running it as a remote app, my knowledge of terminal servers is meager. It does make me think of Windows XP and the Guest accounts, on which ClickOnce apps don't work either, because of permissions with the Guest accounts. Is there any way you can set the permissions on the C:\users\username\AppsData\Local\ folder(s) when the user connects?

I would take Mike's suggestion, and copy the deployment to a folder on the server and then see if you can run it by running the executable. That does eliminate the question of if it's a clickonce app problem or a problem with the application period.

RobinDotNet

Microsoft MVP, Client App Dev
Friday, March 25, 2011 6:53 AM
• Mike,

Since there is a difference between how ClickOnce behaves when running as a RemoteApp -- it's completely broken without even a hint as to what's wrong AND you take the same user and the same application and it will run successfully using ClickOnce from a full RDP session we are left with the conclusion that this is definitely not an intended design. Something in the ClickOnce code needs to be adjusted to run properly on Server 2008 with the restrictions imposed by RemoteApp or Published Application technology. It's an undocumented limitation that is no doubt a bug in ClickOnce.

Thank you for the suggestion. We developed a workaround when we initially experienced the problem with ClickOnce and have successfully copied the contents of the ClickOnce deployed application to a global location on the RDP server for all users to run the application from. It works fine, however this particular application didn't sufficiently document the additional setup required to run the application manually outside of ClickOnce because they didn't envision that a customer would want do this so we ran into several snags in the process and had to revert to creating an INI file to point the application to a central file server for other shared network files. Although this was undocumented in the latest version of the app it still worked -- which was good for us but just a lucky circumstance. It isn't a solid long-term solution but it does work for now. We may not be so lucky in the future. This particular application is in the HR / Payroll sector and is updated at least once quarterly. The vendor does not currently deliver an MSI package to install the client on a RDP server so we'll be forced to revert to running the ClickOnce deployment once after each update and then manually copy the updated files to the shared location on the RDP server. It isn't clear whether the vendor will support the way we choose to run the application or if it will continue to work in future updates.

So we do need a long-term fix that includes correcting this limitation. We're not the only organization to spot this issue and there are no solid solutions to this issue or even an adequate explination of why this issue occurs. We appreciate the dialog and hope that the Visual Studio team will come up with something eventually...

Friday, March 25, 2011 11:23 PM
• Robin,

Thanks for following up. We agree. There is a big difference in the design philosophy behind Server 2003 and 2008. Microsoft began an initiative to have technology delivered as "secure out of the box" many years also and we can all benefit from the results of this design as operating system technology as progressed. This is all very good however when the underlying operating system changes each team must remember to assess the overall impact to their components and make code adjustments as necessary to support any new technical limitations imposed. The ClickOnce team unfortunatelly missed this one.

The issue we are seeing doesn't exist in Windows 2008 (or R2) if you are running a standard RDP session. You can use a ClickOnce application without issue so this effectively eliminates operating system user-level permissions on the .Net cache folder structure. The problem only surfaces if we attempt to use RemoteApp technology on Server 2008. RemoteApp allows a user to launch an application and the application continues to run at the server not on the desktop, while it appears to the user like it is running locally on their desktiop PC. So unlike a pure ClickOnce deployment where files are downloaded from the server to the desktop and then the desktop runs the application -- when you use RemoteApp all of the files remain and data remain on the server and only the application window, mouse clicks, etc are transferred to/from the desktop PC. It's essentially like running the application from a thin-client. Very little happens at the desktop. In bandwidth sensitive environments (or with specific application designs) a ClickOnce application may benefit greatly from deployment via RemoteApp. It's critical to understand how RemoteApp technology works (or doesn't work in this case) to understand that there is no significant technical difference between a RemoteApp and opening up an RDP client to a full remote server connection and running the ClickOnce application from within the RDP session. It's technically very, very similar. This is why we believe that this particular issue is a bug and not simply a new limitations of Server 2008 security. We've done enough testing to be able to confirm that this limitation doesn't make any technical sense.

Mike's suggestion is one that we had already implemented several weeks ago when we initially encountered the issue. Due to the issues cited to Mike on our previous post we believe this may only be a short-term solution and not the best approach to take over the long-haul.

Anyway, thanks for the assistance filing the bug report and for seeing that the issue is forward to the ClickOnce deployment team within Visual Studio. Let us know if you have any further questions! Have a GREAT weekend!

Wendell W. Pinegar

Friday, March 25, 2011 11:39 PM
• Hi Wendell W. Pinegar,

As we discussed above, I think this is a windows server 2008 system permission problem, rather than a clickonce problem.

And I also don't think so this is a product issue, it just a security consideration. If the system let you access the private folder at anytime, then do you think so the private data in the private folder is also secure enough?

And if you think this is a product issue, then the experts in the MS Connect website can help you to solve your doubt.

I suggest you to create a thread in the windows server 2008 forum to look for more opinions on this question.

If there's any concern, please feel free to let us know.

Best wishes,

Mike [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Tuesday, March 29, 2011 7:18 AM
• Mike,

Thanks again for following up. Here is some additional information that could help. I opened a full RDP session on a Server 2008 RDP server and launched the sample clickonce deployment on the original post above using the URL through Internet Explorer. After launching the application and allowing it to deploy we were able to locate the application ClickOnce cache and open the .net application deployment directory at the following path:

C:\Users\wpinegar\AppData\Local\Apps\2.0\P08J6C8T.WO5\06YX7PV0.K90\plus..tion_9f7a6d8a971f920b_0001.0000_60b71991da0b7392

We were also able to launch the application directly using the deployed .Net executable at the following path:

C:\Users\wpinegar\AppData\Local\Apps\2.0\P08J6C8T.WO5\06YX7PV0.K90\plus..tion_9f7a6d8a971f920b_0001.0000_60b71991da0b7392\Plus.application

So far the process works as expected. Now here is where things break down. I took the same user account and on the same server and I launched Internet Explorer as a Citrix published application (we receive the same results when using RemoteApp). I then tried to launch the ClickOnce sample application and it didn't work. Nothing happened and there was no indication of a problem from the ClickOnce deployment code. No deployment log was generated. We then downloaded the ClickOnce manifest by using "Save As" in Internet Explorer to save the manifest to a location on the server where we then proceeded to attempt to launch the locally downloaded manifest (through the IE Web Browser and directly through the Explorer shell) and again there was no success. So we opened the ClickOnce cache (through the IE Web Browser and directly through the Explorer shell) by entering the direct path above and we were able to successfully launch the downloaded application directly from the ClickOnce cache.

This effectively eliminates all security considerations and points squarely to a limitation in ClickOnce. The only part of this process that didn't work as expected was attempting to run the ClickOnce deployment as a published application or RemoteApp. We are able to duplicate these results across all of the Server 2008 and 2008 R2 servers we have attempted.

Let us know if you need any additional information on this issue! Have a WONDERFUL day!

Wendell W. Pinegar

Wednesday, March 30, 2011 5:01 AM
• Posted by Patrick Gunerud on 4/6/2011 at 7:17 AM I was able to get this to successfully working on a 2008 R2 Terminal Server by configuring the Remote App as "C:\windows\explorer.exe" then setting the command-line arguments to be the path to the .application manifest. This will launch explorer which will then launch the ClickOnce application. Explorer will disappear after the ClickOnce application is launched

I have confirmed that the workaround posted by Patrick Gunerud on the bug report that I filed does successfully resolve the issue on 2008 R2 when running ClickOnce applications as a RemoteApp. This should be a usable approach for anyone who would like to deploy ClickOnce applications through RDP. Thanks Patrick!

Wendell W. Pinegar
Thursday, April 07, 2011 5:47 AM
• Hi Wendell W. Pinegar,

Best wishes,

Mike [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Thursday, April 07, 2011 6:25 AM
• Remote apps is a new feature offered in Windows Server 2008. At this time, ClickOnce does not support it, so it's not a bug. There's a rumor that they might support it in WS2008 in the future and include a fix in some update, but I couldn't pin that information down. If I get anything more specific, I'll post back here.

RobinDotNet

Microsoft MVP, Client App Dev
Monday, April 11, 2011 6:39 AM
• Thanks for the follow-up Robin. It would be helpful if this limitation was documented in a KB so that it's clear that this isn't a supported deployment model. Finding information on this limitation has been very difficult.

While Windows Server 2008 RemoteApp is indeed new, the same issue exists if you attempt to run the ClickOnce deployment by running the RDP client and setting the option to "Start the following program on connection" to startup the ClickOnce application immediately upon connecting to the remote server. This isn't a new feature. The issue also exists when attempting to run a RemoteApp as a Citrix published application, which also isn't new but is a 3rd party extension that is built on Terminal Services. So to say that RemoteApp is new and therefore this deployment model isn't supported may not be the full story. It has become apparent that ClickOnce team may not have fully tested .Net deployments running on Server 2008. Particularly there appears to be a requirement in Server 2008 for the Explorer shell to be running for ClickOnce to function and if the Explorer shell isn't running the ClickOnce code fails (for evidence of this see the workaround that Patrick Gunerud posted on the bug report). So ClickOnce is simply broken on Server 2008 under several real-world conditions and it has been for years.

Hopefully this will be addressed in the future. Have a GREAT day!

Wendell W. Pinegar

Tuesday, April 12, 2011 12:40 PM
• Dear Wendell,

I have the same issue with Server 2008 R2 SP1 and XenApp 6.5. I tried both to publish the manifest .application (that reside on a different server) via IE and explorer.exe but none of them are working, despite you say that the second resolved the issue.

Am I missing something? Do you have additional steps to suggest?

Please let me know, it's a big issue in my company not to be able to deploy our ERP (the ClickOnce application) by using XenApp, that we purchased exactly for this purpose.

Regards.

Alessandro

Thursday, December 06, 2012 10:23 PM
• Alessandro,

Although we haven't dealt with this issue recently we can confirm that publishing the application "C:\windows\explorer.exe" and setting the command-line argument to the full path of the click-once manifest (the fully qualified path to the .application file) does correct the issue and allow the ClickOnce application to be launched via RDP and XenApp environments on Server 2008 R2. Can you explain how is your click-once ERP application distributed? Via a URL or a UNC share? Are there any prerequisites required (such as client-side runtime objects) that must be installed by an administrator prior to allowing the ClickOnce application to deploy successfully? Exactly what error do you see? Can an administrator account run the published application? If an administrator can run the application from a full RDP session directly from the ClickOnce deployment directory or URL but you cannot run the application as a RemoteApp or Citrix Published Application then you may be dealing with the same issue we encountered. However if this isn't the case you are likely dealing with a different issue.

For example some of the vendors that have written applications with DotNet didn't correctly compile their applications so the application may work correctly on 32-bit systems but doesn't work correctly on 64-bit systems. We've had to use CorFlags.exe on more than one occasion to change the header of the application and force it to run as a 32-bit application or the application would experience issues when launching on Server 2008 R2 or Windows 7 or 8 64-bit. So the developers of some popular applications in some instances miscompile the DotNet application and forget to target the application as 32-bit (x86) instead of the default "Any CPU" -- which causes the app to run as a 64-bit app on 64-bit systems and a 32-bit app on 32-bit systems....which breaks some apps.

Wendell W. Pinegar

Friday, December 07, 2012 12:50 AM
• Dear Wendell,

• The ERP application can be launched if accessing via RDP to the XenApp server. I can also fire the application within the RDP session with the following syntax (from a cmd session): "C:\windows\explorer.exe" "http://iis-server/path/to/application/erp.application" or even "C:\windows\iexplore.exe" "http://iis-server/path/to/application/erp.application"
• The application now is accessed by publishing the desktop, so normal users (Domain Users) have all prerequisites in place to run it.

Probably the issue is related with 64bit of the OS and the fact that the ERP runs in 32bit mode. If this is the case, do I have any chance to overcome the issue? What if I play with the application type (streamed)?

Thanks again for your precious feedback and have a great day!

Alessandro

Tuesday, December 11, 2012 2:55 PM
• As an additional specification to my reply, when I run the application from my client via web interface (I am logged in with an user who is member of Domain Admins) I see an IE bar opening but immediately closing, an nothing else happens. On the XenApp server I have no evidence of this "problem": where should I look? maybe in the event viewer for a specific message?

Thanks again.

Alessandro

Tuesday, December 11, 2012 3:04 PM
• I've just found and tested this workaround that is working for me: http://jonspallone.com/2012/02/08/admins-click-once-twice-three-times-for-clickonce/

The only bother is that whenever I update the application I have to recopy the folder under the C:\Users\<user>\AppData\Local\Apps\foo\bar path. But that's all, I hope.

Alessandro

Tuesday, December 11, 2012 3:48 PM
• The problem can be resolved by:

1)  On the TS:
Copy the file: C:\Windows\explorer.exe
(call the copy test.exe, for example, and save it in the same Windows directory).

Publish test.exe and write the desired URL of the .Net application in the parameters line.

Note:
In case that you have more than one Terminal Server, perform step #1 on each one of Terminal Servers.
Friday, February 01, 2013 2:37 PM
• The problem can be resolved by:

1)  On the TS:
Copy the file: C:\Windows\explorer.exe
(call the copy test.exe, for example, and save it in the same Windows directory).

Publish test.exe and write the desired URL of the .Net application in the parameters line.

Note:
In case that you have more than one Terminal Server, perform step #1 on each one of Terminal Servers.

So you are saying this works via Ericom's PowerTerm WebConnect with your instructions?

Faye Jasman

Monday, February 11, 2013 6:38 PM
• I found this thread and others while trying to figure out how to run a clickonce app as the program to run (no desktop) in and RDP session. All of the proposed solutions either don't work or aren't acceptable in our environment.

After much experimentation I found that this works.

Create a batch file that contains

• C:\Windows\explorer.exe "http:\\distserver\MyAppFolder\MyApp.application"
• pause

Set this batch file as the program to run in your RDP connection. When the session is started the first line will kick off the application and as long as you don't hit a key to exit the batch file the application will run as expected. After closing the application hit a key to exit the batch file and the session will close.

Please note! If you exit the batch file before the application starts or while it is running the session will immediatly close.

While this illustrates what the problem is it's probably not what you want to use in a production environment. We chose to create a PowerShell script to launch the application and then monitor for it closing so the session could be closed without user intervention. Since some of our clickonce applications can be told by an administrator to update while the app is running and this causes the app to close and restart we had to take that into account.

Param( [string]$URL )$exe = $URL.Substring($URL.LastIndexOf("/") + 1)
$exe =$exe.TrimEnd(".application") + ".exe"
"executable = $exe"$user = whoami
$user =$user.TrimStart("mfc\")
"user = $user" function getProcess() { process {$proc = (GET-WMIOBJECT -Query "Select * from win32_process Where Name='$exe'" | where-object {$_.getowner().user -eq $user}) } end { return$proc }
}
start-process "C:\Windows\explorer.exe" $URL$cnt = 0
do
{
sleep 5
$cnt++ "$cnt"
$p = getProcess } while ($p -eq $null -and$cnt -le 12)
if ($cnt -ge 12) { "didn't get started" } else { "$exe is running"
$cnt = 0 do { sleep 5$p = getProcess
if ($p -eq$null)
{
if ($cnt -eq 0) { "$exe has quit running" }
$cnt++ } else { if ($cnt -ne 0)
{ "$exe has started running again" }$cnt = 0
}
if ($cnt -ne 0) { "$cnt" }
} while (\$cnt -le 6)
"finished"
}

Since running a PowerShell script from a RDP command line entry gets complicated we have decided to run this via a one line batch file.

powershell.exe -executionpolicy bypass c:\...\StartClickOnce.ps1 -URL 'http:\\distserver\MyAppFolder\MyApp.application'
Dave
Friday, June 21, 2013 4:53 PM
• I have found this works also, but only with a UNC path, not a URL.

Faye Jasman

Friday, June 21, 2013 5:12 PM
• This is how I finally got it to work for me

I created a batch file with just the following:

set __COMPAT_LAYER=Win2000

"C:\Program Files (x86)\Internet Explorer\iexplore.exe" http://server/myapp.application

That would allow the app to launch, but if I exited out of the app, the Receiver windows stayed open.  So, per CTX891671, I added the below registry entry, and in my case it was dfsvc.exe (found that by a process of elimination) that was hanging around.  Once I edited the registry, I was able to launch the app, close the app, and the Receiver window closes.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI

Value Name:LogoffCheckSysModules
Type:
REG_SZ
String:
MyAppName.exe

Faye Jasman

• Proposed as answer by Wednesday, September 23, 2015 8:44 AM
Friday, December 06, 2013 9:16 PM
• This is how I finally got it to work for me

I created a batch file with just the following:

set __COMPAT_LAYER=Win2000

"C:\Program Files (x86)\Internet Explorer\iexplore.exe" http://server/myapp.application

That would allow the app to launch, but if I exited out of the app, the Receiver windows stayed open.  So, per CTX891671, I added the below registry entry, and in my case it was dfsvc.exe (found that by a process of elimination) that was hanging around.  Once I edited the registry, I was able to launch the app, close the app, and the Receiver window closes.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI

Value Name:LogoffCheckSysModules
Type:
REG_SZ
String:
MyAppName.exe

Faye Jasman

Works Great
Wednesday, September 23, 2015 8:44 AM