If my ASP.NET webapp isn't fit for runtime? - asp.net

I want to run some tests when my ASP.NET webapp comes online (preferably before anyone tries to access it), to make sure all of my runtime dependencies are available as I expect them to be.
When is a good time to perform these tests (e.g. Application_Start, Application_Init, somewhere else, etc), and what's a good technique for making my webapp unavailable to users if my tests fail (it shares an app pool with other apps I don't want to affect)?

One approach would be to put your checks in the Application_Start event, and update a static property (or properties) in the Global class with the result of your test.
If you're using master pages, each master page (I've personally never seen more than 2 base master classes in a project) could check the static property in the Global class, and redirect to an "app offline" page if appropriate. Since the static property would only be updated when the application started, there shouldn't be any performance impact.
The code in your master page's OnLoad event might look like this...
if (!Global.WasDependencyCheckSuccessful)
{
//redirect to error page
}
If you're not using master pages, this may not be the best solution (because you would need to update each web form in your site individually).

You can put it in the Application_Start event in the global.asax.
To bring your app offline, simply create an App_Offline.htm file. I do it on our server by having an "App_Offline.html" file and when I need to bring it offline, I have the code rename it to change the extension from .html to .htm, and reverse that to bring it back online.
Of course, to bring it back online, you have to do it from code outside of your website, or do it manually, because if the file is there, the code in your website won't run...

Related

How to create a default user in global.asax?

The project I'm working on uses ms identity hooked into a mongo database. For deployment purposes (since there is no public registration), I'd like for the page to automatically check for an admin account and create one if its missing. I can't seem to do that however since there is no owin context when executing Application_Start() and thats the only way i know how to get to the user manager outside the whole mvc thing. Right now, It checks for the admin account every time the home page is loaded but it occurred to me that this is unnecessary bloat and I'd like to move it to somewhere thats visited less frequently.
The best solution I can provide you here is create an install.aspx. This you will execute manually and create a user for you.
In addition you could perform various application tasks, such as, refreshing application variables and so on...

per client master page separation

On the current project I'm working on we are developing a product that eventually gets used at various different client sites. At the moment the way things are done is that all code for all of the clients is included in the one solution, currently there's only about 5 or so clients so its manageable but I'd like to reorganize this so we can move these bits out to client specific areas.
In regards to the actual assemblies for various clients I think we can easily achieve something flexible using MEF or IOC.
The area im not sure about is the web side of things. Each client current has their own master page and these master pages are fairly radically different, apart from having the same content areas, the customization is probably not able likely to just be achieved by pure CSS.
Is there a way to have a "base" masterpage that would normally get used and then if we want to deploy to client A we can just inject somehow client As master page. Currently this is handled by all of the content pages referring to Master.master as their master page and then there is a generic Master.master, when deploying to client A we rename Master.master to something and rename the specifically tailored master page for client A (ClientA.master) to Master.master and deploy.
The down side to all of this is that all of the master pages are kept in the one web project which feels a bit wrong if we are trying to head to a client agnostic main branch, and unless the other master pages are deleted as part of the deployment the client would get a copy of them on their server even though they aren't used and preferrably we'd not like to have one client being able to switch to another clients view etc (not that security wise it would have any effect)
Have you checked out Themes. We have used themes for this sort of thing before.
If that does not have enough power for you you can do what you want in the pre_init phase. We use this code in some places
protected void Page_PreInit(object sender, EventArgs e)
{
this.MasterPageFile = "~/page.master";
}
You can of course use logic to determine what master page you wish to use.

Is there anyway to load up a asp.net page object and render its contents to string from a console application?

I am trying to use aspx pages as an email templates. There will likely be a bunch of objects on the page which will be used as replacements in the html. Because it's an aspx page I'll be able to use databinding, repeaters, etc. At run time, I want to be able to instantiate the aspx page from its path, pass in a bunch of properties, and then get the rendered result of the page and email it. This seems pretty straightforward from a asp.net website (maybe using BuildManager or Server.Execute.) However, I want to be able to use the same templates via a console application by just loading up a page object from its filepath. Is this possible?
You could host your own webserver. Like the Cassini webserver.
In my own application (a Windows-based Desktop-CMS), I include a web server, too (non-Cassini). It works very well, also it does not serve ASP.NET but plain, HTML.
As I did some research back then, I first wanted to use the Cassini, too, but at some point, I found out that too much user privileges were required to run it successfully; this may not be an issue to you, but keeping this in mind and try to run it early with the permissions of the later user, might be a good idea.

Must .aspx files have a page directive?

