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
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/
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.
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,
Related
This issue is getting real tiresome and I've been spending atleast 2 days looking around for an answer. Basically, I want to publish a game, and I've hired a friend of mine to test it out before I officially release it. Whenever he runs it, reports as "nothing happends".
These conditions are met:
He has installed the .NET Framework 4.0 and the XNA Redistributable 4.0 (he most likely also has installed other .NET Frameworks and XNA Frameworks as well, because nothing worked).
The game is compiled onto a Release build.
GamerService referenced is removed.
A possible issue could be that he's using Win8, but as my searching experience goes, XNA DEVELOPMENT is only restricted on Windows 8, right?
So, what's going on? I'm clueless.. I even put a MessageBox.Show(); after the execution of my game in my Program.cs file via try/catch, and no results.
Are there any extreme conditions in my code that I need to meet?
Any site describing 100% of all requirements to run an XNA game and the most proper way to build it?
Any issues when using non-distributable "developer tools" in XNA coding? If so, what includes in these "developer tools", and what do I need to modify? (I noticed that on another thread).
An answer to this issue would more than make my day...
Ah, and also, I tried running it on a virtual machine ( Windows 7 ) but then it spat out a messagebox saying Index outside the bounds of the array on a perfectly valid code execution, and various other random errors such as missing files when they clearly are there.
Thank you greatly!
In summary I think your app wont run on Windows 8, let me explain:
Windows 8
A possible issue could be that he's using Win8, but as my searching experience goes, XNA DEVELOPMENT is only restricted on Windows 8, right?
Officially, desktop games using unmodified Microsoft XNA 4/is not supported on Windows 8 in any form:
Microsoft officials have said the XNA tools/runtime environment used primarily by game developers isn't supported on Windows 8. - Read more...
Redistributables
Any issues when using non-distributable "developer tools" in XNA coding?
That depends on whether they are required at runtime on the target machine. That might sound like an oxymoron but in Windows c/c++, I can have an app that depends on Microsoft DLLs but we are not allowed to deploy the DLLs, one must depend on it being present in the OS; service pack or some other form. Is there something you are missing?
Windows 7
Ah, and also, I tried running it on a virtual machine ( Windows 7 ) but then it spat out a messagebox saying Index outside the bounds of the array on a perfectly valid code execution
This is more interesting and I suspect is one of the more testable aspects of your application (also that it is not Windows 8). I suggest you setup a remote-debug session to your Win7 VM or if that is not possible, use Debug.WriteLine() or equivalent displaying critical state contents.
Reading the following (and skimming other areas of the site):
http://msdn.microsoft.com/library/windows/apps/br211361.aspx
It seems as though I have to re-write a program I've been writing in VC# 2010, to be able to put it on Windows Store. Is this true? Can I simply import my project into VC# 2013 and then put it out there? Is there a reason I shouldn't do that even if I could (i.e. it looks different than other Windows 8 apps and users will be off-put by it)?
If I can't import and release my project into Windows Store directly, and this is a little bit of a tangent, but, can I at least import it into Visual Studio 2013, and then begin rewriting/adding the parts I need to to be able to make it compatible with Windows Store? I've never used app stores before, so please be gentle.
In most cases, opening a VS2010 project in VS2013 is not a pain.
You can find 2 kind of apps in the Windows Store :
Modern UI apps (aka Metro)
Desktops Apps
If you want to create a Modern UI app you need to target the .Net 4.5 framework. To do so you need to upgrade to VS2013.
But most of your work will be to rewrite a huge part of your program as the modern UI is not compabible with WPF (and you will need to manage touch devices). Other assemblies also doesn't have all the features of the desktop ones, so you will probably have a little bit of work in that area too.
Here is a link that explain the process of publishing an app in the Windows Store : http://msdn.microsoft.com/en-us/library/windows/apps/jj657972.aspx
If you want to publish a desktop application it seems to me that you only need to provide an URL to download your package. Be careful it is not possible to submit that kind of app with a personal account, you need a company account to do so. You can find more information about that process on MSDN: http://msdn.microsoft.com/en-US/windows/desktop/dd535817
I am using Install shield limited edition to install my WPF application.
My current scenario is like this.
The created set up is available in our website for downloading.
User can download and then Install the set up on their own machines.
I have option to modify the software and will update the modified
installer into the website , so that users will get the updated
software.
My Next step:
In my application I am going to include “Maintenance release (Download Updates)” functionality. So that users can download the latest updations automatically from the software itself.
How Can I do this.? Any help would be appreciated.
Is there any facility in the Install shield for this?
I recommend NAppUpdate. It provides a framework with features for all tasks required for an update process. For example, it lets you check for updates from various sources (Web http / ftp), trigger update checks and replace your binaries with the updated ones.
You still will have to integrate this into your app, so it is not an "out of the box" solution. But my experience is that most out-of-the-box solutions eventually cause headaches due to limited customization possibilities and moreover are rarely free (if this is important to you).
A good introductory article can be found here: The philosophy behind NAppUpdate.
I don't think there is any facility to add that feature through install shield but there is a software update framework for .NET called NetSparkle. You can try that if you want. If you want to implement something on your own then its better to some other websites like code project that provide startup code or similar projects.
Here 's the link for NetSparkle.
There is also a similar question on StackOverflow : Code to check for updates, install new version of app
Is there any way to access the time the app was downloaded (or first launched, etc) as this would be of great help in implementing my trial run feature on my app.
I don't remember how does it stand on the Win8 platform, but for WinPhone7.0/7.5 there's a clear warning/guideline in the official documents from Microsoft, saying:
Do not rely on usage time limited trials to protect your app’s value.
Typically, it is best to protect the value of your full mode app by limiting trial access to key code paths. A user may uninstall and retry an app without restriction so a trial design that offers full mode behavior for a limited time provides only inconvenience as a barrier to reuse.
Source: Creating trial apps for Windows Phone
The problem in time-based trials is very simple: when you uninstall the application, the Phone's operating system will erase it completely. This means, that nothing will be left, not a byte. If you write any data to isostorage, it will be purged upon deletion.
So, if you make a time-base trial and store a "installed date", then the user will simply uninstall the application and install it again, and will be happy to get next free-trial period. If it is OK for you, well, then just be aware of that.
To make a true time-trial you'd need to create some internet service that your application will register to with the phone's/user's UUID, and then the app would need to check at the service to determine whether the trial has passed or have been used up by a previous installation..
What's more, Microsoft Phone Appp guidelines state that generally you should not create an application that "turns off some of its features" at some point of time. This irritates end-users and the makes the whole phone/platform "bad" from the user's point of view, because people don't like to lose what they once had.
IIRC, at some early point of time Microsoft even advised to create two separate applications: one free and without the extra features at all, and one paid with all extra features. Later, TrialModes were included in the Market's workflow and Microsoft's App Licensing API introduced a very easy way to determine if an app works in "free trial" or "fully paid" mode, depending on whether it was downloaded from the market for free or not.
I truly don't know which one is most-recent, so let me paste three:
XNA: http://msdn.microsoft.com/en-us/library/dd282459(v=xnagamestudio.30).aspx
SL: http://msdn.microsoft.com/en-us/library/windowsphone/develop/microsoft.phone.marketplace.licenseinformation.istrial
W8: http://msdn.microsoft.com/en-us/library/windows/apps/windows.applicationmodel.store.licenseinformation.istrial
If you are trying to implement a trial function within your phone application, why not latch onto the libraries that MS provides?
MSDN Creating a trial application
MSDN Sample code for integrating a trial applicaiton
This is only available for WP7.1, WP7.1+ and WP8 (when written for WP7.1)
Microsoft recommends using the WP8 LicenseInformation class, to do
MSDN LicenseInformation class, WP8
Hope this helps!
My C#.NET application is running much slower when the exe is located on the network.
And I'm talking about everything, even the graphical dispay is slower. For example: when a form is already loaded, if I unplug my network cable and minimize and maximize the window, it takes a very long time to redraw itself (whether the cable is plugged or not).
I'm using framework .NET 3.5 SP1.
Any idea on the cause?
My hypothesis so far:
I'm missing some options when building the app?
my corporate antivirus checks more stuff because the exe is on the network
the cache of Windows XP SP3 doesn't work the same way when the exe is on the network
the server is a Novell server: maybe this does change something ?
Thanks for your help!
Leo
Perhaps because the CLR needs to go across the network to read any new assemblies, etc?
You would probably have better luck using a one-click installer, where the application is installed on the local machine but updates can be downloaded from a centralized server.
I'm surprised that unplugging makes a difference. I would expect some difference running from a share, though - you get a different security mode, i.e. not full trust. In full trust most of the internal security is simply skipped. Without full trust it works a lot harder. "Fusion" (assembly resolution and loading) also will have to work harder, but this shouldn't be a problem when repeating operations you've already done once in that session (i.e. when the dlls have loaded).
Have you considered deploying (still to a network share) as ClickOnce (.application)? This should then copy locally automatically and run with a better trust model (and no network performance impact).