12

we are deploying our application with ClickOnce and we noticed that when we start our application by clicking the ClickOnce desktop icon, the application start slower (it takes at least 30-60 seconds more) than while started directly from the .exe. I've seen that it's not an unkown issue ( Slow startup of Clickonce winforms application after update ) but it seems it's still unresolved. I'm wondering why that would happen and how to fix that.

I'm only using one machine so I guess it's not machine-related, not antivirus-related.

I'm noticing different memory management pattern during startup: the ClickOnce deployment takes more time and after a while it deallocates some memory. We are still talking about 12 MBytes in difference ( 67MB via ClickOnce, 50 via direct .exe).

This is driving me nuts...

Thanks

Community
  • 1
  • 1
Massimo
  • 692
  • 2
  • 11
  • 29
  • 3
    Did you try configuring clickonce to search for updates after application starts? – Pikoh Feb 11 '16 at 09:17
  • Hi, thanks for the comment. No, I've not tried. I thought that the search for updates terminates after the first little pop-up (that notifies the user that it's looking for updates). I'll surely try that! – Massimo Feb 11 '16 at 09:19
  • @Pikoh Nope, no changes in performances (other than removing the initial update part) – Massimo Feb 11 '16 at 10:07
  • Which windows version do you use? Maybe the exe / dll files will be send to the SmartScreen filter that is enabled by default in newer windows version. And that process cann take some time. – Matthias Feb 12 '16 at 22:40
  • Hi @Matthias , for my tests I'm using Windows 7, I will try to have a look at the SmartScreen filter and I will let you know. Does the SmartScreen trigger silently only when clicking the Clickonce desktop shortcut? – Massimo Feb 13 '16 at 07:29
  • 1
    30-60 seconds is a very long time and eliminates the obvious. There are only two kinds of issues that could cause such a delay. Network timeouts are around 45 seconds, but should be eliminated when you configure CO to not look for updates. Next one is the common plague, the shrink-wrapped malware that programmers voluntarily install. Disable your anti-malware product and try again. – Hans Passant Feb 13 '16 at 13:31
  • @HansPassant it's worth noting that the first installation is done from http. What I don't understand is why starting from .exe is faster than clicking on the desktop icon. Unfortunately I can't disable the anti-malware, I'm on a client's machine – Massimo Feb 14 '16 at 07:29

2 Answers2

3

I guess it's not machine-related, not antivirus-related.

You need to prove that hypothesis by installing the same anti-virus your client has on a dev VM. If you cannot reproduce the slow start up compare ProcMon traces between the machines.

I believe Hans is on the money and the anti-virus is the most likely culprit, as per the correct answer in the QA you refer to in your question:

I have seen very poor performance (minutes vs a few seconds) for a newly deployed first run .Net application is the users are running antivirus software as the antivirus tool checks the newly Jitted assemblies are not malicious.

Make sure you're using .NET Framework 3.5 SP1 or above as "there are significant performance improvements in the area of startup. Particularly with WPF applications" and 3.5 SP1 includes Splash Screens.

A Splash Screen could be a quick (temporary) fix. Alas, not an ideal solution.

ClickOnce is getting pretty old now and there have been a lot of advancements in this field so why not adopt another strategy with a different deployment mechanism, such as Windows Installer and an Update Menu in the app. I detail the steps to make an MSI installer to Install to same path when upgrading application.

If you want to be strict about everyone being on the latest version instead of ClickOnce it would be better to have a web service the app pings on start up and downloads and executes the update when a new version is released.

Also, take tips from Google in this area. You remember the Jeff Atwood article: http://blog.codinghorror.com/the-infinite-version/

enter image description here

If you dont use ClickOnce you can use things like NGEN AND bsdiff, possibly even Google courgette.

There's some other ways to speed up the startup of a ClickOnce application discussed here.

While this may not answer your question directly, hopefully it gives you food for thought on how to identify the root cause and/or use a different more up-do-date method for rolling out updates.

Community
  • 1
  • 1
Jeremy Thompson
  • 61,933
  • 36
  • 195
  • 321
  • Hi, really nice and welcome answer, but I still can't find what's being done under the hood when I click on the desktop clickonce icon. The action pursued by the clickonce application between the click and the execution of .exe where it has been deployed. I tested the clickonce deployment on a desktop Win7 PC, disabled every possibile antivirus and windows UAC but the issue remains the same. What is causing the different memory load (hence the speed difference, I guess) between the two modes? Unfortunately I can't change the deployments method :(. – Massimo Feb 17 '16 at 08:59
  • Can you confirm after its installed once the startup time is much quicker via the CO desktop icon? You can use CLR profiler and check the big chunks in Gen2 to see that 12mb, if that's not the way you're already using to determine the extra memory allocation. – Jeremy Thompson Feb 17 '16 at 09:03
  • Also, on second run of the app (after its installed) is there a lot of IO happening when you open the app? You can use ProcessMonitor's FileMon trace to see the IO activity.. Silly question but you have set all the DLLs and EXE with a version number, yeah? It's not using a wild card for build number, no CD? – Jeremy Thompson Feb 17 '16 at 09:12
  • Hi Jeremy, I had some spare time to investigate the issue (sorry I left you hanging but we were going to production... :) ) and I found that the 30 seconds difference is caused by the function "InitializeModules" in Prism.Unity WPF application we are deploying. I'm on version 5.0.1 and I can't seem to be able to find any correct pdbs to further investigate the exact point of failure. I'm still wondering why ClickOnce would interfere on loading time (I guess it checks the dll unity is trying to load) after the update check process. – Massimo May 11 '16 at 15:43
0

When you publish the build please choose the option of running the app in offline mode. Otherwise the clickonce installer will try to launch the app from your server rather than local exe.

Please let me know if there are any other scenarios need to look into or this helps.

Thanks,

Sathik Khan
  • 439
  • 4
  • 13
  • The check "The application is available offline as well (launchable from Start menu" is already checked, Thanks – Massimo Feb 20 '16 at 08:33
  • Please also verify what are the clickonce related events are captured. That may take time to load. Sorry for very hight level but hoping this may help. – Sathik Khan Feb 20 '16 at 08:41
  • I'm not following, what are the clickonce related events? – Massimo Feb 20 '16 at 08:54
  • Please go through this link you will get an insights and will also get to know how to customize the clickonce installation... https://msdn.microsoft.com/en-us/library/ms404263.aspx – Sathik Khan Feb 20 '16 at 09:09