Performance issue while publishing package - acumatica

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

Related

Azure App Services Web App not registering update

I have a Azure App Service app that I'm trying to get deployed.
Today I ran into an issue where .NET informed me (via the yellow screen of death when I browse to the URL of my app) that I had a missing DLL (for the purposes of this question I don't think it really matters).
I used FileZilla to publish my changes in an attempt to do a manual deployment first and then work my way to automate it.
After so many attempts to fix it I later realized that the error message never changed. I did something more severe and renamed my bin folder into something completely different and the exact same error message would appear.
I've stopped the service, restarted it, and as mentioned, renamed folders, etc. and still the exact same error message persisted.
I also decided to open up the Azure Portal Console for my App Service app to browse a bit and to my amazement, nothing seemed to have reflected at all. The FTP shows one thing and the Console shows another.
Would anyone have any idea as to why this is happening?
I eventually got it to work and I will share what I tried.
I deleted the web app and created it again (I found this to be important the first time around). This was quite time consuming and did help but it wasn't long before the same problem happened again.
Then I finally found a solution that seems to give me consistent results:
I kept on editing the Web.config which seems to force a recompile and clear some sort of cache. So each time the web app stopped updating, I would make a slight change in the Web.config, upload it via FTP and the app finally updates.
If anyone has any more details on this, it would be greatly appreciated.

Azure web deploy/publish keeps getting stuck

every time I try to publish my web app to azure it gets stuck, how can I determine what the problem is? logs etc, I cant see anything but the output but thats not enough to diagnose the issue.
So the way I got around this issue was to set the visual studio parallel build settings to 1.
this would force visual studio to build each individual project one after the other, and this way you would be able to diagnose if there is something going wrong during the build stage or not.
fortunately for me nothing was wrong with the build stage and my project got published fine.
Same thing I have faced many times, process stuck while publishing Web app.This is related to network speed. May be at that time your network speed is slow. Please make sure while your will going to publish your network speed should be high.
This is work for me.

How to take web app offline while publishing?

Very often, when I hit Publish in VS13, I get the site to compile but when uploading I get the error saying that a file is busy.
Updating file (MyAzureSite\PrecompiledApp.config).
C:...\v12.0\Web\Microsoft.Web.Publishing.targets(4255,5):
Error ERROR_FILE_IN_USE: Web deployment task failed.
(The file 'PrecompiledApp.config' is in use.
Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.)
When I follow the link provided, it's suggested that I should go for enabling the appOffline rule. "Sure!", I think to myself. But how?! I've googled it, only to get a bunch of hits on the file that's supposed to replace the site while publishing. However, I get no info on how to get rid of my little problem.
I went the easy way and downloaded a publishing profile from my Azure web site and now I'm using it (you know, ALT+B+H).
Right now I resolve the problem by going to the portal for Azure and manually take the site off-line. Then I can publish and after that I take the site on-line. Highly impractical and painfully tedious.
What is causing this and how do I kill it?
You actually configure it in the publishing profile (.pubxml). Just add the element to the PropertyGroup like this:
<PropertyGroup>
<EnableMSDeployAppOffline>true</EnableMSDeployAppOffline>
...
</PropertyGroup>
More in this MSDN document
The Azure App Service Deployment Task has a checkbox for this (from version 2.0 onwards), under Additional Deployment Options: Take App Offline. Check that and you should be good to go.
Take Application Offline: Select the option to take the AzureRM Web App offline by placing an app_offline.htm file in the root directory of the Web App before the sync operation begins. The file will be removed after the sync operation completes successfully.
Screenshot:

Publish Web Application's UI Extremely Slow

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.

deploying to sharepoint using the object model doesn't work reliably

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").

Resources