Re: ASP .NET 2.0 Unanswered questions...


"Juan T. Llibre" <nomailreplies@xxxxxxxxxxx> wrote in message
news:emUy8U2DIHA.1208@xxxxxxxxxxxxxxxxxxxxxxx
re:
!> Well, I think this is the heart of the issue. Let's just use some
!> rudimentary detective skills here. You rarely use code-behind (the VS
.NET
!> 2003 default) and get multiple assemblies. I never use them and always
get
!> single assemblies.

Did you miss the explanation in which I said that my app uses *both*
codebehind (for the admin pages) and inline code ( for most of the app ) ?

Not at all, but I believe that because you are using both, you aren't
getting the same effect as if you just were using straight code-behind.


re:
!> As I've said a couple of times, I believe that when you
!> use the inline model, you will get an assembly per page, but when you
use
!> code-behind you will get just one assembly for all the page classes.

Surely, you can't draw the conclusion that you are trying to draw from a
mixed model.

All I know is that you are the one saying that you get multiple assemblies
and you are also the one that hasn't used the straight code-behind model.
It seems reasonable to me that because your only examples use the inline
model that the inline model is the culprit.


If I were, in fact, only using inline code, you might have an argument
but,
since I I'm not, you are grasping at straws trying to justify your
postulates.

I'm not grasping at straws, I'm using simple reasoning.

