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 ;-)
--
Alan Silver
(anything added below this line is nothing to do with me) 7 2843
On Wed, 2 Nov 2005 15:14:58 +0000, Alan Silver
<al*********@nospam.thanx> wrote: 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,
--
Scott http://www.OdeToCode.com/blogs/scott/
>>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.
OK, that's what I guessed would be the suggestion. Sounds good to me. 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..
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
--
Alan Silver
(anything added below this line is nothing to do with me)
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" <al*********@nospam.thanx> skrev i meddelandet news:zI**************@nospamthankyou.spam... 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 ;-)
-- Alan Silver (anything added below this line is nothing to do with me)
>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" <al*********@nospam.thanx> skrev i meddelandet news:zI**************@nospamthankyou.spam... 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 ;-)
-- Alan Silver (anything added below this line is nothing to do with me)
--
Alan Silver
(anything added below this line is nothing to do with me)
Ok, sorry, that's correct.
PL.
"Alan Silver" <al*********@nospam.thanx> skrev i meddelandet news:oq**************@nospamthankyou.spam... 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
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.
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/
======================================
"Alan Silver" <al*********@nospam.thanx> wrote in message
news:oq**************@nospamthankyou.spam... 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" <al*********@nospam.thanx> skrev i meddelandet news:zI**************@nospamthankyou.spam... 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 ;-)
-- Alan Silver (anything added below this line is nothing to do with me)
-- Alan Silver (anything added below this line is nothing to do with me)
>> 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.
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/ ====================================== "Alan Silver" <al*********@nospam.thanx> wrote in message news:oq**************@nospamthankyou.spam... >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" <al*********@nospam.thanx> skrev i meddelandet news:zI**************@nospamthankyou.spam... 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 ;-)
-- Alan Silver (anything added below this line is nothing to do with me)
-- Alan Silver (anything added below this line is nothing to do with me)
--
Alan Silver
(anything added below this line is nothing to do with me) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Wayne Wengert |
last post by:
In VB6 I used to put Public variables, functions and Subs in a BAS Module.
What is the best way to handle this in .NET? From what I see in some books
it looks like I should use a Class Library but...
|
by: Jonas Rundberg |
last post by:
Hi
I just started with c++ and I'm a little bit confused where stuff
go...
Assume we have a class:
class test {
private:
int arr;
};
|
by: Nikola |
last post by:
compiler says: function undeclared how come???
help!
#include<stdio.h>
#include<stdlib.h>
#include<time.h>
struct lista{
int element;
struct lista *next;
}*pocetak;
|
by: ad |
last post by:
We usually store the connection string of Web Applicaiton in Web.Config.
Now I want to develop WinForm Application.
Where is the better place to store the conneciton string?
|
by: Rob |
last post by:
Where is the best place to store database connection info in a vb.net
program ? I do not want to "hard-code" a database name into my program.
Where could I store and retrieve that information ? ...
|
by: rdemyan via AccessMonster.com |
last post by:
I'm trying to implement a licensing scheme. There are three types of
licenses:
Trial - good for 30 to 60 days
Interim - good for 1 year
Fully Paid - no expiration
Everything is working fine...
|
by: Ranginald |
last post by:
Hi,
I am generally new to OOP and in learning and writing code I have
developed many of my own reusable methods.
A. What is the best way to store these methods for easy reuse later?
I was...
|
by: Merk |
last post by:
I'm looking for a safe and maintainable way to store connection string info
(connecting to SQL Server 2005 from .NET 2.0 Windows Forms client app);
things like server name or IP address and...
|
by: Swinky |
last post by:
Mr. Browne's copy code on his web site has saved me. I have been
struggling to copy a record with several related sub-form tables. I
found code on his web site that copies a sub-form table,...
|
by: junky_fellow |
last post by:
Guys,
Consider the following snippet of code:
int main(VOID)
{
static ushort fractionalValue={
0, 100, 200, 300, 400, 500, 600, 700, 800, 900,
250, 333, 666, 750, 0, 0
};
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: Mushico |
last post by:
How to calculate date of retirement from date of birth
|
by: DJRhino |
last post by:
Was curious if anyone else was having this same issue or not....
I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 4 Oct 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: Aliciasmith |
last post by:
In an age dominated by smartphones, having a mobile app for your business is no longer an option; it's a necessity. Whether you're a startup or an established enterprise, finding the right mobile app...
|
by: giovanniandrean |
last post by:
The energy model is structured as follows and uses excel sheets to give input data:
1-Utility.py contains all the functions needed to calculate the variables and other minor things (mentions...
|
by: NeoPa |
last post by:
Hello everyone.
I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report).
I know it can be done by selecting :...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be focusing on the Report (clsReport) class. This simply handles making the calling Form invisible until all of the Reports opened by it have been closed, when it...
| |