I am using routing with my ASP.NET WebForms application, using the technique described by Phil Haack:
http://haacked.com/archive/2008/03/11/using-routing-with-webforms.aspx
This works well most of the time, however on on occasion the first call to System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath is takes tens of seconds to return.
This happens in the following method:
public IHttpHandler GetHttpHandler(RequestContext requestContext)
{
LapTimer lapTimer = new LapTimer();
string virtualPath = this.GetSubstitutedVirtualPath(requestContext, lapTimer);
if (this.CheckPhysicalUrlAccess && !UrlAuthorizationModule.CheckUrlAccessForPrincipal(virtualPath, requestContext.HttpContext.User, requestContext.HttpContext.Request.HttpMethod))
throw new SecurityException();
IHttpHandler page = BuildManager.CreateInstanceFromVirtualPath(virtualPath, typeof(Page)) as IHttpHandler;
if (page != null)
{
//Pages that don't implement IRoutablePage won't have the RequestContext
//available to them. Can't generate outgoing routing URLs without that context.
var routablePage = page as IRoutablePage;
if (routablePage != null)
routablePage.RequestContext = requestContext;
}
return page;
}
At the same time as this I notice (using Task Manager) that a process called csc.exe, the C# compiler, is taking up 10%-50% of my CPU.
Can anyone suggest why this would be happening?
Your application is using runtime compilation of views. While your business logic, codebehind etc (basically any .cs file) gets compiled by Visual Studio, your views (*.aspx, *.ascx, *.Master) are compiled by the asp.net runtime when a given view is first requested (i.e. the BuildManager is asked for an object that corresponds to a given virtual path). It might take some time because views might be compiled in batches (e.g. all views in a single folder).
A view will be recompiled if you change it. Also all view compilations will be invalidated if the App Domain recycles (which can happen if you make changes to web.config, global.asax, etc).
All this is normal behavior in ASP.NET. If you find that this is unacceptable in your scenarios you can use precompiled applications. This will provide you with app startup perf benefits at the cost of being able to easily tweak the markup of your site withouth having to recompile everything.
Related
First, I do not believe this is a dupe of these:
GetEntryAssembly for web applications
Get entry assembly from ASP.NET application
I have an ASP.NET WebForms app that references a class library. When I call Assembly.GetEntryAssembly() from within the class library while it's referenced by the ASP.NET app, it returns null. However, when I call that same code while the class library is referenced by a console app, it returns the console app assembly.
This answer perhaps sheds light on why Assembly.GetEntryAssembly() behaves differently with ASP.NET:
Why do ASP.NET resolve assembly references differently?
Still, I'd like to be able to get the ASP.NET assembly as if it were a Windows application (console, WPF, WinForms, etc). Is there any way to allow my class library to know about the ASP.NET assembly without adding any ASP.NET references?
Edit: While not the solution I am looking for, this works for the time being. Basically, I use the code below provided by the answerer from one of the questions above to get the ASP.NET assembly from within the web app and then pass it as an argument to a method in my class library.
There's also AppDomain.CurrentDomain.GetAssemblies() which does expose the ASP.NET assembly when called within the class library, but there are like 50 assemblies loaded in the app domain which means you'd need a magic string to get the assembly name. Definitely not an option, but it could work.
static private Assembly GetWebEntryAssembly()
{
if (System.Web.HttpContext.Current == null ||
System.Web.HttpContext.Current.ApplicationInstance == null)
{
return null;
}
var type = System.Web.HttpContext.Current.ApplicationInstance.GetType();
while (type != null && type.Namespace == "ASP") {
type = type.BaseType;
}
return type == null ? null : type.Assembly;
}
An ASP.NET application is started by IIS worker process, which is a native module, in most cases. Thus, that API should return null to reflect the differences from a console application.
Whatever you want to achieve with that API, find an alternative way instead.
My company would like to update legacy visual basic 6/classic asp code. We do not have access to a visual basic 6 compiler, so it seemed like a good idea to use Visual Studio 10 and recompile the visual basic 6 code as a VB.NET class. With some minor modifications everything compiled and we registered it as a com object to be called from classic asp.
Now we are trying to access global variables from the asp server. After an extensive search on Google, the only way mentioned was to use System.Web.HttpContext.Current or System.Web.HttpContext.Current.Application . However, this doesn't appear to work.
Here is the code leading up to error. We have imported System and System.Web.
Public Function DoSomethingUseful() As String
Dim objCurrent As System.Web.HttpContext
DoSomethingUseful = Nothing
objCurrent = System.Web.HttpContext.Current
If objCurrent Is Nothing Then
Throw New Exception("No Context.") '<--- THIS EXCEPTION IS THROWN
End If
The problem is we can't get a current instance of the http context and the exception is thrown. Every example I've seem shows that the line objCurrent = System.Web.HttpContext.Current should work but it doesn't. Perhaps it's because we are not using ASP.NET? If not then why isn't it working?
Yes, it is because you're not using ASP.NET.
Despite the similar sounding names, and to a certain degree similar design choices, there is no relationship whatsoever between ASP.NET anything and "Classic" ASP anything. They are completely independent environments.
To access directly the ASP context objects (not the similarly-named ASP.NET context objects which in your application don't even exist), your object must be a registered COM+ object, so:
Your class must inherit from System.EnterpriseServices.ServicedComponent *
On Windows 7/2008 and up, you must enable the "Allow IIS Intrinsic properties" from Component Services, just like you would have to in VB6 (open \Component Services\My Computer\COM+ Applications\YourComPlusApp\Components; select all the objects that need the ASP objects; right-click; click on Properties; go to the Advanced tab).
You can then retrieve the ASP objects (Application, Server, Request, Response, Session) from the COM+ ObjectContext.
Your code would look something like this:
objCurrent = System.EnterpriseServices.ContextUtil.GetNamedProperty("Application")
There are also attributes that you can add to your class to simplify the deployment of the code, but that's a bit outside the scope of this question.
For your reference:
ASP Built-in Objects
ContextUtil.GetNamedProperty Method
* I don't remember 100% if this is a hard requirement. It might actually depend on what the object is actually doing with COM+.
I have a Windows Azure web role that contains a web site using ASP.NET MVC. When an HTTP request arrives and a page is first loaded the view (.aspx or .cshtml) is compiled and that takes some time and so the first time a page is served it takes notable longer than later serving the same page.
I've enabled <MvcBuildViews> (described in this answer) to enforce compile-time validation of views, but that doesn't seem to have any effect on their compilation when the site is deployed and running.
Azure web roles have so-called startup tasks and also a special OnStart() method where I can place whatever warmup code, so once I know what to do adding that into the role is not a problem.
Is there a way to force compilation of all views?
Take a look at Precompiled Razor Views by David Ebbo
Why would you want to do that?
One reason to do this is to avoid any runtime hit when your site
starts, since there is nothing left to compile at runtime. This can be
significant in sites with many views.
Also, you no longer need to deploy the cshtml files at all, resulting
in a smaller deployment file set.
Another cool benefit is that it gives you the ability to unit test
your views, which has always been something very difficult with the
standard runtime compilation model. I’ll cover that in more details in
a future post.
Turns out there's ASP.NET Precompilation that can be performed using ClientBuildManager.PrecompileApplication and mimics the on-demand compilation behavior, but just compiles every page. Tried it - the first load looks notably faster.
The non-trivial part is what to pass as ClientBuildManager constructor parameters. The solution is to enumerate all .Applications of the Site object and for each item in .Applications enumerate all .VirtualDirectories and use Path and VirtualPath from each item as parameters to ClientBuildManager constructor.
Is this an initial-load issue or a steady-state issue? One issue seen is that of app pool recycling, which defaults to 20 minute timeout. If you disable timeout (or set it to something large), is that a valid workaround?
Here's another SO answer discussing AppPool timeout and how to disable it. Basically:
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.processModel.idleTimeout:00:00:00
Add this to OnStart:
using (var serverManager = new ServerManager())
{
string siteName = RoleEnvironment.CurrentRoleInstance.Id + "_" + "Web";
var siteId = serverManager.Sites[siteName].Id;
var appVirtualDir = $"/LM/W3SVC/{siteId}/ROOT"; // Do not end this with a trailing /
var clientBuildManager = new ClientBuildManager(appVirtualDir, null, null,
new ClientBuildManagerParameter
{
PrecompilationFlags = PrecompilationFlags.Default,
});
clientBuildManager.PrecompileApplication();
}
If you use the Publish functionnality of Visual Studio, there is a much simpler option :
On the Publish dialog > Settings pane, expand File Publish Options and check Precompile during publishing then click configure. On the Advanced Precompile Settings dialog box, uncheck Allow precompiled site to be updatable.
source: https://msdn.microsoft.com/en-us/library/hh475319.aspx
I have the requirement that the end-user can change localized resources and the changes should be visible in the application without the need to restart the application.
Update to clarify the scenario:
I am talking about changing the localized resources at runtime. Lets say I have a typo in the german translation of a page. Then some admin-user should have the possibility to change that typo at runtime. There should be no need for a redeployment or restart in order for this change to be reflected in the UI.
I am using ASP.NET MVC3.
What options do I have?
I have been looking into writing a custom ResourceProvider that loads resources from the database.
This seems not too much effort, however so far I pointed out two drawbacks:
It is not working with the DataAnnotations that are used for convenient validation in MVC3 (DataAnnotations work with a ErrorMessageResourceType parameter, which only works with compiled resources)
We basically have to provide our own tooling around managing resources (like translating etc.) which is a pity, since there are a lot of tools for this that work with resx-files.
What are the other options? Would manipulation of the deployed resx-files at runtime be an option?
But I suspect that the application is automatically "restarted" when it detects those changes: I suspect ASP.NET realizes that the resx-files have changed, it then recycles the application-pool and compiles the new resx-files on the fly.
Is this correct? Is there any way around this?
I have not yet looked into compiling the resources into satellite assemblies before deployment. Is this even a recommended scenario for web applications?
But even with compiled satellite assemblies I suspect that ASP.NET restarts the application, when those assemblies are changed on the fly. Is this correct?
I would be interested in any experience in how the original requirement can be satisfied?
And I would be interested in any comments about the options I have mentioned above.
DataAnnotations accept a ErrorMessageResourceType which tells the ValidationAttrributes where to access resources. You can pass this as follows:
[Required(
ErrorMessageResourceType = typeof(DynamicResources),
ErrorMessageResourceName = "ResourceKey")]
public string Username { get; set; }
By creating a type for this parameter with static properties for each key you can create an implementation that loads resources from a database or other implementation. You could then combine this with a dynamic object for DRY and move the implementation into TryGetMember. Potentially then use T4 templates to generate the statics from your database at compile time, ending up with this:
public class DynamicResources : DynamicObject
{
// move these into partial and generate using T4
public static string MyResource
{
get { return Singleton.MyResource; }
}
public static string MyOtherResource
{
get { return Singleton.MyOtherResource; }
}
// base implementation to retrieve resources
private static dynamic singleton;
private static dynamic Singleton
{
get { return singleton ?? (singleton = new DynamicResources()); }
}
public override bool TryGetMember(GetMemberBinder binder, out object result)
{
// some logic here to look up resources
result = GetResourceKeyFromDatabase(binder.Name);
return true;
}
}
Of course it would be perfect if resources weren't static properties.
I really tried hard to find a similar issue to get some leads, but no one seems to describe the case we are having, so here it goes.
Background
We have a product with the following general design:
[Local installation folder]
Contains a set of .NET assemblies, implementing the bulk of our product functionality.
Example: Implementation1.dll, Implementation2.dll
[GAC]
ClientAPI.dll. Our client assembly, to be referenced from end user Visual Studio projects. Has strong references to the implementation dll's in the local installation folder.
In ClientAPI.dll, we have an entrypoint we require end user projects to invoke. Lets call it Initialize().
The very first thing we do in Initialize is to install a so called assembly resolve handler on the current domain, using the AssemblyResolve event. This handler will know how to locate the implementation dll's and load them into the client process, using Assembly.Load().
Consider a console application. It will look something like:
class Class1
{
void Main(string[] args)
{
ClientAPI.Initialize();
// Use other API's in the assembly, possibly internally referencing the
// implementation classes, that now will be resolved by our assembly
// resolve handler.
}
}
Now, all is good in the console/windows forms/WPF world. Our assembly resolve handler is properly installed and invoked, and it can successfully resolve references to the implementation DLL's once ClientAPI.dll require their functionality.
Problem statement
With that being said, we intend not to support only console or WPF applications, so we were relying on the same design in ASP.NET. Hence, creating a new ASP.NET Web Application project in VS 2010, we figured everything would be as straightforward as:
class Globals : HttpApplication
{
void Application_Start(object sender, EventArgs e)
{
ClientAPI.Initialize();
// ...
}
}
A few 20-30 hours of dwelling in the ASP.NET runtime universe, trying the above in both the development server and in IIS, we've learned that things there are not really as we expected.
It turns out that in ASP.NET, as soon as the ClientAPI class is referenced anywhere, all references it has to any other assemblies are instantly resolved. And not only that: the results are cached (by design, since .NET 2.0 we've found), meaning we never have a chance at all trying to assist the CLR.
Without further elaboration about the different things we've tried and learned, it basically comes down to this question we have:
Why is ASP.NET resolving references like this? It is not compatible with how other types of applications does it, and even more, it is not according to the documentation of .NET / the CLR runtime, specifying that references to external types / assemblies are to be resolve when first needed (i.e when first used in code).
Any kind of insight/ideas would be highly appreciated!
Windows Forms / WPF applications run on individual client machines (and therefore run in a single, local context), whereas ASP.Net runs within IIS, within an application pool, on a server or set of servers (in a web farm situation). Whatever is loaded in to the application pool is available to the entire application (and therefore is shared between all clients who connect to the application).
HttpApplication.Application_Start is executed once, when the application starts up. It is not executed per client as it would be with a Winforms application - if you need to initialize something for every client that connects, use Session_Start or Session_OnStart, but then you may run in to memory issues with the server, depending on how many clients are going to connect to your web application. This also depends on whether your class is a singleton, and if the Initialize() method is static. If you have either of those situations, you're going to run in to cross-threading problems fairly quickly.
Additionally, it's worth noting that an idle IIS application pool will reset itself after a period of time. If no one uses the web application overnight, for example, IIS will flush the application's application pool and free up memory. These settings can be changed within IIS administration, but you should be careful when doing so - changing these settings to circumvent a badly designed object (or an object that isn't designed for a web application) can create even more problems.
FYI - I'm being a little fussy, but for the avoidance of doubt, the object is not cached - yes, it is loaded in to memory, but how the memory is managed is up to how you've designed the object (caching in the web world is an entirely different thing, and can be implemented in many different layers of your application).
Don't try and make a web application act like a windows application; you'll just create yourself more problems!