Using code behind without a virtual directory?

[antonyliu2002]

I have a C# class GeneralUtilities.cs , which many of my aspx.cs files
will refer to. So, I've put it under the App_Code folder and compiled
it to library using csc /target: library from the DOS console.

I can use objects of type GeneralUtilities in any aspx.cs file in my
web application without any problem if only I make my web application
folder a virtual directory.

If I don't make it a virtual directory, the compiler complains about
GeneralUtilities type or namespace.

But, some other components of this web application refuse to work in a
virtual directory. It takes time to explain, so I will not delve into
this situation.

Right now, I am working around this by putting the GeneralUtilities
class in each single aspx.cs file and de-virtualize the web folder.
This works fine, but it is very tedious to have to put into each
aspx.cs file the same snippet of code, which should otherwise be well
shared from code-behind. It's gonna be even worse if I need to make
big changes to the GeneralUtilities class.

So, I am wondering if there is any way to share code behind without
virtualizing the web folder?

Thanks in advance.

[Jason Stearns]

Its not so much that its marked as a virtual directory, but that its an
application. In all practicality they are one in the same, but unless its
marked this way, IIS doesn't know to treat it as an application instead of a
subdirectory in the parent app. I would approach this problem from why your
app doesn't work as a virtual directory.

Is it because you have references to folders using "/foldername" and because
its not the root of the website the paths don't match up? If so this can be
fixed using ResolveUrl("~/foldername"), where "~/" is the application's root
directory not the website's.

Just a thought.

"an***********@yahoo.com" wrote:

I have a C# class GeneralUtilities.cs , which many of my aspx.cs files
will refer to. So, I've put it under the App_Code folder and compiled
it to library using csc /target: library from the DOS console.

I can use objects of type GeneralUtilities in any aspx.cs file in my
web application without any problem if only I make my web application
folder a virtual directory.

If I don't make it a virtual directory, the compiler complains about
GeneralUtilities type or namespace.

But, some other components of this web application refuse to work in a
virtual directory. It takes time to explain, so I will not delve into
this situation.

Right now, I am working around this by putting the GeneralUtilities
class in each single aspx.cs file and de-virtualize the web folder.
This works fine, but it is very tedious to have to put into each
aspx.cs file the same snippet of code, which should otherwise be well
shared from code-behind. It's gonna be even worse if I need to make
big changes to the GeneralUtilities class.

So, I am wondering if there is any way to share code behind without
virtualizing the web folder?

Thanks in advance.

[antonyliu2002]

Jason Stearns wrote:

Its not so much that its marked as a virtual directory, but that its an
application. In all practicality they are one in the same, but unless its
marked this way, IIS doesn't know to treat it as an application instead of a
subdirectory in the parent app. I would approach this problem from why your
app doesn't work as a virtual directory.

Is it because you have references to folders using "/foldername" and because
its not the root of the website the paths don't match up? If so this can be
fixed using ResolveUrl("~/foldername"), where "~/" is the application's root
directory not the website's.

Just a thought.

Thanks a lot. As a matter of fact, I would rather fix the problem why
some components of my web applicatin refuse to work in a virtual
directory.

OK, so, here is the story.

We are extending an old web application written in classic ASP. We
will write in ASP.NET. Our web users log into the web application from
the classic ASP application.

Then there is the ever-haunting problem of sharing sessions between the
classic ASP application and the ASP.NET application. (Damn Microsoft
which does not also release a bridging facility btwn the two the time
they released ASP.NET).

So, I googled and found this strategy:

http://www.eggheadcafe.com/articles/20021207.asp

and gave it a shot. It works great, but only if transferring the
session objects to the same folder or another folder that is not a web
application or virtual directory itself. Otherwise, the session
objects won't be delievered to the target ASPX page.

That is the problem.

So if there is a good strategy to share session objects between classic
ASP and ASP.NET applications, that would solve this problem.

It looks like the eggheadcafe strategy at the URL above will only
deliever session objects from a classic ASP page to an ASP.NET page
WITHIN the same application. If only it could do so BETWEEN a classic
ASP application and an ASP.NET application, it would also solve the
problem.

The only info we need from the ASP application is the user ID. I do
not think my boss would invest a few hundred bucks for some commercial
bridging package for this purpose.

Your continued help is highly appreciated.

[Jason Stearns]

It looks like the eggheadcafe strategy at the URL above will only

deliever session objects from a classic ASP page to an ASP.NET page
WITHIN the same application.

This part sounds correct because of the server.transfer he's using, but even
if you were ok with this you would still need bridging code for every file
that you need for the session variables. If you're going to do that, you
might as well upgrade the whole thing.

I've been in this boat before and the way i got through it was to just
upgrade my classic asp code to asp.net. you could just put each page into
compatability mode, AspCompat="true", so you just have to do the minimum to
upgrade each page.

Not sure there is any easy answer to this.

"an***********@yahoo.com" wrote:

>
Jason Stearns wrote:

