We have a strange problem. We have a click-once deployed application at a customer site that is experiencing slowness. It happens every time they launch the application, regardless of whether new updates have been applied or not. So it has nothing to do with first time loading slowness. The target framework is .net 4.5 and the application itself is a wpf application.
If we execute the .exe directly from where the click-once install puts the files in, then there is no delay whatsoever.
As far as I can see there is nothing that we are doing that is special in code...that is specific to click-once installation.
Any ideas?
when a clickonce application starts up, it checks for updates. Where do you have the updates stored? That may be where the slowness is coming into play.
On the publish tab, under updates, you can specify how often your app will check for updates. It can check for updates after the application starts which will speed up start time, however, updates will not be installed until the next time your app runs.
Related
I try all the possible configuration in ClickOnce but the application only updates on restart.
I want the application to update after the application startup but in VS 2022 the update after startup is blocked as we can see in the following image:
I am using .net core 6 and my IDE is VS2022.
According to the documentations, checking for update before the application starts, is the default and only option available for .NET 3.1 and newer versions:
For .NET 3.1 and newer applications, checking updates before the application starts is the only update option supported.
ClickOnce update strategies
Here is a summary of main ClickOnce update strategies:
Automatic update - Check for updates after application startup
In this strategy, ClickOnce will check updates in the background when the application starts. Then, the next time when the user starts the application, based on the result of previous check-for-update, if an update was available, it shows a prompt to the user asking to download and install the updates.
Main use-case for this scenario is low-bandwidth networks or large applications when updates takes longer to download and install.
Automatic update - Check for updates before application startup
In this strategy, every time the user starts the application, the application first checks for an update and if an update is available, it downloads and applies the updates and then start the application.
It's the default strategy and as I mentioned above, it's the only available option for .NET 3.1 and above.
Main use-case for this scenario is high-bandwidth networks and also cases which you want to make the update mandatory.
Manual update - Provide a user interface for updates
In this strategy, developer writes code using the ApplicationDeployment class to check for updates; For example checking for update based on when users clicks on a menu item or button; or based on a custom user-defined schedule.
The main usage scenario for this strategy is when you want to have different strategies for different users, or custom scheduled updates for different users, or to have a manual check for update button/menu.
To learn more, take a look at the following doc articles:
Choose a ClickOnce update strategy
How ClickOnce performs application updates
How to: Check for application updates programmatically using the ClickOnce deployment API
I have recently upgraded my website to the dot net nuke version- 9.4.1 but here getting performance issue, the website runs slow. I have searched for this and applied the performance configuration inside the server setting and also did the cache configuration at the page level.
I have minified the files(Js and CSS) and have updated the setting value inside the host setting table.
Thanks a lot in advance.
Check the DNN Scheduler to see if there are any active jobs that are taking longer than they should. For example, if the Site Crawler scheduler is constantly running then you should check the files in the Portals folders to make sure all of the files located in the Portals folder should actually be there. The crawler is rebuilding the index and if you have a lot of files it could take hours to complete. If the files should be there, disable the crawler scheduler and then run during your slowest time of the day (1:00 AM?). I ran into this problem on a server that had hundreds of thousands of documents in the portals folder. Ended up solving it by running the crawler between 1:00 AM and 5:00 AM for a few days until it indexed all of the files. Once the files are indexed it will only have to index changed and new files; so it should just be a burden the first time it runs.
Another possible cause are exceptions. If your site is throwing a large amount of exceptions it will slow down your site. The handling of the exceptions and then the logging of them (to the DNN EventLog table in the database and the Log4Net files) can be brutal if your site is constantly throwing exceptions. If your site is also running in DEBUG mode the performance hit is multiplied by at least 30 times due to .Net collection all of the additional information about the exception while running in debug mode. That will be brutal to your sites performance.
Check the server logs to see how often IIS is recycling the application pool for your DNN site. If it's occurring often then that is also a sign of a large amount of exceptions being thrown if you are using the default IIS application pool settings. By default, IIS will recycle your application pool if too many exceptions are thrown within a short period of time. If you also have the option set to bring up a new instance of your site and run it side by side before IIS terminates the existing instance while your site is throwing exceptions that can cause a bottleneck and will cripple performance. For this situation, I usually disable IIS from recycling the application pool if too many exceptions are thrown within a short period of time. That may not be the best option for you but if you are on top of the exceptions being thrown on the site then you can disable that and let IIS run instances side by side after an app recycle (this is nice to have when you recycle during active periods so that all existing traffic completes with the old instance and all new traffic is sent to the new instance. Once all traffic is hitting the new instance of your site IIS will terminate the older instance.)
If none of the above help, run SQL Profiler on your database to see if there is any extreme database activities going on. Also check for any db locks.
There are a lot of possible causes that can slow down DNN. The best way to find out what is going on is to run a profiler on the server (RedGate Ants profiler or Telerik (Progress) Just Trace).
We have an net 4.0 winforms application that we publish with clickonce to the client pc's. The installation is about 80 MB. The application is offline available and the update occurs in the startup of the app using
ApplicationDeployment.CurrentDeployment.Update
Each time we do an update of the application everything works fine and each client gets udpated. However the application cache keeps growing in size... We noticed that more then two versions are kept in the LocalAppData folder. The size of the clickonce installation folder is more then 1GB.
ClearOnlineAppCache works only for online applications and we don't find any information to clean the LocalAppData for offline application.
Is there any way to manage previous versions of our application in the LocalAppData folder from our client pc's?
Update:
We removed our custom update code and used the update mechanism of the Clickonce framework. Now old versions are removed properly and only two versions are kept in LocalAppData. I have still no idea why all versions are kept when we update through the custom update code.
I've seen this issue before, but I clarified with the ClickOnce lead at Microsoft before answering.
It keeps two versions of the deployment plus there are extra folders for each assembly. When processing an update, ClickOnce figures out which files have changed by comparing against the assembly it has already cached, and it only downloads the ones that have changed. The deployment folders have hard links to the assemblies in the separate folders. So you might see additional files, but it's not actually the file, it's a link to the files in the assembly-only folders. Explorer will show it as a file, but it's not. So unless you're running out of disk space and are just concerned about the folder size, be aware that the information reported by Windows Explorer may not be accurate.
There is an answer to this problem here
I wrote a function to clean old ClickOnce versions in the client side.
In my machine I've freed 6Gb of space. I don't want to even know the total space used by old versions org wide...
We have a wpf application, which we have deployed using Microsoft's Click Once approach...manifest and application files are available in a web server.
If the application is already running on a client machine...and if I update the manifest and application files(in web server)...how do we notify the user about the changes ?
Is there anyway that we can display some kind of text to the user...that application has modified ..and he has to get latest ?
Any help will be appreciated. Thanks
ClickOnce does not provide you with an out-of-box means of alerting the end-users to an update.
In the company I worked at, it was good enough to walk around the end-users desks and making sure they weren't using the application before I updated it. Obviously, this doesn't scale too well.
If I had to implement a solution for this, I would include a message broadcast system that made sure the users were notified BEFORE the update was deployed.
If this was a client-server system, and updates to the server means that any out-of-date clients can't communicate with the server, then the end-users risk losing their work.
I am interesting in hearing if others have addressed release management for Silverlight applications.
I have a business application that is to be released shortly andam concerned about how to "release" updates to this application. Typically this application's users will leave the application open all day (and potentially all night) without reloading it.
What if there is is need to release an change that includes an web service interface change? How can this be deployed w/o causing errors on the client side?
We have grown so used to deploying ASP.Net apps by just dropping the latest code on the server. My only idea currently involves a client version number and a periodic timer on to check for updates.
I would love to know what others have done before implementing this.
Thanks,
Mike
I just answered a question on how to make sure that .xap files are not cached by the browser, which might be of some help:
Prevent Silverlight xap from being cached by proxy server
But that's no use if the users never reload your application. In my own application this is not a problem since users will be automatically thrown out whenever we deploy an update to the web service. But I like your idea with the timer, I would go with that.
Stating the obvious but don't do anything to annoy your users. E.g. could they spend twenty minutes entering data, nip off to the coffee machine and return to click Submit to find the timer has expired, noticed an update and their work is lost due to a forced restart?
If so, and I admit this hasn't had a lot of thought, if e.g. you have to make changes to the web service that break the current release, could you have the new web service version side-by-side such that users don't get thrown out until the timer has expired and the unit of work is complete? Or is this also stating the obvious?
For server code, i.e. endpoints just do as per normal. for the xap's I think you have a few options depending upon how you handle communications. You could have request contain a version number and if the server has been updated then force some code to reload the client, bit lame, messy but do-able. Perhaps a cleaner solution would be to control the clients session, which presumably is part and parcel with requests to the backedn. When you deploy a new version you could invalidate the client session, perhaps forcing a page refresh with custom logic. If your protocol is push base you could send a command to the client to do what ever you want, for many systems that are on all day its likely that this infrastructure would exist (if u've build it nicely :)). For instance our service layer is abstracted away from the repositories models and view models, in our case we'd could send a logout or perhaps a specific command to kick in some custom logic on the client informing the application is being updated and to refresh your browser when done. Our shell is light weight so our modules (basically other xap's) can be updated in time for the refresh.
I would recommend you to use a solution like mentioned in App Arch Guide:
The Guide Chapter I mean see Deployment considerations.
Divide the application into logical
modules that can be cached
separately, and that can be replaced
easily without requiring the user to
download the entire application
again.
Version your components.
Have you considered keeping a WCF polling duplex channel going that alerts the app when it needs to reload? In addition, you can have your WCF calls direct to a virtual directory that contains 'interfaced' calls. For example:
Silverlight app hosted at "x.x.x.x\Default.aspx"
Silverlight talks to WCF at "x.x.x.x\Version2\DataPortal.svc"
DataPortal.svc talks to a GAC (or otherwise base) assembly that can identify what version can handle what calls.
This way, if you upgrade to "x.x.x.x\Version3\DataPortal.svc", you can still make calls against Version2, assuming those calls have code to convert them to a Version3 concept.
This helps in cases where your line of business app has dynamic xap downloading ('main', 'customer', 'inventory', etc.) and you want to release them independently.