Around 90% of the pages for our websites have no .Net code embedded in them yet are published as .aspx files. I want these to render as fast as possible so I'm removing as much as I can.
Does the .Net page directive have an impact on performance? I am thinking about two factors; the page speed for each GET and what happens when the file changes. The CMS system re-creates each page daily and I'm wondering if this triggers the ASP.Net compilation process.
If your pages have no .NET code and rendering speed is your goal, you may wish to consider changing the extension to .html. Any .aspx page will be passed to the .NET ISAPI filter by IIS and go through the entire chain of HttpModules, then will be handled by the Page HttpHandler. Using a .html extension would trigger IIS to process the request using the Static Resource ISAPI filter, which has a much shorter pipeline and is tuned for resources that run no code.
The <%# Page %> directive is not required. Without it, the default values for Language and other stuff will be assumed.
By changing a .aspx file, it'll be recompiled (it doesn't recompile the whole app though):
Any changes to a dynamically compiled file will automatically invalidate the file's cached compiled assembly and trigger recompilation of all affected resources. The next time a request to the code is made, ASP.NET recognizes that the code has changed and recompiles the affected resources of the Web application. This system enables you to quickly develop applications with a minimum of compilation processing overhead. (Note that depending on the change to the resources, the result can range from recompiling a single page to recompiling the whole Web site.)
Ok, put them in - just to be sure.
.NET pages are ALL compiled, page directive or not. nothing changes. Post compilation, they are as fast as it goes, as they turn into a class (type loaded once) that just executes.
Note that the post by Mehrdad Afshari is factually wrong (sadly I can not tag it). Any page change triggers a complete recompile AND restart of the appdomain. Acutally any FILE change does so, as long as it is outside App_Data and ASP.NET can see it (i.e. non-hidden flag on the directory / file).

How to consolidate ASP.NET master pages across applications?

First shot at throwing a question on these boards so hopefully I can get some help, here goes:
I am working to start up the .NET practice at my client. We have 5 small scale .NET applications in place currently with a few them of them live into production. They're mostly small reporting pieces with some data entry/business logic functionality. Each of these applications is currently using the identical master pages.
What I mean is that there is a copy of the same master page in each application. They are all basic website->WCF->BL->DB tiered applications. So I have 4 copies of the same master page that I have to change when I make a change to it.
The client DOES NOT want to consolidate all of these into a single solution. They like the separation of applications across sites. I just don't want to continue dealing with the hassle of multiple updates for common elements (which there will be many more of across these applications).
The code is all stored in team foundation server. We also do NOT want to compile the master page into a .dll and deploy it.
Can anyone please make some suggestions as to how I can maintain a single copy of these common files (master, .css, etc) across my multiple applications.
thanks in advance
You might want to look at Sharing Master Pages in Visual Studio.
If that is no help then you could try using Build Events in Visual Studio. I would pick one of the projects to be my "Main Project" and only edit the master page from that project. When you build the project it would run a command that would copy that master page(if it had changed) to your set locations.
The client DOES NOT want to
consolidate all of these into a single
solution. They like the separation of
applications across sites. I just dont
want to continue dealing with the
hassle of multiple updates for common
elements (which there will be many
more of across these applications).
The code is all stored in team
foundation server. We also do NOT want
to compile the master page into a dll
and deploy it.
You eliminated the only two real options there. What all is in the master page? Would it be possible to extract the HTML UI elements to a single template or series of template HTML files and import those dynamically into the master page? You could then relocate the common HTML to an arbitrary URL and have the master page for each application pull it in dynamically.
Edit: I lied. You could also use a VirtualPathProvider like Sharepoint does to store the master page in a database or some other directory, but beware that VirtualPathProviders do not work in MediumTrust environments.
See:
http://msdn.microsoft.com/en-us/library/system.web.hosting.virtualpathprovider.aspx
If you are using Web Applications (compiled into a dll) rather than Web Sites you can do the following:
Right click on the folder you want to store the master page in
Select "Add Existing Item..."
Browse to the master page on the file system, and select both the .master and the .master.cs files.
Then, rather than clicking on the "Add" button, click on the little down arrow to the right of Add, this will bring up a little menu with the options: "Add" and "Add As Link"
Select "Add As Link" this will reference the file in your project, while leaving it in the original location in your dev environment - this allows you to edit it in either application, while keeping it up to date in the other applications.
Obviously if you edit the code behind, you'll need to re-compile the other projects before you deploy the changes to those sites.
This isn't available in web site projects as they rely on the file structure to work out what is in the project.
EDIT: Missed the css part. Obviously you won't be able to serve those files, so this should only work for the master page.
Don't know your scenario, so
IF you can control the DNS / virtual directories to the applications you could use a format like this:
c:\inetpub\wwwroot\Application1
c:\inetpub\wwwroot\Application2
c:\inetpub\wwwroot\Application3
c:\inetpub\wwwroot\Application4
c:\inetpub\wwwroot\Application5
and have your Master page at c:\inetpub\wwwroot\master.Master,
c:\inetpub\wwwroot\master.Master.cs,
c:\inetpub\wwwroot\master.Master.cs.designer
Then you could reference the single copy of the master page from /../master.Master. I gave this a quick shot with a precompiled master page to make sure I could reach back beyond my root. You might have to give it a shot to see.
We use our source control to create links to the shared files in all the places that we need it. So if you edit in one place, you just need to do a get latest and it will appear in the other places you have linked it.
I ended up going with the VPP route. I created a virtual path provider and built my master page into a DLL and this is working. Now I have a massive problem though in that a Content page whos master page is late bound through the codebehind throws validation/formatting hissy fits because it thinks its should be a stand along page. my CNTRL + K, CNTRL + D has broken on every page where I'm now sharing my master page. This is extremely frustring for me and the team

Resources