Its not so much that its marked as a virtual directory, but that its an
application. In all practicality they are one in the same, but unless its
marked this way, IIS doesn't know to treat it as an application instead of a
subdirectory in the parent app. I would approach this problem from why your
app doesn't work as a virtual directory.

Is it because you have references to folders using "/foldername" and because
its not the root of the website the paths don't match up? If so this can be
fixed using ResolveUrl("~/foldername"), where "~/" is the application's root
directory not the website's.

Just a thought.

Thanks a lot. As a matter of fact, I would rather fix the problem why
some components of my web applicatin refuse to work in a virtual
directory.

OK, so, here is the story.

We are extending an old web application written in classic ASP. We
will write in ASP.NET. Our web users log into the web application from
the classic ASP application.

Then there is the ever-haunting problem of sharing sessions between the
classic ASP application and the ASP.NET application. (Damn Microsoft
which does not also release a bridging facility btwn the two the time
they released ASP.NET).

So, I googled and found this strategy:

http://www.eggheadcafe.com/articles/20021207.asp

and gave it a shot. It works great, but only if transferring the
session objects to the same folder or another folder that is not a web
application or virtual directory itself. Otherwise, the session
objects won't be delievered to the target ASPX page.

That is the problem.

So if there is a good strategy to share session objects between classic
ASP and ASP.NET applications, that would solve this problem.

It looks like the eggheadcafe strategy at the URL above will only
deliever session objects from a classic ASP page to an ASP.NET page
WITHIN the same application. If only it could do so BETWEEN a classic
ASP application and an ASP.NET application, it would also solve the
problem.

The only info we need from the ASP application is the user ID. I do
not think my boss would invest a few hundred bucks for some commercial
bridging package for this purpose.

Your continued help is highly appreciated.

[antonyliu2002]

Jason Stearns wrote:

It looks like the eggheadcafe strategy at the URL above will only
deliever session objects from a classic ASP page to an ASP.NET page
WITHIN the same application.

This part sounds correct because of the server.transfer he's using, but even
if you were ok with this you would still need bridging code for every file
that you need for the session variables. If you're going to do that, you
might as well upgrade the whole thing.

I've been in this boat before and the way i got through it was to just
upgrade my classic asp code to asp.net. you could just put each page into
compatability mode, AspCompat="true", so you just have to do the minimum to
upgrade each page.

Not sure there is any easy answer to this.

That sounds easy. But where do you put that directive
(AspCompat="true")? In the ASP.NET page? Will this trick demystify
the whole thing?

[Juan T. Llibre]

<%@ Page aspcompat=true %>

Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================
<an***********@yahoo.comwrote in message
news:11**********************@m7g2000cwm.googlegro ups.com...

>
Jason Stearns wrote:

It looks like the eggheadcafe strategy at the URL above will only
deliever session objects from a classic ASP page to an ASP.NET page
WITHIN the same application.

This part sounds correct because of the server.transfer he's using, but even
if you were ok with this you would still need bridging code for every file
that you need for the session variables. If you're going to do that, you
might as well upgrade the whole thing.

I've been in this boat before and the way i got through it was to just
upgrade my classic asp code to asp.net. you could just put each page into
compatability mode, AspCompat="true", so you just have to do the minimum to
upgrade each page.

Not sure there is any easy answer to this.

That sounds easy. But where do you put that directive
(AspCompat="true")? In the ASP.NET page? Will this trick demystify
the whole thing?

[Jason Stearns]

Sorry, yeah, it goes in the page directive. Intellisense should pick up on it
and help you out. However, this isn't the magic bullet either, you'll still
need to do some code upgrading.

check out this article, Scott Mitchell is an ASP/ASP.NET god.
http://www.4guysfromrolla.com/webtech/041601-1.shtml

"an***********@yahoo.com" wrote:

>
Jason Stearns wrote:

It looks like the eggheadcafe strategy at the URL above will only
deliever session objects from a classic ASP page to an ASP.NET page
WITHIN the same application.

This part sounds correct because of the server.transfer he's using, but even
if you were ok with this you would still need bridging code for every file
that you need for the session variables. If you're going to do that, you
might as well upgrade the whole thing.

I've been in this boat before and the way i got through it was to just
upgrade my classic asp code to asp.net. you could just put each page into
compatability mode, AspCompat="true", so you just have to do the minimum to
upgrade each page.

Not sure there is any easy answer to this.

That sounds easy. But where do you put that directive
(AspCompat="true")? In the ASP.NET page? Will this trick demystify
the whole thing?

[antonyliu2002]

Jason Stearns wrote:

Sorry, yeah, it goes in the page directive. Intellisense should pick up on it
and help you out. However, this isn't the magic bullet either, you'll still
need to do some code upgrading.

check out this article, Scott Mitchell is an ASP/ASP.NET god.
http://www.4guysfromrolla.com/webtech/041601-1.shtml

"an***********@yahoo.com" wrote:

