3

I've attempted just about everything to get our ClickOnce VB.NET app to run under Terminal Services as a RemoteApp. I have a batch file that runs the .application file for the app.

This works fine via RDP desktop session on the terminal server. As a TS RemoteApp, however, well... not so much.

I get a quick flash of command prompt (the batch file) on the client system and then... nothing...

Same goes for having it point to the .application file directly (without using a batch file) or even copying the publication locally and having it point to that.

I found a technet.microsoft.com discussion about a similar issue, but there's no resolution to it listed.

For anyone who has run into this before and got it working, what did you have to do?

We currently use RemoteApp's for everything else on that server, so I'm hoping to stick with that if possible.

The current workaround is to build and run an MSI-based installer for the app on our terminal server whenever we publish via OneClick out to the network, but this can be quite a pain at times and is easy to forget to do.

Since the app works fine via Terminal Services when run in full desktop mode but not during RemoteApp, I don't think it's anything specific to Terminal Server permissions so much as ClickOnce requiring something that isn't available when running as a RemoteApp.

Kevin Fairchild
  • 10,501
  • 6
  • 30
  • 51

8 Answers8

8

The Key to getting it to work is to use Windows Explorer "C:\windows\explorer.exe". This process is the base process when you login to a full session.

If you setup the RemoteApp to use Windows Explorer and the command line argument of the path to the .application file for the ClickOnce application then it will work when launched as a remote application. Windows Explorer will flash for a second when it starts, but it will disappear then the ClickOnce application will launch.

Patrick
  • 96
  • 1
  • 2
1

Why does it have to be a ClickOnce application? I would consider just deploying the exe file and assemblies.

I know it only half a solution, but if the application does not change much, it might be a good solution.

Thomas Jespersen
  • 11,101
  • 12
  • 43
  • 54
  • 1
    The code base changes fairly regularly. We use it within our intranet as well. By using ClickOnce, we can ensure all of the clients always get the latest code, have any prerequisite libraries, etc. all with very little hassle. – Kevin Fairchild Sep 22 '08 at 03:07
1

Faced the same problem this morning and got it resolved by copying the clickonce app's directory from the user settings folder to somewhere like c:\MyApp\ - I know its nasty and not very ideal.. but good enough for me!

  • You would have to make sure you do a manual update in your application otherwise it would never check for updates without running the .application? – Jake Edwards Dec 03 '14 at 01:04
1

I believe your problem is related to the fact that ClickOnce needs to store it's data in a special user folder called the ClickOnce application cache. Apparently because of how Terminal Services sets up user folders ClickOnce can't access this in TerminalServices mode.

See this link for more information.

http://msdn.microsoft.com/en-us/library/267k390a(VS.80).aspx

There may not be a way to do it :(

splattne
  • 100,048
  • 51
  • 202
  • 247
Don
  • 1,060
  • 1
  • 20
  • 27
  • When run as a remote desktop session, the ClickOnce deployment does work, however... When run as a RemoteApp, there's a quick flash on the client system of it checking for prerequisites and then nothing. – Kevin Fairchild Jan 27 '09 at 19:30
1

Can you launch the .exe directly? It's buried under your profile in \AppData\Local\Apps\2.0[obfuscated folders], but you should be able to find it.

That will skip the built-in update process, but if it can be launched that way you could then write code to do a manual update after the application starts.

codeConcussion
  • 12,097
  • 8
  • 48
  • 59
  • 1
    Yes. The application DOES start via that method. The main limitation is that it only works if the user has started the app at least once already, I guess... But, still, I guess it's a start... – Kevin Fairchild Feb 03 '09 at 16:41
  • I went ahead and gave you the bounty, since your solution at least got it to load. Now I just need to figure out a way to handle that first launch... Logging in as the user probably isn't practical. – Kevin Fairchild Feb 03 '09 at 16:47
  • So each user needs to link to their .exe? Could everyone link to one .exe? There may be security issues that arise when trying to do that though. Sorry for all the questions but TS RemoteApps are barred from my work computer. – codeConcussion Feb 03 '09 at 16:54
  • Also, tyvm for the bounty even though I only got you half-way there. – codeConcussion Feb 03 '09 at 16:54
  • I doubt linking to a single .EXE would work, but your suggestion has at least narrowed things down a bit... Drives me nuts, though. Using the same credentials, it should either work using full desktop and RemoteApp or not work. But working with one way and not the other is a pain... – Kevin Fairchild Feb 03 '09 at 17:00
1

We recently ran across this issue and decided to post a bug report on this issue to the Visual Studio development team. Feel free to comment on the bug report. It has to be a bug in ClickOnce caused by some changes in Server 2008.

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

We also have a discussion on the MSDN forums covering this issue:

http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/7f41667d-287a-4157-be71-d408751358d9/#92a7e5d9-22b6-44ba-9346-ef87a3b85edc

Wendell W. Pinegar
  • 11
  • 1
0

Try using RegMon and FileMon when starting the app - You may be able to track it down to a file and/or registry permission issue.

DJ.
  • 15,477
  • 3
  • 39
  • 45
0

Also maybe check the event logs to see if anything's getting logged when the process fails.

Don
  • 1,060
  • 1
  • 20
  • 27
  • Unfortunately, there don't seem to be any event logs generated for the error. Just events you'd see associated with any other typical login. – Kevin Fairchild Jan 28 '09 at 20:49