Where do you store your code-behind files and user controls?

[Alan Silver]

Hello,

I am just looking at VWD and seeing what needs doing to take an existing
site I've written by hand and importing it into VWD. I've already
discovered that I need to rename my code-behind files to match the .aspx
file name so VWD will tie the two together, and I'm now wondering what
to do about the location of the code-behind files.

Is there any set convention for where the code-behind files live? I have
been putting them in the bin folder, with the thought that when the site
is ready to deploy, I would change the page attribute of the .aspx to
use a DLL instead of the actual .cs file. I would just need to compile
all the .cs files in the bin folder.

However, from my tests with VWD, it seems it puts the code behind file
in the same folder as the .aspx file. Is this sensible? Any other
comments on the issue?

The same question goes for user controls and their code-behind files. At
the moment, they are all in the bin folder, partly because I have been
thinking of them a little like include files in classic ASP, all of
which used to live in an include folder on my sites.

Any and all comments appreciated as usual ;-)

 

[Scott Allen]

However, from my tests with VWD, it seems it puts the code behind file
in the same folder as the .aspx file. Is this sensible? Any other
comments on the issue?

I think it's sensible. The two files are closely related. You wouldn't
want to change the attribute to point to a dll, always leave the
attribute pointing to the .cs file, the ASP.NET runtime will figure
everything out. You can always use precompilation if you don't want to
deploy source code.

The same question goes for user controls and their code-behind files. At
the moment, they are all in the bin folder, partly because I have been
thinking of them a little like include files in classic ASP, all of
which used to live in an include folder on my sites.

I'd leave the bin directory for "binaries". You could always make a
folder with a reasonable name like "controls" or "common" as a place
to keep user control file. It all depends on what purpose they server
for the site and how many you have..

HTH,

 

[Alan Silver]

However, from my tests with VWD, it seems it puts the code behind file

I think it's sensible. The two files are closely related. You wouldn't
want to change the attribute to point to a dll, always leave the
attribute pointing to the .cs file, the ASP.NET runtime will figure
everything out. You can always use precompilation if you don't want to
deploy source code.

OK, that's what I guessed would be the suggestion. Sounds good to me.

I'd leave the bin directory for "binaries". You could always make a
folder with a reasonable name like "controls" or "common" as a place
to keep user control file. It all depends on what purpose they server
for the site and how many you have..

Well, some of them are used specifically by one page, some by many
pages. I'm not sure that that really makes the difference though. I
always worked with the idea that "main" page files went in the folder
where they lived and any "include" files (I know, classic ASP ideas
still here) went into an includes folder. I suppose there's no real
logical basis for this.

HTH,

Sure does. Thanks very much

 

[PL]

You store the code in the folder App_code, there are a bunch of new folders
with ASP.NET 2.0, do a search on MSDN.

PL

 

[Alan Silver]

You store the code in the folder App_code, there are a bunch of new folders

with ASP.NET 2.0, do a search on MSDN.

I thought that App_code was for source files that the framework compiled
for you? I am talking about the code-behind files that are compiled
before you deploy. I am not putting source files on the server.

Or did I miss the point of App_code?

Thanks for the reply

 

[PL]

Ok, sorry, that's correct.

PL.

I thought that App_code was for source files that the framework compiled for you? I am talking about the code-behind files that
are compiled before you deploy. I am not putting source files on the server.

Or did I miss the point of App_code?

Thanks for the reply

 

[Juan T. Llibre]

re:

Or did I miss the point of App_code?

No, you did not.

re:

I am talking about the code-behind files that are compiled before you deploy. I am not
putting source files on the server.

I am scratching my head a little bit here.
You are compiling "code-behind" files which are *not* controls or classes ?

I.O.W., if you have page.aspx and page.aspx.cs,
you compile page.aspx.cs to an assembly and place it in the bin ?

What do you name the resulting assembly ?

And, then, you upload the page.aspx file and it works ?
What do the Page and Import Namespace directives for that page look like ?

I usually compile all my utility classes to an assembly, and place it in the bin
directory, but I then have to use an Import directive to call the namespace.

You store the code in the folder App_code, there are a bunch of new folders
with ASP.NET 2.0, do a search on MSDN.

I thought that App_code was for source files that the framework compiled for you? I am
talking about the code-behind files that are compiled before you deploy. I am not
putting source files on the server.

Or did I miss the point of App_code?

Thanks for the reply

 

[Alan Silver]

Or did I miss the point of App_code?

No, you did not.

Oh good, I got something right then!!

Judging by what you wrote below, I think I wasn't clear about what I was
asking. Having thought more about it, I decided that it wasn't really a
good question!! I have done all my ASP.NET development by hand so far,
and have developed sites with uncompiled code-behind files (ie using the
Src attribute of the page directive). As I am now nearing completion of
my first really major ASP.NET site, I had in mind to compile the
code-behind files for the pages into DLLs. I was still pondering where
to keep the source files (hence my question), when I realised that it's
irrelevant as the source files are (hopefully) never going to leave my
development machine. Where I keep them is purely up to me, or up to VWD
if it decides to store it somewhere specific.

Sorry to have thrown an eight-ball in there (I think that's what they
call it isn't it? I'm English and know little about these curious
American tribal rituals!!)

However, if you would like to look at the thread I started about my
problems trying to create an IIS-based site in VWD Express, I would be
very grateful. It seems to have come to a stop, and I'm nowhere nearer
an answer (except for a sneaking suspicion that it isn't going to work
with the Express edition)

Ta ra

I am talking about the code-behind files that are compiled before you
deploy. I am not
putting source files on the server.

I am scratching my head a little bit here.
You are compiling "code-behind" files which are *not* controls or classes ?

I.O.W., if you have page.aspx and page.aspx.cs,
you compile page.aspx.cs to an assembly and place it in the bin ?

What do you name the resulting assembly ?

And, then, you upload the page.aspx file and it works ?
What do the Page and Import Namespace directives for that page look like ?

I usually compile all my utility classes to an assembly, and place it
in the bin
directory, but I then have to use an Import directive to call the namespace.