Web Application Publishing in VS2012 used to be quite fast for me, but for the last week or so the UI exhibits very long pauses:
When I first right-click the project and select Publish, the publish UI takes about 30 seconds to come up (VS is unreactive during that time).
If I select a New Package, the associated UI takes up to 60 seconds to appear.
The actual publishing is quite fast. It's just the VS2012 UI that is unresponsive.
This is similar to Publish very slow in VS 2012. However, that ticket is about publishing itself being very slow rather than about the publishing UI.
Given that the UI was fast and has become slow, it it possible that some setting or configuration is causing the slowness? Any idea how to make it fast again?
I had this problem when I had multiple publish profiles in my solution configured to publish to servers that were no longer available or were offline. I was using the File System publish method.
I believe that Visual Studio tries to connect to the servers and the UI hangs until the connections time out.
Removing the profiles that were no longer in use resolved the slowness issue for me. Remove them by selecting Manage Profiles... in the Publish wizard, and then use the Remove button to delete them.
Related
Debugging an ASP.NET MVC application on the Azure Service Fabric platform takes a long time. How do I speed it up?
If you are talking about cloud cluster debugging then that is going to be a bit slow process if you are attaching debugger to that cluster, in which case you should be relying more on your application logs to find a problem because you should try to replicate the problem in your local cluster first and debugging that locally will be much easier.
Now if you are trying to debug on local cluster then couple of things are important to speed up things.
Set your cluster to run in 1 node configuration rather than 5 node
configuration.
Set your "Application Debug Mode" to "Refresh Application". To do
this, right click on the fabric project in your solution and click
on properties. you will see a window where you can set project
properties, here you will see this option of setting "Application
Debug Mode".
once you have done this then you can hit F5 and the debugging will be a lot faster. Also remember that you don't need to publish your application every time you make code changes, all you need is build and cluster will pick up changes and you can debug any time. one last thing to remember is that if you make any changes to your settings.xml or manifest.xml files you will need to publish in order for these settings to be picked up by the application.
Hope that helps.
Publishing package in my local system is taking much longer time than expected. It is taking around 15-20 minutes to publish, and sometimes it is throwing an error, UNABLE TO READ DATA like this.
I also tried even after Restart Application from Apply Updates screen but still same issue. How I can solve this?
You might want to try to disable web site building.
In Visual Studio, go to web site property pages and deactivate the following 2 configurations:
Uncheck Build Web site as part of the solution
Before run startup page - no build.
See http://asiablog.acumatica.com/2016/09/make-compilation-of-extension-library.html
Windows 8.1 Pro, Visual Studio 2012 Update 4, MVC4 Umbraco site using SQL Azure (have also tried with a local SQL 2008 R2 db). Running through IIS.
Site runs perfectly while not debugging. However, when debugging the site is extremely slow. The default page takes nearly a minute and a half to execute. Subsequent requests take the same amount of time.
I thought this may be environmental (Surface Pro 3, i5), so went over to a MacBook Pro (i7)...issue still occurs on that PC as well.
At my wits end trying to figure out what could be causing it.
Thank you so much!
There are several thing that could be happening here. Using an Azure SQL db would cause slower initial loading of pages (compared to a local db) because of the data transfer time. However, subsequent page loads should be quick because everything would be loaded into the site cache.
If subsequent page loads are still extremely slow then this could be because the XML cache isn't being generated. Check that the settings are correct in the web.config in debug configuration.
Also, check where you are writing your debug logging to. Umbraco will write log messages to a log file in App_Data/Logs/ and also separate logs to the database. Using a remote database would make these writes slower.
Without knowing what else is happening in your project it's difficult to know what other factors may be playing a part. But you need to step through the application in debug mode in VS and you can check the event viewer for swallowed errors like timeouts. Finally, you can use a profiler to pin point exactly where your issue is.
I have a ps1 script that deploys all of my webparts. I started noticing an error (Error 503 service unavailable) after running Update-SPSolution. What is happening is that when I upgrade all my webparts, the application pools for all SharePoint web applications stop. It also takes about 12 minutes per web part to deploy (which seems like forever - it looks like it may be running them all in parallel). Could someone shed some light as to what the best way is to upgrade web parts using Update-SPSolution. Optimally, I would like my script to stop while it fully completes an upgrade on a particular web part, and then move on the next one when it is finished. Thoughts?
You might get better performance on the upgrade if you set ResetWebServer to false in each solution manifest. Naturally, you would be compelled to reset the web server(s) after all the upgrades, but at least you would only be required to do it once.
You might also consider combining web parts into fewer projects/solutions. This can be challenging, as your web parts' assembly-qualified names are part of the .webpart file, and therefore part of any web part that is still in use.
If your solutions are Farm solutions, SharePoint will restart the application pool in order to reload your assemblies.
The only way to completely remove this restart is to use Sandbox solution. That's not always possible, but depending on your type of customization this may be an answer.
Another solution is to only have one solution containing all your webparts. You'll still need an application pool restart, but it should take less than a minute.
12min is really a lot!
Edit:
To merge your WSPs, you'll have to merge your Visual Studio projects into one. It's also possible to do it by hand, but it's not a good choice in the long term.
Deploying to sharepoint using the object model or STSADM commands sometimes results in one or more packages being in the "error" state in the web control, a redeploy instantly fixes this, usually, even stranger, if i create two apps one which adds and one which deploys then i get no problems, but putting a delay between a single program does not have a similar effect.
If i run the deploy twice for programs which did not deploy successfully it works fine, as long as I do not try to do it programatically in which case it makes no difference.
It is different files and sometimes is none.
I do use stsadm -execadmsvcjobs between add and deploy and even between two of the deploy bunches.
(i'm deploying around 10 wsp files programatically)
Does anyone have any ideas on why this happens? or how to solve it, as when i get to implementations it causes problems.
The problem lies in the fact that sharepoint will perform app pool recycles and / or full iisresets, as well restarts of the SharePoint Timer Service (altough not completely sure about that though). When you try to actually deploy the just installed package sharepoint is still busy getting up and running again, the timer job created to install / deploy is basically waiting for the central admin app pool to be fully running again.
The same thing happens (somewhat reproducably) while retracting a solution. Hit F5 a lot of times on the solution management page while the retract process is underway and if you refreshed fast enough it will hang and display "error" in red.
My solution was to create a WebRequest to at least the central admin (or just do a SPSite = new SPSite("centraladminurl")) in your deployment app or in powershell. Do this after every deploy action as well.
This SHOULD fix the timing issue (basically a kind of "race condition").