By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,197 Members | 1,173 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,197 IT Pros & Developers. It's quick & easy.

DLL vs. no DLL

P: n/a
I am a total newbie to the .NET web development arena and have a basic
question. I have inherited a .NET web application, written with C# in
code-behind pages. The way that the application currently works involves
having the various .aspx pages up on the server together with a single
compiled DLL that I assume contains the compiled version of all of the
code-behind files for all of the pages together with whatever else. The
problem I'm having is that, by looking at the server, I have no idea what
the actual code behind the pages is since it's all compiled into the DLL.
So, though I know it must be a slight performance hit, I'm thinking it would
be nice to be able to put the .cs files up on the server, together with the
..aspx files, and then, if I need to change a .cs file, I can do so and
simply put the new file up on the server and be done with it. Then, I would
guess, the first time the page is accessed, the server would have to compile
the new .cs (can it even do this?).

There are really two issues I'm trying to address here:
1) I want to be able to know for sure, by just looking at code files on the
server, what code is behind the pages.
2) I want to be able to change a single .cs file and put the changes up on
the server without needing to recompile and distribute a single DLL. This
way, I can be sure I didn't inadvertently introduce unwanted changes
elsewhere into the DLL (e.g. may have changed another page's code). In this
way, I could easily isolate the changes I'm pushing up to the server.

I'm certainly welcome to hearing about what I'm missing, if anything, here.
Any input would be greatly appreciated.
Nov 19 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
UPDATE: Well, I figured out a way to be able to debug .aspx pages even when
start page is a .asp page. I specify a generic page as the start page and
"run" the application. Then, when the browser opens to the generic page, I
simply go up and change the URL to point to the default.asp page and press
Enter. Then, when I later attempt to go to .aspx pages, I can trace through
them! This is an acceptable solution for me and I'm imagining that it's the
best I can hope for. However, if there is a way to set the default.asp page
as the startup page, I would be curious to know how.

"BobRoyAce" <bo*@omegasoftwareinc.com> wrote in message
news:0u********************@comcast.com...
I am a total newbie to the .NET web development arena and have a basic
question. I have inherited a .NET web application, written with C# in
code-behind pages. The way that the application currently works involves
having the various .aspx pages up on the server together with a single
compiled DLL that I assume contains the compiled version of all of the
code-behind files for all of the pages together with whatever else. The
problem I'm having is that, by looking at the server, I have no idea what
the actual code behind the pages is since it's all compiled into the DLL.
So, though I know it must be a slight performance hit, I'm thinking it
would be nice to be able to put the .cs files up on the server, together
with the .aspx files, and then, if I need to change a .cs file, I can do so
and simply put the new file up on the server and be done with it. Then, I
would guess, the first time the page is accessed, the server would have to
compile the new .cs (can it even do this?).

There are really two issues I'm trying to address here:
1) I want to be able to know for sure, by just looking at code files on
the server, what code is behind the pages.
2) I want to be able to change a single .cs file and put the changes up on
the server without needing to recompile and distribute a single DLL. This
way, I can be sure I didn't inadvertently introduce unwanted changes
elsewhere into the DLL (e.g. may have changed another page's code). In
this way, I could easily isolate the changes I'm pushing up to the server.

I'm certainly welcome to hearing about what I'm missing, if anything,
here. Any input would be greatly appreciated.

Nov 19 '05 #2

P: n/a
Asp.net can't compile code-behind files. You need VisualStudio for that.
Asp.net can compile aspx pages including c# scripts in the way you want -
you just change a page and it will be compiled next time. it is requested.

Eliyahu

"BobRoyAce" <bo*@omegasoftwareinc.com> wrote in message
news:0u********************@comcast.com...
I am a total newbie to the .NET web development arena and have a basic
question. I have inherited a .NET web application, written with C# in
code-behind pages. The way that the application currently works involves
having the various .aspx pages up on the server together with a single
compiled DLL that I assume contains the compiled version of all of the
code-behind files for all of the pages together with whatever else. The
problem I'm having is that, by looking at the server, I have no idea what
the actual code behind the pages is since it's all compiled into the DLL.
So, though I know it must be a slight performance hit, I'm thinking it would be nice to be able to put the .cs files up on the server, together with the .aspx files, and then, if I need to change a .cs file, I can do so and
simply put the new file up on the server and be done with it. Then, I would guess, the first time the page is accessed, the server would have to compile the new .cs (can it even do this?).

There are really two issues I'm trying to address here:
1) I want to be able to know for sure, by just looking at code files on the server, what code is behind the pages.
2) I want to be able to change a single .cs file and put the changes up on
the server without needing to recompile and distribute a single DLL. This
way, I can be sure I didn't inadvertently introduce unwanted changes
elsewhere into the DLL (e.g. may have changed another page's code). In this way, I could easily isolate the changes I'm pushing up to the server.

I'm certainly welcome to hearing about what I'm missing, if anything, here. Any input would be greatly appreciated.

Nov 19 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.