I've said that inline will cause multiple assemblies. We all seem to be in
agreement on that. I've also said that straight code-behind will cause one
assembly. I've tried it (for about 5 years now) and you haven't and seem
unwilling to do so (why, I don't know). Who's grasping? The evidence you
provide for getting multiple assemblies seems to always have inline pages
involved in the mix. The evidence I provide for a single assembly never
involves inline pages - it seems reasonable to assume that the use of the
inline page model is the key here. I don't think there is anything biased
or far-fetched about coming to that conclusion.


re:
!> I think that because you have a mixed model, you are seeing the
multiple assemblies.

Are you saying that because there's some pages which use codebehind,
that the compiler will use the single-page-per-assembly mode for all pages
?

Perhaps, I don't know for sure, but it is not outside the realm of
possibility or even that far-fetched. It may be that the process is more
easily accomplished when only one assembly generation scheme is used, rather
than two and since inline pages *must* use the one assembly per page model,
that is the one that gets used (just a guess - in for a penny...in for a
pound, as they say).


That doesn't sound correct to me.

What I would expect, in that scenarion, is that all codebehind pages
would be compiled into a single assembly and the rest would be
compiled as single-assembly-per-page.

See above comments (process assemblies via 2 rules vs. one).

re:
!> How do you separate your programming logic from your presentation logic
in the inline model

I don't find it necessary to do that.
I understand that some programmers prefer that model, though.

What I do is compile classes into assemblies whose properties/methods I
can call from any page.
That's enough separation for me.

Again, fair enough (and that's why the inline model exists today). But, you
can't deny that nTier and MVC architectures are quite prevelant in
Enterprise development.


re:
!> Yes, but if we can clear this up, it's time (and keystrokes) well
spent.

I'll agree on that.

From my end all I can do is bump this up the programming food chain.
Maybe somebody in the ASP.NET Dev Team can shed light on this.

I would suggest (just for kicks) that you create a new ASP.NET 1.1 Project
in VS .NET 2003 (if you still have it installed) and just add a couple of
pages (no code is needed in those pages). Make sure that all the pages use
the code-behind model and check it out. Since I can attest to the two
behaviors based on the two different ways of creating the pages, but you've
not used the 100% code-behind scenario, you could see for yourself what I've
been describing. This would also confirm for you that what that article I
referenced is referring to is not an anomoly, it is the default architecture
for ASP .NET 1.1 sites built with VS .NET 2003






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/
======================================
"Scott M." <s-mar@xxxxxxxxxxxxx> wrote in message
news:OQym8l1DIHA.1204@xxxxxxxxxxxxxxxxxxxxxxx
Inline....


"Juan T. Llibre" <nomailreplies@xxxxxxxxxxx> wrote in message
news:umLcPX1DIHA.5328@xxxxxxxxxxxxxxxxxxxxxxx
re:
!> What happens if you build an app. using all code-behind pages and no
inline
!> pages AND you deploy the single IL assembly in the project/bin
folder?

I don't know because I seldom use codebehind.

Well, I think this is the heart of the issue. Let's just use some
rudimentary detective skills here. You rarely use code-behind (the VS
.NET 2003 default) and get multiple assemblies. I never use them and
always get single assemblies. As I've said a couple of times, I believe
that when you use the inline model, you will get an assembly per page,
but when you use code-behind you will get just one assembly for all the
page classes.

Here is an article I found that supports this (the code-behind model
anyway):
http://aspnetresources.com/articles/debug_code_in_production.aspx

In particular, this paragraph is of interest (and supports my position):

"The sample project, TestDebug, has two pages named test1.aspx and
test2.aspx. Note that every page is actually a class. The project itself
compiles executable code into a dll, TestDebug.dll. Quite naturally, we
expect to see both test1 and test2 classes inside this DLL."

This excerpt is discussing the temporary assembly, not the project/bin
assembly, just in case you missed it.

I had to be dragged into using codebehind in the admin pages
for the app while using inline code for most of the pages.

I think that because you have a mixed model, you are seeing the multiple
assemblies. As you state, you don't know what would happen when a 100%
code-behind model is followed.

I think that using codebehind is a waste of time, given that the code
in codebehind files has to be compiled twice before it can be used.

Fair enough, but I find the inline model just perpetuates the "spagehetti
code" of classic ASP and does us no good when wanting to separate the UI
from the buisness logic of our applications. In addition, it makes team
development more tricky. I'll never go back to an inline model if I can
help it.

AFAIK, there's nothing which can be done in codebehind which
can't be done inline, so why add unnecessary complexity to apps ?

How do you separate your programming logic from your presentation logic
in the inline model (saying that it's separated by the <SCRIPT> block at
the top of the page isn't going to be a sufficient answer to someone
seeking true nTier architecture). Does it add more complexity, I guess.
But, there are millions who find the separation of presentation markup
vs. programming code a benefit well worth the extra file.

Btw, we have really gone very far OT for this thread.
But, I suppose that's normal for programmers... :-)

Yes, but if we can clear this up, it's time (and keystrokes) well spent.
Not to mention, I don't think we've detracted from the OP as it seems to
have been answered (it was my OP after all!).


The thread originally concerned ASP.NET 2.0,
and we've been discussing ASP.NET 1.1 for quite a while.



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/
======================================
"Scott M." <s-mar@xxxxxxxxxxxxx> wrote in message
news:OLwplO1DIHA.4684@xxxxxxxxxxxxxxxxxxxxxxx

"Juan T. Llibre" <nomailreplies@xxxxxxxxxxx> wrote in message
news:uva%23T$0DIHA.5976@xxxxxxxxxxxxxxxxxxxxxxx
re:
!> this clears things up nicely

It doesn't for me. :-(

See my just sent-in reply, where I state that
the app uses both inline and codebehind pages.

I *still* wind up with an assembly for each page, in the ASP.NET temp
files dir,
even though the app uses the single-assembly per project model.

What happens if you build an app. using all code-behind pages and no
inline pages AND you deploy the single IL assembly in the project/bin
folder?









.

Relevant Pages

  • Re: ASP .NET 2.0 Unanswered questions...
    ... "I've also said that straight code-behind will cause one assembly" ... 2003 default) and get multiple assemblies. ... Did you miss the explanation in which I said that my app uses *both* ... use the inline model, you will get an assembly per page, but when you use ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: ASP .NET 2.0 Unanswered questions...
    ... I've said that inline will cause multiple assemblies. ... I've also said that straight code-behind will cause one assembly. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: ASP .NET 2.0 Unanswered questions...
    ... pages AND you deploy the single IL assembly in the project/bin folder? ... You rarely use code-behind (the VS .NET ... 2003 default) and get multiple assemblies. ... use the inline model, you will get an assembly per page, but when you use ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: ASP .NET 2.0 Unanswered questions...
    ... 2003 default) and get multiple assemblies. ... code-behind you will get just one assembly for all the page classes. ... How do you separate your programming logic from your presentation logic in the inline model ... What happens if you build an app. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: ASP .NET 2.0 Unanswered questions...
    ... What happens if you build an app. ... I don't know because I seldom use codebehind. ... for the app while using inline code for most of the pages. ... using all code-behind pages and no inline pages AND you deploy the single IL ...
    (microsoft.public.dotnet.framework.aspnet)