Jason Stearns wrote:

It looks like the eggheadcafe strategy at the URL above will only
deliever session objects from a classic ASP page to an ASP.NET page
WITHIN the same application.
>
This part sounds correct because of the server.transfer he's using, but even
if you were ok with this you would still need bridging code for every file
that you need for the session variables. If you're going to do that, you
might as well upgrade the whole thing.
>
I've been in this boat before and the way i got through it was to just
upgrade my classic asp code to asp.net. you could just put each page into
compatability mode, AspCompat="true", so you just have to do the minimum to
upgrade each page.
>
Not sure there is any easy answer to this.

That sounds easy. But where do you put that directive
(AspCompat="true")? In the ASP.NET page? Will this trick demystify
the whole thing?

Hi, thanks. But I am not going to upgrade the entire classic ASP
application into ASP.NET. Really, at this moment, the only thing that
needs to be transferred from the ASP application to the ASP.NET
application is the user ID. So, all I need is

(1) Share sessions between classic ASP pages and ASP.NET pages, which
the eggheadcafe strategy does.

(2) In addition to (1), share sessions between two different
applications, which the eggheadcafe strategy does not.

I have problem (1) taken care of with the eggheadcafe trick, but not
sure how to shoot (2).

[antonyliu2002]

What I will do to solve this problem is to go up one level, such that I
will be working under the same application which is mix of both classic
ASP and ASP.NET pages.

This has been working fine. Good.

an***********@yahoo.com wrote:

Jason Stearns wrote:

Sorry, yeah, it goes in the page directive. Intellisense should pick up on it
and help you out. However, this isn't the magic bullet either, you'll still
need to do some code upgrading.

check out this article, Scott Mitchell is an ASP/ASP.NET god.
http://www.4guysfromrolla.com/webtech/041601-1.shtml

"an***********@yahoo.com" wrote:

>
Jason Stearns wrote:
It looks like the eggheadcafe strategy at the URL above will only
deliever session objects from a classic ASP page to an ASP.NET page
WITHIN the same application.

This part sounds correct because of the server.transfer he's using, but even
if you were ok with this you would still need bridging code for every file
that you need for the session variables. If you're going to do that, you
might as well upgrade the whole thing.

I've been in this boat before and the way i got through it was to just
upgrade my classic asp code to asp.net. you could just put each page into
compatability mode, AspCompat="true", so you just have to do the minimum to
upgrade each page.

Not sure there is any easy answer to this.
>
That sounds easy. But where do you put that directive
(AspCompat="true")? In the ASP.NET page? Will this trick demystify
the whole thing?
>

Hi, thanks. But I am not going to upgrade the entire classic ASP
application into ASP.NET. Really, at this moment, the only thing that
needs to be transferred from the ASP application to the ASP.NET
application is the user ID. So, all I need is

(1) Share sessions between classic ASP pages and ASP.NET pages, which
the eggheadcafe strategy does.

(2) In addition to (1), share sessions between two different
applications, which the eggheadcafe strategy does not.

I have problem (1) taken care of with the eggheadcafe trick, but not
sure how to shoot (2).

[antonyliu2002]

What I will do to solve this problem is to go up one level, such that I
will be working under the same application which is mix of both classic
ASP and ASP.NET pages.

This has been working fine. Good.

an***********@yahoo.com wrote:

Jason Stearns wrote:

Sorry, yeah, it goes in the page directive. Intellisense should pick up on it
and help you out. However, this isn't the magic bullet either, you'll still
need to do some code upgrading.

check out this article, Scott Mitchell is an ASP/ASP.NET god.
http://www.4guysfromrolla.com/webtech/041601-1.shtml

"an***********@yahoo.com" wrote:

>
Jason Stearns wrote:
It looks like the eggheadcafe strategy at the URL above will only
deliever session objects from a classic ASP page to an ASP.NET page
WITHIN the same application.

This part sounds correct because of the server.transfer he's using, but even
if you were ok with this you would still need bridging code for every file
that you need for the session variables. If you're going to do that, you
might as well upgrade the whole thing.

I've been in this boat before and the way i got through it was to just
upgrade my classic asp code to asp.net. you could just put each page into
compatability mode, AspCompat="true", so you just have to do the minimum to
upgrade each page.

Not sure there is any easy answer to this.
>
That sounds easy. But where do you put that directive
(AspCompat="true")? In the ASP.NET page? Will this trick demystify
the whole thing?
>

Hi, thanks. But I am not going to upgrade the entire classic ASP
application into ASP.NET. Really, at this moment, the only thing that
needs to be transferred from the ASP application to the ASP.NET
application is the user ID. So, all I need is

(1) Share sessions between classic ASP pages and ASP.NET pages, which
the eggheadcafe strategy does.

(2) In addition to (1), share sessions between two different
applications, which the eggheadcafe strategy does not.

I have problem (1) taken care of with the eggheadcafe trick, but not
sure how to shoot (2).