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
Related
Spent several hours today trying to write some unit tests against an ASP.NET project. It's Visual Studio 2010.
Using Windows 7 Enterprise with IIS7.
Steps I took were:
Added a new test project to the solution
Opened a class file as part of the web site (Member.vb)
Right clicked within the class file and "Generate unit tests"
Select the methods I wish to generate stubs for, choose to add to my test project, click OK
Open up the generated MemberTest.vb file in the test project, click within one of the generated tests, click "Run tests in curent context"
When following these precise steps on my Windows XP Professional with IIS6 machine it works fine.
However on the Windows 7 Enterprise machine on IIS7 I get:
The URL specified ('http://localhost/MyProject') does not
correspond to a valid directory. Tests configured to run in ASP.NET in
IIS require a valid directory to exist for the URL. The URL may be
invalid or may not point to a valid Web application.
So what's going on, I can confirm I can browse to http://localhost/MyProject and it displays perfectly.
I feel sure I'm missing some sort of config in Windows/IIS but I'm really at a loss.
Generated test method:
<TestMethod(), _
HostType("ASP.NET"), _
UrlToTest("http://localhost/MyProject")> _
Public Sub MyMethodTest()
Dim target As Member_Accessor = New Member_Accessor() ' TODO: Initialize to an appropriate value
Dim CurrentVal As Short = 0 ' TODO: Initialize to an appropriate value
Dim expected As Short = 0 ' TODO: Initialize to an appropriate value
Dim actual As Short
actual = target.MyMethod(CurrentVal)
Assert.AreEqual(expected, actual)
Assert.Inconclusive("Verify the correctness of this test method.")
End Sub
(Cross-posted at ASP.NET Forums)
This could be a permissions issue.
If you're using the default directory (C:\users\\Documents\Visual Studio 2010\Projects), the app identity pool does not have permissions there. You'd have to create a project in something like C:\webs and make sure app pool identity has permission to the folder.
Refer to Rick Anderson's blog post at http://blogs.msdn.com/b/rickandy/archive/2011/04/22/test-you-asp-net-mvc-or-webforms-application-on-iis-7-in-30-seconds.aspx and see if that helps.
If you have not done unit testing before, I would really recommend that you start by just testing the functionality of your classes as cleanly as possible. Try to break you you functionality into small pieces that can be tested individually without and dependencies to the web context.
Have a look at this question for an idea about What is unit testing
Here is an MSDN Magazine article about testing
You can also have a look at this Blog. The examples are using NUnit but the principal is the same if you are using MSTest.
I can also recommend Roy Osheroves Book Art of unit testing
In you case if the Member class does not have dependencies to web context you don't need the IIS and could instead just do something like this:
<TestMethod()> _
Public Sub MyMethodTest()
Dim target = New Member()
Dim CurrentVal As Short = 0 ' TODO: Initialize to an appropriate value
Dim expected As Short = 0 ' TODO: Initialize to an appropriate value
Dim actual As Short
actual = member.MyMethod(CurrentVal)
Assert.AreEqual(expected, actual)
End Sub
I ran into the same problem today. After some research, I found this thread which suggested I check my event log. Upon doing that, I discovered numerous errors similar to the following:
(QTAgent32.exe, PID 12348, Thread 61) WebSites.GetWebServer: failed to
create AspNetHelper:
Microsoft.VisualStudio.Enterprise.Common.AspNetHelperException: The
website metabase contains unexpected information or you do not have
permission to access the metabase. You must be a member of the
Administrators group on the local computer to access the IIS metabase.
Therefore, you cannot create or open a local IIS Web site. If you
have Read, Write, and Modify Permissions for the folder where the
files are located, you can create a file system web site that points
to the folder in order to proceed. --->
System.Runtime.InteropServices.COMException: Unknown error
(0x80005000)
That lead me to this blog post which seems to have resolved the issue.
I just needed to go to "Turn Windows features on or off" and add IIS 6 Management Compatibility and all four subcomponents. I'm running Windows 7 Home Premium which doesn't have the Windows Authentication option, but that didn't seem to be an issue. Give it a shot and see if that resolves the issue for you.
You may need to enable "Use IIS" in the project properties, then click "Create Virtual Directory". Do you have IIS Express installed?
I want to make a "properties style web form" that shows the application version for various .NET applications.
If I know the URL e.g. /someapp/default.aspx is it possible via reflection to execute that page and figure out the assembly version?
It's quite easy to find the executing assembly version, but without modifying the other application, is it possible?
Both the property page and the other application is running on the same server and in the same application pool.
Update: I've had some luck with
var url = "~/SomeApp/default.aspx";
var appType = System.Web.Compilation.BuildManager.GetCompiledType(url);
But navigating appType to find the assembly file version is not the same everytime.
Without modifying the web application to expose the version number through some URL-based retrieval (a simple page GET being the easy, obvious one), you're going to need to find a way to figure out where the DLL for the web application is from the URL.
If you can know the DLL's location, either by some convention (e.g. /appX/ is always at D:\Sites\appX\bin\appX.dll) or some configuration (you manually enter where each URL base's DLL is in a database), then you can retrieve that DLL's assembly version using the following code:
Assembly assembly = Assembly.LoadFrom("MyAssembly.dll");
Version ver = assembly.GetName().Version;
Code taken from this question.
Edit:
I've had a little look around, and there are some APIs to inspect the IIS configuration, so this is certainly a route to explore if you're trying to get from the URL to the assembly location. This question has an example of getting the physical path from the application/site name, for example. Microsoft.Web.Administration is the assembly to explore.
The ASP.NET engine streams nothing but HTML, javascript, etc.. to the client. There is nothing left of the assembly that gets passed in the response that can show what version of .net/asp.net that the application is running unless the developer on the server side adds it.
That said, you can gather some information from a utility at http://uptime.netcraft.com/up/graph that will give you some server information. Not down to the assembly version, but this is as close as I believe you are going to get.
You may implement custom HttpModule, put it to the bin folder of each application that you wish to monitor and append register this module in web.config files. In this module for example you should handle request, retrieve all required information and put it to response cookie.
The challenge is to determine whether ASP.NET is enabled within IIS7 in a reliable and correct way.
Enabling/Disabling is done in this case by going into:
Server Manager ->
Roles ->
Web Server (IIS) ->
Remove Role Services ->
Remove ASP.NET
The natural place to determine this should be within the applicationHost.config file. However, with ASP.NET enabled or disabled, we still have the "ManagedEngine" module available, and we still have the isapi filter record in the tag.
The best I can find at the moment is to check if the <isapiCgiRestriction> tag includes the aspnet_isapi.dll, or that the ASPNET trace provider is available.
However these aren't detecting the presence of the ASP.NET config directly, just a side effect that could conceivably be reconfigured by the user.
I'd rather do this by examining the IIS configuration/setup rather than the OS itself, if possible, although enumerating the Roles & Services on the server might be acceptable if we can guarantee that this technique will always work whenever IIS7 is used.
Update
Thanks for the responses. Clarifying exactly what I want to do, I'm pulling settings from a variety of places in the server's configuration into a single (readonly) view to show what the user needs to have configured to allow the software to work.
One of the settings I need to bring in is this one:
The one highlighted in red.
I don't need to manipulate the setting, just reproduce it. I want to see whether the user checked the ASP.NET box when they added the IIS role to the server, as in this example they clearly didn't.
I'd like to do this by looking at something reliable in IIS rather than enumerating the role services because I don't want to add any platform specific dependencies on the check that I don't need. I don't know if it will ever be possible to install IIS7 on a server that doesn't have the Roles/Services infrastructure, but in preference, I'd rather not worry about it. I also have a load of libraries for scrubbing around IIS already.
However, I'm also having trouble finding out how to enumerate the Roles/Services at all, so if there's a solution that involves doing that, it would certainly be useful, and much better than checking the side effect of having the ASPNET trace provider lying around.
Unfortunately, if you don't check the ASP.NET button, you can still get the ManagedEngine module in the IIS applicationHost.config file, so it's not a reliable check. You can also have ASP.NET mapped as an isapi filter, so checking them isn't enough. These things are especially problematic in the case where ASP.NET was installed but has been removed.
It looks like the best solution would be to examine the Role Services. However, API information on this is looking pretty rare, hence the cry for help.
The absolute way to know if they checked that or not is to search the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Components
In there you should see two values set to 1, ASPNET and NetFxEnvironment and NetFxExtensibility. This registry key is the IIS Setup key that contains all the components that have been enabled in IIS.
Determining if asp.net is even an installed feature (prerequisite for enabling it) can be done through PowerShell, which implies there is .net api out there for it if you dig hard enough. The PowerShell methods:
Import-Module servermanager
Get-WindowsFeature web-asp-net
Which will return an object of type Microsoft.Windows.ServerManager.Commands.Feature. The installed property is boolean and indicates whether or not the feature is installed.
So do you want the easy way? Make a nice pretty .aspx page that displays as HTML with an error block in a div in a placeholder saying "You need to install ASP.NET" and have it change on ASP.NET being installed to instead say "ASP.NET is installed" and then just have the tool launch this webpage in the default browser after copying it to the directory identified in IIS as the *:80 site (or create the directory mapping in IIS programmatically by altering the XML and then removing it later)
May not be the most elegant but it does ensure that testing shows what features are truly installed versus what's in an XML file.
Because that will scream "do it the lazy ignorant way" I'll remind you that the only way for me to know in javascript what features I can use is to test them before I try to use them, or assume they're there and watch it blow up. My point is, it doesn't matter what gets reported in a file, it matters what you can actually use. Just because C:\Windows\Micrsoft.Net\Framework\v3.xxxxxxxx exists and has files doesn't mean the dll's are registered in the GAC, does it?
Intro:
Normally we store ConnectionStrings and some other settings (<appSettings> <add key...) in the Web.config or App.config.
My scenery:
Web application using factory pattern
with direct injection to read data
providers.
In the web.config I have the key
that tells me which DLL (provider)
will I use to retrieve my data.
I can have more than one provider
(each DLL will be a provider for MS
SQL, MySQL, or get the data from
some SOA service).
Each DLL has his own name (ID and namespaces) and will need to have is own
configurations (dataconnections,
service urls, etc...) , the first
idea is to write then in the
app.config.
Problems:
#1 - The website is running (runtime) I need to change the Data Provider, how can I do this? Somehow the default value written in the Web.config will be changed.
My objective is to be able to have multiple providers (and during runtime: add/delete providers and change configurations) - this leads me to my second problem:
.
#2 - Each Data Provider has custom configurations and App.Config files do not work with dll assemblies, only executables. This means that I need to write then on my Web.Config (I do not like this option, because once again I am updating my web.config in runtime). how can I solve this?
I am trying to avoid to write a custom settings XML file. My ideal solution is to deploy somehow the DLL and DLL.config per each provider. And once again during runtime I may need to change this configuration values.
.
Ok guys, while I was waiting for some help I put my hands to work and I was able to find a good solution (in my opinion of course :P).
Let me share it with you:
So, I have one web application, or one console application, or some other kind of application, and lots of class library, and I need to store informations (different per Visual Studio project) that will change during runtime.
Storing this information inside the Web.config or App.config is not a good idea for the many problems it takes.
The other way I see it is to have one XML config file per project.
Each application will read his own XML and add it to the Cache with CacheDependency (will expire when the XML config file is updated). This way we will not need to read the configuration all the times, and we also know when the configuration is changed.
IMO THIS IS THE FASTEST AND EASIEST WAY TO SOLVE THE PROBLEM, no need to use 3rd party frameworks (neither the time it takes to learn/program it).
.
Example code:
protected void Page_Load(object sender, EventArgs e)
{
DBConfiguration cachConf;
cachConf = Cache["cachConf"] as DBConfiguration;
if (cachConf == null)
{
cachConf = new DBConfiguration();
XmlDocument doc = new XmlDocument();
doc.Load(HttpContext.Current.Request.PhysicalApplicationPath + "bin/MyConf.xml");
XmlNodeList xnl = doc.GetElementsByTagName("username");
XmlElement xe = (XmlElement)xnl[0];
cachConf.Username = xe.InnerText.ToString();
xnl = doc.GetElementsByTagName("password");
xe = (XmlElement)xnl[0];
cachConf.Password = xe.InnerText.ToString();
Cache.Insert("cachConf", cachConf,
new System.Web.Caching.CacheDependency(
HttpContext.Current.Request.PhysicalApplicationPath + "MyConf.xml"),
DateTime.Now.AddMinutes(60), TimeSpan.Zero,
System.Web.Caching.CacheItemPriority.Default,
new System.Web.Caching.CacheItemRemovedCallback(
CacheItemRemovedCallBack));
}
LabelUsername.Text = cachConf.Username;
LabelPassword.Text = cachConf.Password;
}
private void CacheItemRemovedCallBack(string key, object value, CacheItemRemovedReason reason)
{
//Response.Write("Hello world");
}
You could store the credentials in a secondary config file referenced from web.config as follows:
<appSettings file="AppSettings.config"/>
You would still need to be careful to avoid editing conflicts on the external file.
Problem 1 - Runtime changes:
The solution that Microsoft hopes you apply to this type of problem is to simply keep the web server stateless. When an ASP.NET application recycles, it lets existing requests complete new requests start on a new process. For background, read about IIS Process Recycling. A change to web.config recycle the worker process, but users will not notice this (unless you keep state in the web server process). That's the MS design.
If you want to monitor for changes without recycling a process, you'll want something other than default web.config behavior. An example that comes to mind are cruise controls project files. They have a component that maps objects to and from xml, using that, you can use the FileSystemWatcher class to monitor for changes.
Problem 2 - Custom configurations:
It sounds like you have components from different libraries that have different dependencies. Your main assembly needs a means to instantiate a service, with a given set of dependencies. The MS data provider model is cool, but not this cool.
To be this cool, use an inversion of control container, because this is exactly what they do. I like autofac (because I like the Philip K Dick reference), but castle windsor is great.
Now, if you are talking about changes databases or data providers on the fly, it may be that configuration is not the right place. If your are reporting against x databases of y types, you need a central repository of that database information, and a configuration file is not the right place, nor is an IOC container the right solution.
As Precipitous suggested, try Castle Windsor:
http://www.castleproject.org/container/
You're doing Inversion of Control manually. Windsor will take the burden off of you.
I'm hosting the ASP.NET runtime via the ApplicationHost.CreateApplicationHost method. When I modify the web.config while the application is running, i see lots of first chance ThreadAbortExceptions thrown. This is right before my application comes crashing down. I'm assuming this is because the runtime has detected changes to the configuration and wants to restart.
This isn't really a supported scenario for us, so i'd prefer if I could just switch off the automatic reloading.
Does anyone know how to do this?
Actually, the first two answers are incorrect. It is possible, and quite easy, to prevent this recycling from happening, and this feature has been available since at least IIS6.
Method 1 (system wide)
Change the DWORD registry setting for HKLM\SOFTWARE\Wow6432Node\Microsoft\ASP.NET\FCNMode to the value 1, which will disable all file change notifications.
Don't be confused by the location: Wow6432Node has, in this case, no influence on the bitness of your web application.
Method 2 (.NET 4.5+)
If you are using .NET 4.5, then it is now possible to disable this on a per-site level, simply use the following in your web.config:
<httpRuntime fcnMode="Disabled"/>
Method 3 (IIS6+)
Finally, and also (at least) around since IIS6, there's a setting called DisallowRotationOnConfigChange as a setting for only the application pool (at least that is what I think the text on MSDN tries to say, but I haven't tested it). Set it to true and changes to the configuration of the application pool will not result in an immediate recycle.
This last setting can also be set from Advanced Settings of the application pool:
Method 4 (ASP.NET 1.0 and 1.1)
For (old) websites using ASP.NET 1.0 or 1.1, there is a confirmed bug that can cause rapid and repeated recycles on file changes. The workaround at the time was similar to what MartinHN suggested under the main question, namely, something like the following in your web.config:
<compilation
debug="false"
defaultLanguage="vb"
numRecompilesBeforeAppRestart="5000">
This does not disable recycling, but it does so only after 5000 recompilations have taken place. Whether this number is useful depends on the size of your application. Microsoft does not clearly say what a recompilation really is. The default, however, is 15.
As an aside: regardless of the version of .NET or Windows, we find that when the application is run from a share and used in a load-balanced environment, that the site recycles continuously. The only way to solve it was by adding that FNCMode setting to the registry (but now there are more fine-grained options).
As far as I am aware there is no way to disable this behavior, changes to the webconfig force the application to be restarted.
Update: it is actually possible, there are a number of methods, well documented, as explained in this answer*
Original answer:
There is a similar question here just for other reference. I found additional info that may be helpful.
Configuration Changes Cause a Restart
of the Application Domain
Changes to
configuration settings in Web.config
files indirectly cause the application
domain to restart. This behavior
occurs by design. You can optionally
use the configSource attribute to
reference external configuration files
that do not cause a restart when a
change is made. For more information,
see configSource in General Attributes
Inherited by Section Elements.
From This MSDN Article
* Disclaimer: I wrote the other answer and normally wouldn't make a self-reference, but find it relevant enough to link here since 8 years after this post it is really quite different: a solution is very easy by clicking through the IIS front-end, and workarounds exist since ASP.NET 1.0.
I ran in to an even bigger problem along the same lines - changes to any file or sub-folder in the AppDomain base directory cause the hosting environment to shutdown. This is a pretty big issue for our application as we're running a WPF UI in the same AppDomain and we can't restart it without being distruptive to the user.
I really wanted to avoid having to run a separate AppDomain for the web based part of the application so I did some digging with Reflector. I found that the culprit was the internal class FileChangesMonitor.
So I wrote a horrible horrible reflection hack to solve the problem. I thought I'd post it here as a potential solution for anyone else having the same problem. You just need to call HttpInternals.StopFileMonitoring() to disable shutdown on file/folder changes.
internal static class HttpInternals
{
private static readonly FieldInfo s_TheRuntime = typeof(HttpRuntime).GetField("_theRuntime", BindingFlags.NonPublic | BindingFlags.Static);
private static readonly FieldInfo s_FileChangesMonitor = typeof(HttpRuntime).GetField("_fcm", BindingFlags.NonPublic | BindingFlags.Instance);
private static readonly MethodInfo s_FileChangesMonitorStop = s_FileChangesMonitor.FieldType.GetMethod("Stop", BindingFlags.NonPublic | BindingFlags.Instance);
private static object HttpRuntime
{
get
{
return s_TheRuntime.GetValue(null);
}
}
private static object FileChangesMonitor
{
get
{
return s_FileChangesMonitor.GetValue(HttpRuntime);
}
}
public static void StopFileMonitoring()
{
s_FileChangesMonitorStop.Invoke(FileChangesMonitor, null);
}
}
A solution would be adding following element to web.config section :
<httpRuntime
waitChangeNotification="315360000"
maxWaitChangeNotification="315360000"
/>
As mentioned by jfburdet the solution is to use waitChangeNotification and maxWaitChangeNotification.
That being said, you should know they don't work on IIS 7 if ASP.NET is run in mixed mode: http://forums.iis.net/t/1149344.aspx