In SSRS 2005 (and 2008 I would imagine) you can provide functions to the reports, and if I'm not mistaken, whole assemblies as well, which allow you to perform some type of work before the report is rendered.
Does anyone know at what point in the ASP.NET page life-cycle is this function compiled and / or executed?
I would tend to think it's executed On_Render, but that's obviously just a guess.
Does anyone have any insight, and does a SSRS 2008 Report same functionality, and if so, at what point that that execute?
Custom code and report assemblies are compiled in the life-cycle of the report and not necessarily in the life-cycle of your page.
That means, in the usual asynchronous and remote processing case, it happens on the report server, after your page is rendered and sent to the browser.
From peeking with Reflector, I'd guess when not using asynchronous processing, it is happening during PreRender.
If your custom report assemblies need more than Execute permission, be sure to deploy them with appropriate permissions on the report server or, if processing locally, to call the AddTrustedCodeModuleInCurrentAppDomain method.
Related
I'm trying to debug an ASP.NET MVC application which uses the .NET 4.5 version of WIF to provide user identity. As those claims are being generated by a remote STS specific for that user, it's hard to test which claims are being received for a given user in an development environment.
What I would like is a mechanism that will allow me to see a user's claims by looking over their shoulder as they use the system. I immediately thought of the ASP.NET WebForms trace system as a source of tracing information and a convenient mechanism to display it, but I don't know of an equivalent in ASP.NET MVC.
Are there any built-in mechanisms to expose this information to me whilst debugging with a tester?
Options
Glimpse- like webform inpage trage/trace.axd on steroids. Works nice for MVC apps, has little to offer webforms though (the team has been promising big things though, it's an area to watch).
trace.axd - Trace.Write output should appear here, I've never tried to run it on a busy server. Access to trace.axd should work for an mcv app, not sure if inpage trace works for mvc-- I would guess not but I have never tried.
<% "Some trace" %> -- I sometimes dump diagnostics to all screens and put it in the footer, or put it in the footer then make the text white on white, so I can instruct the user on how see it and copy it, but they won't normally see it.
System.Diagnostics TraceSource and associated classes -- It's better than Trace.Write but has some flaws if you use trace a lot. Still, there are scenarios when you can't assume your favorite trace/logging library will be available. If I were to use this, I'd write a custom listener and write to your user's diagnostic data to the database, or a file, listeners already exist for files.
Log4Net -- a trace/logging framework. Supports writing to a variety of places-- console, database, file, etc. Has fewer design flaws that System.Diagnostics, but requires adding noe more dependency to your app. Use same as System.Diagnostics -- log to a file or database and inspect your users STS values there.
I've never had the good fortune of using WIF or STS, but I imagine that pretty printing an object and it's properties is the same for much any object. You may want to post a WIF/STS question separately if you need to know how to extract a particular piece of info from it.
Well - Trace.Write data shows up in the output window in VS while debugging. Maybe thats good enough. You can also add a trace listener for the System.IdentityModel trace source to get more insight into the token/claims processing.
What this part is doing? Especially why its time consuming, if I dont have ViewState and big object graph? It can take sometimes 3rd of request speed.
Found that this problem, is only on dev server.
I have also noticed that this stage is comparatively expensive even without ViewState (even with a nearly blank page)
I was able to speed this stage up drastically by running my project on my local IIS instance rather than running on the Visual Studio development web server. Compiling in release mode versus debug mode seemed to give a marginal improvement as well.
My guess is that 1) it is nothing to worry about and 2) the VS web server may be less optimized than IIS for some piece of the process. For example, IIS may cache machine values (such as registry settings, certificates, etc) and the VS web server may not.
If during SaveStateComplete an encryption routine is run (such as when EnableViewStateMac="true"), a call to local machine resources might be much more expensive running on the VS web server even if nothing is actually being encrypted.
I don't consider this a great answer; if you are really concerned you could profile ASP.NET to see what it is actually doing (for example, which BCL methods are being invoked).
the role of SaveStateComplete is to save control viewstate/controlstate before it is rendered. So, unless you have disable viewsate(EnableViewState="false" at page level) for your page/controls, the job is always done. Moreover, disabling viewstate doesn't disable controlstate.
Do you have many controls on your page?
I was talking to a guy and he says he likes his site with asp but not asp.net because its 'always compiling'. I Know aspx is compiled and is separate from the main app in a dll. But what does he mean by 'always compiling'? I thought it compiles once on startup and everything you modify aspx file if you modify at all.
But anyways, how is the performance of server side ASP.NET compared to others such as php, python, ruby and java?
You're right, ASP.NET dynamically compiles ASPX web pages and caches the generated binaries when a page is hit after one of the following events:
the IIS application pool has been recycled
a change is made in the bin folder
a change is made in the Web.config file
This dynamic compilation stage comes naturally with a price in terms of page responsiveness. However it affects only the first request coming in to a specific page while it represents an performance enormous benefit for the following requests, since they are served a cached
compiled version of the page.
The performance penalty paid by the first page request can be mitigated by performing the ASP.NET compilation and caching step ahead of time. This technique is known as web site precompilation and is done through a command-line tool included in the .NET Framework called ASP.NET Compilation Tool (Aspnet_compiler.exe).
Related resources:
Understanding ASP.NET Dynamic Compilation
ASP.NET Web Site Precompilation Overview
Very generally....
The "code behind" file is compiled in advance which would generally contain most of "your" code.
The aspx itself it also compiled, but usually not in advance which is probably his reason for saying "always compiling". Each page is compiled as required and the compiled version is cached in temp files until it needs to be compiled again.
'always compiling' of asp.net is possible in some cases - if website have rare requests and application pool's idle time-out(in iis) is very short(1 minute for example). You can note that first request takes long time(about even few seconds), but after first compile it asp.net runs very fast.
speed tests - http://www.wrensoft.com/zoom/benchmarks.html
Since asp (not ASP.NET) is a script language like php everything compiles every time.
In ASP.NET you have to differentiate between presentation items (aspx pages/views) and pure code items (classes/code behind etc).
In general compilation in .NET means compiling code into IL (Intermediate Language or more generally speaking: byte code).
When such a compiled component is actually used it compiles again into actual machine code.
This process is called 'Just In Time' (JIT) compilation.
Presentation
The presentation pages are compiled the first time they are accessed. But your web server notices when they are modified and recompiles them again.
Code
Code items in fact only get compiled once. At the time you hit build in VS.
So what does that mean performance wise? Well think about it, which is further the way from user readable code to machine code or from byte code which is already close to machine code to actual machine code?
I would go with the later any day and in the past for me ASP.NET always has been proven to be faster.
Yes. The absolute first time you access a page it might take longer, but this is not the case you should think about, its the 10th and 20th visitor that you should have in mind.
Does TFS 2010 have an SVN Post-Commit event ?
I want to run a script or an app or do stuff every time a developer checks in something. I've looked over the internet but didn't find something about this.
You will need to create (and publish) a web service and subscribe to the event. DotNetCurry has a decent article on the mechanics of wiring up the event.
http://www.dotnetcurry.com/ShowArticle.aspx?ID=330&AspxAutoDetectCookieSupport=1
I'm trying to do load testing against an ASP.NET web site and I need to be able to parametertise field value of a page to test different code paths.
I had great success with JMeter when load testing a JSP web site before. However, because ASP.NET encodes all form values in the ViewState, changing control values does not really work.
I Googled this problem and people said the web testing tool in Visual Studio Team Tester Edition works well with ASP.NET pages. However, it cost quite a bit so I am just wondering does anyone know how to get around the ViewState issue with JMeter or WAPT?
I've used WebLoad before. Its scripting language is basically JS, so you may be able to find controls on the page using JS and invoke them as part of your load script.
WebLoad is free.
I've figured out how to do this, basically you cannot simply record a static script with JMeter. What you need to do is to record a request, send it, capture the viewstate in the response and send the viewstate back in next request.
If you need more details, I've documented how to do this along with some screenshots on my blog post
As webapps get more complex (ViewState, AJAX, etc) it is tougher and tougher to use traditional load testing tools. That's because they try to jam a ton of virtual users on a very small amount of hardware resources.
My company, BrowserMob, took a different approach. We build a load testing service that uses real web browsers to drive load. Your scripts end up being essentially functional tests (specifically Selenium scripts). My background has been in Selenium for some time (I created Selenium RC and founded OpenQA.org), so as soon as cloud computing made it possible to rent the 5TB+ of RAM necessary to do this, I jumped on the idea :)