I have a large (to me) ASP.NET (4.5 Framework) application that was working fine when developed in and published from VS2012.
I've since upgraded from VS2012 to VS2013 and I opened the solution without issue and it runs fine locally (on IIS Express).
I don't know if this is a red-herring, but I used NuGet to update the AJAX Control Toolkit for the first time (and its dependencies) and it appears to have worked.
When I publish (file system publish) the site to our web server (IIS 8 in Windows Server 2012) it loads fine UNTIL I change <compilation defaultLanguage="vb" debug="true" targetFramework="4.5"> to debug="false".
When I do, the site runs like a pig, sometimes pages don't even load, and its IIS Worker Process spikes the CPU and holds, growing in % until it consumes essentially all the CPU.
EDIT: this happens on the server and on my PC (IIS Express)
This test site's AppPool is running with the identical settings as our live site's AppPool. Of note:
Enable 32-bit applications: True
.NET Framework Version: v4.0
Managed Pipeline Mode: Integrated
I expect you'll need more information, but I honestly don't know where to begin and I don't want to overwhelm with unnecessary detail.
Thank you in advance
EDIT: I REALLY should have mentioned this:
the site is precompiled during publish in Release mode. I've never had to change to debug=false in my development environment prior to publish in the past.
I get this for each of the Projects in my solution:
(0,0): warning : The following assembly has dependencies on a version of the .NET Framework that is higher than the target and might not load correctly during runtime causing a failure: [projectname], Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. The dependencies are: Microsoft.VisualBasic, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. You should either ensure that the dependent assembly is correct for the target framework, or ensure that the target framework you are addressing is that of the dependent assembly.
EDIT: it appears this solution I inherited is a web SITE not APP. I don't know if that comes into play.
I ended having to call Microsoft on this. They used ProdDump and LogMan to analyze what was happening. In less than 24hrs came back to me and said:
"Thread 19 seems to be pretty badly bogging down the CPU. The top of
the stack indicates that AjaxMin is trying to do FindEntry on a
Dictionary object and this was triggered from AjaxControlToolKit,
specifically there appears to be something “CombineScripts” attribute
defined on either the Master page or in the design page of
OrderDetails.aspx. Basically this combines all the JS files and
minifies them.
A quick test would be to disable the logic of CombineScript from
AjaxControlToolKit and see if that improves performance"
Google told me CombineScripts was an attribute of ToolkitScriptManager and since AJAX was always a suspect (for no real good reason, just a hunch) I jumped on it.
Sure enough, changing my reference to the ToolkitScriptManager to include CombineScripts="false" completely fixed the problem!
<ajaxToolkit:ToolkitScriptManager ID="ToolkitScriptManager1" runat="server" CombineScripts="false" ScriptMode="Release" />
Related posts:
I'm not the only one: https://www.google.ca/#q=ToolkitScriptManager+combinescripts+problem
Two helpful posts:
http://forums.asp.net/t/1696523.aspx
http://ajaxcontroltoolkit.codeplex.com/workitem/27558
In the project project properties check for any reference to old version of Ajax control toolkit. If found any then remove the same and try again.
I some times gave same error when I use nuget. I think conflict is your web.config assembly reference. Please compare your dll reference and web.config reference.
Try to change .Net version for Application Pool to v4.0
Related
I've developed a site using the Umbraco 7 CMS system, all works great and I've been able to copy and deploy this to numerous other machines and severs without any issues.
However now that we have tried deploying this to the live server, we are unable to login to the backend Umbraco section. The error is as follows:
Received an error from the server
Server call failed for getting current user
Could not load file or assembly 'Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Access is denied.
Exception Details:
System.IO.FileLoadException: Could not load file or assembly 'Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Access is denied.
The only different here is that the live server is administered by a Plesk control panel. So the actual site within IIS were created using this. However we have full Remote Desktop access and have set all the required "full control" permissions. And have checked that we have the correct .NET versions installed. But with no luck.
Has anyone experienced this or have a fix, I've searched Google and can't find anything that works.
Thanks
I haven't run into this myself, but it sounds like the server where you are trying to run your live site does not have the Windows Identity Foundation installed. I'd try installing that on your production server. Alternatively, you could find Microsoft.IdentityModel.dll reference in your solution right click it, open its properties and set Copy Local to true. That will cause the referenced dll to actually be dumped into the bin on compile. If you then deploy those dlls from the bin, your live site should be able to find them. You might have to go through that a couple of times until you find all of the Windows Identity Foundation dlls you need to get to.
It sounds like WIF has been integrated into the .NET 4.5 framework. It is depreciated and you shouldn't use it unless you are developing with .NET 3.5 or 4. I wouldn't expect you to be having this problem on .NET 4.5. What version of .NET framework are you using?
See What is Windows Identity Foundation for more info on WIF
Was any of that helpful?
I'm trying to figure out what I'm doing wrong or not understanding. I have a solution with a web application and a few class libraries.
I edited the web app publish settings of the web project. It has "precompile this application before publishing" checked and I've selected "Only files needed to run this application".
I created a publish profile which just dumps it to a folder. From that folder I upload (using FTP) the DLLs to a staging site I have setup which is where I do final testing before deploying the app live. After uploading the DLLs and going to the staging site there's still an app startup delay, which seems just as slow. Isn't that supposed to be gone by precompiling?
Edit: Turning off allowing the site to be updatable fixes the problem. Allowing it to be updateable causes all of my ASPX pages and user controls to be compiled on first page view which is causing there to still be a delay even though the code behind is compiled. I've disabled batch compiling and turned on optimizeCompilations in the web.config and now it's fast:
<compilation batch="false" optimizeCompilations="true" />
Maybe you have left debug=True setting in config?
This will, among other things, disable batch compiling and caching (but caching should not affect your startup time).
See here and here for more details.
Which Framework version are you on? If you are on .Net 3.5 (specifically), you should consider using:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
It will approx half the cold-start time. But it is a known issue that when IIS do a cold-start on an application, there is an initial delay. This is not limited to you deploying the application, but also when your application pool recycles.
So far, the best option that I can think of is to write a scheduled-script to automatically spin-up (warm up) a site periodically (say every 1min?).
I managed to figure mine out. Previously my cold start was taking 18 minutes on my local dev machine (on staging it was less than 30s).
I finally noticed that a program was running high CPU during the cold restart.
The program was.. MsMpEng.exe - This is Microsoft Security Essentials including Microsoft Defender.
I uninstalled it and my site now loads on less than 30 seconds.
Obviously it was scanning each .dll being copied during the cold start, and blocking each additional .dll from being copied until it was finished scanning the previous one.
Cold start is now less than 30s.
In our case the precompiled app (that was previously updated in a blink of an eye) started behaving slowly after we added SignalR.
Now, I profiled the process using this open source tool (disclaimer, I'm a contributor to the project, originally written by the Stackoverflow team), and I saw this among the longest call stacks:
//...skipped
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start
Microsoft.Owin.Host.SystemWeb.OwinCallContext.AcceptCallback
//...skipped
Thanks, Obama.
Wtf, Microsoft?
Say hello to Owin dependency.
Situation:
We created an assembly with our own ASP.NET control.
That control registers some resources (images, JavaScript files, etc);
There is a web-application which uses our control.
The control is loaded well and get access to internal resources. In result HTML code all calls to resources look like "/WebResource.axd?d=...".
So far, so good.
We have two computers: first - Win7 32 used for development, second Win7 64 - for testing.
The problem:
The assembly generated on Dev machine works well on it but give 404 error for all requests to WebResource.axd when running on Testing computer.
If we just copy the sources to Testing computer and build our assembly there - it works well on both computers.
We use .NET 4.0. All latest updates are installed on both computers. Web application which uses our control runs right from VS 2010 (under ASP.NET Development Server).
Any suggestion?
We've found the problem.
Our testing computer had wrong date/time set (10 days before the real date). So our assembly (built on development system) was considered by it as a "DLL from the future".
And it seems ASP.NET can stand the assembly "from future" but it does not like "future" resources placed into that assembly.
Once we corrected date setting on the testing system - everything started to work well.
Hope this case will help somebody else.
The assembly with your asp.net control may not be included in your web application deployment.
Look for the reference to your assembly in the web application, right click it and select properties.
Look for the copy local box, and set it to true.
recompile the application and redeploy it to the other machine.
I'm having some trouble setting the ExecutionTimeout element in my applications web.config.
My page is making a lengthy webservice call and times out after 110 seconds. (the default I believe). I set the value to 220, and make sure the compilation debug=false.
Does the compilation setting refer to when IIS/ASP.net compiles the ASPX pages when a client requests them, or does it refer to the visual studio compile process there the assemblies are created.
Would using an assembly built using debug in visual studio still allow the above settings to work?
IIS does not compile aspx pages when people request them. If you have a 'web application project' in VS, you compile all of your code behinds and other class files before you deploy. If you have a 'web site project' in VS, then the web server compiles your app on first request only. After either one of these happen, the application is not compiled again until you make a change.
With that information in mind above, this is when the compilation debug = true | false comes into play. Having debug = true, you get some pretty detailed information back on errors and other events but it can make your app run slower as debug symbols are inserted into the .dll and overall, it is not optimized for performance. By setting debug = false, you don't get quite the same level of error reporting, but you do get your performance gains back.
If you build in VS, it will build according to the settings in the web.config unless it is an external .dll/class project that you are including. If that is the case, the web.config settings mean nothing to that .dll and will run regardless of what combination of debug = false|true you have on those two projects.
Compilation tag is used to add referenced libraries for compilation by IIS or Visual Studio and to specify debug and batch compilation modes.
Speaking of debug attribute, here's good article with all the details in Milan Negovan blog.
And about compilation itself.
There are 3 modes of compilation. They are fully described in MSDN Overview.
By default web application uses updateable precompilation: all .cs files are compiled into one assembly, but all pages, controls and master pages are compiled on demand into new derived class.
Web Site project uses in-place compilation by default.
And non-updateable full precompilation must be specified explicitly. And here when compilation tag comes in. If batch="true" then all pages in application will be compiled upon first request to any page. This moves us to yet another story about big applications :)
Note that there are some other specifics in compilation model, look into ASP.NET Precompilation Overview if you really need this.
IIS compiles ASPX pages (and ASCX UserControls, ASHX, ASMX, ...) the first time they are requested. It also dynamically compiles:
Code in the App_Code folder
Code in code-beside pages for a website project
The compilation element in web.config refers to this compilation.
If you are using a Web Application Project in Visual Studio, your ASPX pages will have a code-behind file. This is compiled into a DLL when the project is built in Visual Studio, and won't be affected by the web.config compilation element.
We have a web application project (not a web site), until the day we have added batch="false" to web.config web development server was compiling all the web application instead of the page that was requested.
<compilation debug="true" batch="false">
<assemblies>
...
</assemblies>
</compilation>
This make us faster. But I don't know what changed (I have inspected both foo.cproj and web.config from repository, comparing older versions but find nothing can cause this slowness).
I looked at %temp%/Temporary ASP.NET Files; after I compile my web app (not recompile, shift + f6), then I request a page and I see that web server deletes all of already compiled files from %temp%/Temporary ASP.NET Files and recreates. I don't know if this is normal but it seemed to me a full recompilation of all web app, which is very slow. (I looked via process explorer to wevdev.wevserver.exe it calls csc.exe several times)
How can I can make compilation faster? Thanks...
There is an option for ASP.NET Development Server named 'Enable Edit and Continue' that is available with the 32-bit version of NET CLR. Turn that off in Visual Studio.
Also, try changing the build for 'Any CPU' in a build for 'x86'. That should make compilation faster.
I believe this is a part of using the Web Application Project. Any time you build your application, the entire site is recompiled. You should see that unlike a 'Web Site', the web application all compiles down to a single dll (plus references).
Another thing you have to watch out for is any time you delete a file/folder under your root web app folder it will also force a recompile, which can be a real pain in the butt for temporary files.
On the plus side once you get over the first compile, there will be no additional waiting for compile times on unvisited pages.