How to change Global.asax to code-behind

[ad]

The Global.asax is code-inside with default.
How to change Global.asax to code-behind?

 

[Scott Allen]

In global.asax you need to modify the @ Application directive.

<%@ Application
Codebehind="Global.asax.cs" Inherits="YourNamespace.Global" %>

Then create your .asax.cs file, and add a class named Global derived
from System.Web.HttpApplication.

 

[Juan T. Llibre]

AFAIK, that's gone from ASP.NET/VS.NET 2.0, though.

The new Web project model affects the Global.asax file.

In 2.0, when you convert a previous project :

1. the global.asax code-behind file's contents are moved to the App_Code directory.

2. The CodeBehind and Inherits attributes are removed from the @ Page directive.

3. A Language attribute is added to the @ Page directive, if one is not already specified.

4. For Visual Basic, a Namespace statement is added to the class file.
The namespace is defined by the root namespace in the Web project.

VS.NET 2005 won't even let you create a global.asax
with a code-behind file in any new website you create.

See : http://msdn2.microsoft.com/en-us/library/421whcfb(en-us,vs.80).aspx

The section titled "Global.asax File"




Juan T. Llibre
ASP.NET MVP
ASP.NET FAQ : http://asp.net.do/faq/
==========================

 

[Scott Allen]

That's an odd piece of documentation you found, Juan. I'm not sure why
global.asax would ever have an @ Page directive.

I know VS2005 doesn't let you create a global.asax with a code-behind
file, but adding the CodeBehind and Inherits attributes and putting
the .cs file in App_Code does work - I've tried it. There is not much
of a benefit in doing so, though.

 

[Juan T. Llibre]

re:

I'm not sure why global.asax would ever have an @ Page directive.

The doc refers to the changes made by project *conversions*.
As usual with MS documentation, you need to interpret it. ;-)

re:

adding the CodeBehind and Inherits attributes
and putting the .cs file in App_Code does work

Yup, but the explanation is nowhere to be found,
*except in that document*.

I, also, hate the idea of putting source code on a server.

I don't know who came up with that doozy, but they should
be hung by their you-know-whats for inflicting that on us.

I'm skipping that part entirely by manually compiling to assemblies
anything which would go into App_Code as raw code.

I see the App_Code directory as a security failpoint.

I'm not sure if there's any advantage any more to using
codebehind, anyway, particularly with global.asax.

If you can do anything with inline coding, or manually-compiled assemblies,
that you can do with codebehind, why should we have to go through the
additional contortions which codebehind requires ?

Do you know of anything which can be done in codebehind
which can't be done inline or with command-line compiled assemblies ?

I'm finding the codebehind model a bit hard to swallow these days
primarily because of the additional complexity which it requires,
and the usual explanation that it "separates UI from code" sounds,
increasingly, hollow.

I can separate UI from code with manually-compiled assemblies.



Juan T. Llibre
ASP.NET MVP
ASP.NET FAQ : http://asp.net.do/faq/
==========================

 

[Scott Allen]

If you can do anything with inline coding, or manually-compiled assemblies,
that you can do with codebehind, why should we have to go through the
additional contortions which codebehind requires ?

Do you know of anything which can be done in codebehind
which can't be done inline or with command-line compiled assemblies ?

I can't think of anything you can or can't do in one model that you
can do in the other.

I was sticking with code-behind based on the close-minded principal
that it was "the right way to do it".

The more I learned abouyt 2.0 the more I started liking inline code -
it's one less file to manage, one less file to "diff" ... etc. There
is no difference in productivity or tool support in 2.0!