I'd like to take advantage of the new multi-core jitting feature in .net 4.5.
My web.config is set to targetFramework="4.5"
The application pool framework in IIS is set to v4.0 (from what I understand, that is correct)
My processor is an i7 with 4 cores (or 8 with hyperthreading) - http://ark.intel.com/products/52214/
But it doesn't seem to have decreased the JIT compilation time (based on performance profiling), and I can see no evidence of any *.prof files being created in ASP.NET Temporary Files.
How can I track down the reason for this?
Background JIT compilation might not work in some specific scenarios. You can debug it using PerfView http://www.microsoft.com/en-us/download/details.aspx?id=28567
From the documentation, here are the main reasons:
When modules are loaded, a module constructor could be called, which could have side effects (even this is very rare). Thus if background JITTing would cause a module to be loaded earlier than it otherwise would be, it could expose (rare) bugs. Because background JIT had a very high compatibility bar, it protects against this by taging each method with the EXACT modules that were loaded at the time of JIT compilation, and only allows them to be background JIT compiled after all those EXACT modules were also loaded in the current run. Thus if you have a scenario (say a menu opening), where sometimes more or fewer modules are loaded (because previous user actions caused different modules to load), then background JIT may not work well.
If you have attached a callback to the System.Assembly.ModuleResolve event, it is possible (although extremely unlikely and very bad design) that background JITing could have side effects if the ModuleResolve callback returned different answers on the second run than it did on the first run. Because of this background JIT compilation is suspended the first time an ModuleResolve callback in invoked.
Because any module lookup that fails, WILL call the ModuleResolve event before it finally fails, this means that any probing for modules which fail will also inhibit background JIT compilation.
I would suggest to check if the assembly(ies) which is failing the background JIT is exposing one of these issues. To do so, start a new Collection before your application is starting, and Stop it when it's done. Don't forget to check the Background JIT option in the Advanced section.
In the JITStats section you should get something like this:
Total Number of JIT compiled methods : 10,673
Total MSec JIT compiling : 9,873
This process uses Background JIT compilation (System.Runtime.ProfileOptimize)
WARNING: Background JIT aborted at 11,847.909 Msec
The last assembly before the abort was 'NHibernate.XmlSerializers' loaded unsuccessfully at 11,793.741
Methods Background JITTed : 0
Percent # Methods Background JITTed : 0.0%
Update
Related to scenario 3, in the case of ASP.NET, ASP.NET itself handles the ModuleResolve event, so any module that fails to load will cause MCJ to abort in an ASP.NET app.
Related
I have a VS 2022 solution with a WPF client and ASP.NET backend and when I put breakpoints in the backend web services they have the yellow tag with a message:
Breakpoint will not currently be hit. No symbols have been loaded for
this document.
I run the solution with the WPF project set as the start project, but, if I test this by setting the web project as the start project - the symbols will load, but of-course this is useless as the wpf app is not running.
A little history: This solution was running on my old dev PC (same version of everything) and all worked as expected, but when loading all solutions onto my new PC, this problem started up. I have googled this and found a ton of posts about it and have tried everything, but nothing has worked yet.
I can run the solution and attach to the process and then debug, but since I will be debugging 100s and 100s of times, those extra steps are a real pain and I have been able to debug asp.net projects from wpf for many years up to now.
Can someone please recommend some additional steps I can take to solve this problem?
FYI, I Have been through everything from this link:
How do I remedy "The breakpoint will not currently be hit. No symbols have been loaded for this document." warning?
Thanks.
Common method:
In VS, go to Tools --> Options --> Debugging --> General, and then cancel the checks in front of [Enable "Only My Code"] and [Require source files to exactly match the original version].
But this method you may have tried.
Ultimate method:
When the breakpoints clicked by the mouse are invalid, you can perform the following operations in vs:
Debug --> delete all breakpoints
Debug --> New Breakpoint --> Function Breakpoint, and then enter the name of the function to add a breakpoint
Qt 5.8 was supposed to come with the optional use ahead of time qtquick compiler, instead it arrived with a sort-of-a-jit-compiler, a feature that's enabled by default and caches compiled QML files on disk in order to improve startup performance and reduce memory usage.
The feature however arrives with serious bugs which greatly diminish, or in my case even completely negate its benefits, as I didn't have a problem with startup times to begin with, and testing didn't reveal any memory usage improvements whatsoever.
So what I would like to do is opt out of that feature in my project, but I don't seem to find how to do that. Going back to Qt 5.7.1 is not an option since my project relies on other new features, introduced with 5.8.
Add QML_DISABLE_DISK_CACHE (set to 1) to your environment variables. You should be able to do it inside your application via qputenv -- put it somewhere in main before loading QML content.
Credit to peppe for informing us of the environment variable, but qputenv()only takes a QByteArray as the value parameter, so 1 won't work.
The two options that work:
qputenv("QML_DISABLE_DISK_CACHE", "1"); // or
qputenv("QML_DISABLE_DISK_CACHE", "true");
This successful disables the cache and prevents the associated bugs from manifesting.
Visual Studio 2008/2010/ASP.NET:
How to speed up the delay after rebuilding the solution?
I like to detach my debugger while testing my changes or debugging issues that can be pinpointed by a simple strack trace.
After I fix a bug, I build the solution and then refresh the page.
There's that initial lag time that occurs after the rebuild before the web page displays.
After that, it's as fast as it should be. I heard that the application is loading up all the new DLLs during this time.
Is there any way to reduce the amount of this lag?
You can set the optimizeCompilations to true, and batch to false
<compilation batch="false" optimizeCompilations="true" ... >
batch=false says to asp.net to build if necessary only the page that you call. We set batch to true, only on release live site to so the asp.net compiles many pages at ones, and you may have a big delay but only ones...
The optimizeCompilations=true says that each page is not check for libraries updates each time its runs. This have a minor issue - if you change a global static function for example that is called from 4 pages, this 4 pages did not know that this function change, so you need to just open them and saved them, to force compiler to re-compile them. Or else they throw error because they did not check if something change - you must know that and updates them to force the re-compile.
reference : CompilationSection Class
I'm having difficulty finding why exactly the following error is happening. I'll outline the puzzling aspects below the error description.
[A]ASP.common_resultmessagepanel_ascx cannot be cast to[B]ASP.common_resultmessagepanel_ascx.
Type A originates from 'App_Web_resultmessagepanel.ascx.38131f0b.2c4hpv_z, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
in the context 'Default' at location
'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\MyWebApp\dc3e0df6\ba1606c8\App_Web_resultmessagepanel.ascx.38131f0b.2c4hpv_z.dll'.
Type B originates from 'App_Web_wz3shqfq, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
in the context 'Default' at location
'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\MyWebApp\dc3e0df6\ba1606c8\App_Web_wz3shqfq.dll'.
The class referenced in the error is a web user control inheriting from System.Web.UI.UserControl and implementing System.Web.UI.ITextControl. The control is registered and used on a master page. None of the parent master pages or implementing pages have instances of the control. The class and the markup page are both in the web application project. The exception does not happen as a direct result of the application code, it happens during internal .NET Framework code execution. The project is a web application, not a web site. The web application is compiled into a single binary, with culture specific resources compiled into one binary per culture.
The context reported for each type in the exception is the same, but I was able to verify that when the exception occurs there are in fact 2 separate class definitions in the Temporary ASP.NET Files folder for the application.
The user control has always existed and was used in the application, but the exception first started happening after the user control was added to a master page.
The exception does not happen consistently. Once the temporary files get created, the exception will happen every time the page is requested. If anything causes the temporary files to be cleared or recreated, it is random as to whether the duplicate temporary class definitions/DLLs will be created again. This could be a web.config change, recycling the app pool, sometimes even just an updated/rebuilt web application binary.
The last bit of the stack trace:
ASP.Default.__BuildControl__control35(Control ctrl) in C:\Projects\ABC.Web\App_Themes\Default\CheckBox.skin:3
System.Web.UI.ControlSkin.ApplySkin(Control control) +12
System.Web.UI.PageTheme.ApplyControlSkin(Control control) +119
System.Web.UI.Control.ApplyStyleSheetSkin(Page page) +61
ASP.masterpages_mymaster_master.__BuildControlpnlResults() in C:\Projects\ABC.Web\MasterPages\MyMaster.master:10
ASP.masterpages_mymaster_master.__BuildControl__control2(Control __ctrl) in C:\Projects\ABC.Web\MasterPages\MyMaster.master:9
System.Web.UI.CompiledTemplateBuilder.InstantiateIn(Control container) +12
System.Web.UI.MasterPage.InstantiateInContentPlaceHolder(Control contentPlaceHolder, ITemplate template) +87
The supposed offending source (the only line in the skin file C:\Projects\ABC.Web\App_Themes\Default\CheckBox.skin):
<asp:CheckBox runat="server" SkinID="FormInput" CssClass="FormLabel FormInputCheckBox" />
At this point I don't know if this issue is caused by the solution, its configuration, IIS and the app pool, or something related to the actual temp file directory itself where maybe old files are not getting cleared out. I've verified that the temp folder is not being indexed by the OS.
I'm worried that in a production environment, the app pool will recycle or some configuration setting will change and cause those temp files to be recreated with the duplicate class definition, and thus the error. We can't have someone testing the application every time the app pool recycles and deleting temp files if the error occurs until the application loads correctly. So I need to find out what is causing the duplication, but at this point I don't really know where else to investigate.
Any ideas?
I've removed the user control from the master page, and put it directly into each of the pages that required it and were implementing the master page.
So far the exception hasn't happened again. I'm going to give it another couple days of test time to see if it crops up again.
I still want to know why the exception was happening at all. Anyone with in-depth knowledge of how IIS runs .net web apps, or how the temp files are created?
New theory!
While it is a web project with a compiled binary, the IIS instance I am running for development is pointed to the project folder. So the source code files are actually in the web path. I think IIS might be compiling the source code files into separate binaries, especially if the app pool recycles. Thus accounting for the duplicated temp files that are being created and the error.
Other developers were experiencing the errors while running the project from within visual studio. I don't know how this would account for those cases, but I wouldn't rule it out as being the cause either.
I'm not sure what's happening in your case, but I had this happen to me under the following circumstances:
Website project type, not Web Application.
/Controls folder containing many ascx usercontrols.
/Client/Controls folder containing other ascx usercontrols, some of which register and reference /Controls usercontrols.
/Controls/BadControl.ascx using /Client/Controls/DupedControl.ascx as a child control.
The compiler runs into a circular dependency as it tries to compile each folder into a separate assembly.
/Controls/BadControl.ascx needs /Client/Controls to be compiled first.
/Client/Controls needs /Controls to be compiled first.
So the compiler punts and compiles DupedControl.ascx into its own separate assembly first. Then /Controls, then /Client/Controls in which DupedControl still gets included.
At this point there are two distinct Types for DupedControl in two separate assemblies. DupedControl.ascx (markup) points to the correct Type -- let's call it TypeA, in the folder's assembly -- while BadControl's reference points to the dupe TypeB in the small extra assembly.
When a page using BadControl executes, DupedControl TypeA gets instantiated via the markup, but BadControl tries to cram it into a TypeB variable, resulting in the error you described.
The solution is to move ascx files around to get rid of the circular reference. I can't remember for certain, but I think maybe the "single page assemblies" and "fixed naming" options might also resolve it.
All that said, Web Application projects compile to a single assembly, so I didn't think this kind of circular folder reference would be possible. Perhaps the problem lies elsewhere.
After a year and a half of seeing this error intermittently pop up for developers in our team, I've finally been able to gather enough data to draw some conclusions.
The key elements in the scenario causing the error are source code files in the web path, and low available memory on the dev machine that is running the application. The low memory condition causes the application pool to recycle or release memory more frequently than it would in a dedicated web hosting environment. When the memory containing the compiled web app code is released, and then a page is requested, the compiled code is reloaded into app pool memory. Since source code files are in the web path, .NET recompiles from the source code files and reloads into memory.
This situation does not happen in a dedicated hosting environment where only the compiled DLL and static files are deployed, and has never happened in our production environment. Additionally memory usage in a dedicated environment should ideally never reach a point where frequent app pool recycling is necessary.
The Visual Studio solution consists of several projects, and developers typically have multiple VS instances, a SQL Server Mgmt instance, and other sundry processes running which cause low available memory on dev machines. The lower the available memory, the more frequently and reliably the error will happen.
To clear the error state, an application pool flush / iisreset will clear out memory, and then a rebuild will usually fix the problem. If available memory is still low, the problem may persist until more memory is available in which to run the application. Simply closing down some applications or otherwise releasing memory back to the OS should do the trick.
I'm still not sure why running the app through Visual Studio's web server instead of IIS has same issue, but if it handles memory the same way IIS does, it stands to reason that the behavior is the same.
SOLVED!
I had similar problem, caused from LoadControl() strange behaviour.. and solved not instantiating my control before.
strange but true..
MyUserControl myuc = new MyUserControl();
myuo = (MyUserControl)Page.LoadControl("~/UserControls/MyUserCOntrol.ascx");
doesnt work
MyUserControl myuc = (MyUserControl)Page.LoadControl("~/UserControls/MyUserCOntrol.ascx");
works
I belive we found a solution to this problem. We always tried fixing this by deleting the whole "Temporary ASP.NET Files" folder.
At some point this solution would no longer be good enough and the error kept popping up every 30 minutes or so. We found that deleting just the file responsible and then restarting the application pool of the application in question is a permenant fix (at least for us). So for you case you would delete the follwing file (bold) and then restart the applications application pool:
[A]ASP.common_resultmessagepanel_ascx cannot be cast to
[B]ASP.common_resultmessagepanel_ascx.
Type A originates from 'App_Web_resultmessagepanel.ascx.38131f0b.2c4hpv_z, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
in the context 'Default' at location
'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\MyWebApp\dc3e0df6\ba1606c8\App_Web_resultmessagepanel.ascx.38131f0b.2c4hpv_z.dll'.
Type B originates from 'App_Web_wz3shqfq, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
in the context 'Default' at location
'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\MyWebApp\dc3e0df6\ba1606c8\App_Web_wz3shqfq.dll'.
This permenantly fixed the problem for us.
EDIT:
Found a permenant solution, at least for us.
In web.config look for tag and add batch="false" to it. So it would look something like:
compilation debug="false" targetFramework="4.7.2" batch="false"
The error never repeated after this.
I'm sure there's a simple explanation for this, but I haven't had much luck at finding the answer yet, so I figured I'd put the word out to my colleagues, as I'm sure some of you've run into this one before.
In my (simple) dev environment, I'm working with a handful of WCF Web Services, imported into my FB3 project and targeting a local instance of the ASP.NET development Web server. All good, no problems -- but what I'd like to know now is, What's the right way to deploy this project to test, staging and production environments? If my imported proxies all point, say, to http://localhost:1234/service.svc (from which their WSDLs were imported), and all I'm deploying is a compiled SWF, does Flex Builder expect me to "Manage Web Services > Delete", "> Add", recompile and release ever time I want to move my compiled Flex project from development to test, and to staging, and ultimately into production? Is there a simpler workflow for this?
Thanks in advance -- hope my question was clear.
Cheers,
Chris
If you have path names which will change depending on the enviroment then you will likely need to recompile for each environment since these will be compiled in the swf.
I typically use ANT scripts to handle my compile/deployment process when moving from development and production environments. This gives me the ability to dynamically change any path names during the compile. These build files can be integrated into Flex Builder making this process very easy once you have everything set up, and can be done with one click or scheduled.
Thanks Brett. I've been meaning to dig into automating my build processes anyway, so now's probably as good a time as any. :)
You do not need to build a SWF for each environment. Here's a technique I use commonly:
Externalize your configuration properties into an XML file; in this case, it could be a URL for each service or a base URL used by all your services
When the application starts up, make an HTTPService call to load the XML file, parse it, and store your properties onto some bindable "configuration object"
Bind the values from that object against your objects that depend on the URLs
Dispatch an event that indicates your configuration is complete. If you have some kind of singleton event dispatcher used by some components in your app, use that, so that the notification is global
Now proceed with the rest of the initialization of your application
It takes a little work to orchestrate your app such that certain parts won't initialize until steps 1-5 take place. However I think it's good practice to handle a lot of this initialization explicitly rather than in constructors or various initialize or creationComplete events for components. You may need to reinitialize things when a user logs out and a different user logs in; if you already have your app set up to that initialization is something you can control then reinitialization will not be a problem.