ASP .NET 2.0 Unanswered questions...

[Scott M.]

Yes, this would be in scenarios where you just deploy your pages (.aspx),
but no assembly. This is what folks who don't use the code-behind model
would experience. But, I was clear in my earlier posts that this is *not*
the scenario I was referring to.

 

[Rory Becker]

Yes, this would be in scenarios where you just deploy your pages

(.aspx), but no assembly. This is what folks who don't use the
code-behind model would experience. But, I was clear in my earlier
posts that this is *not* the scenario I was referring to.

Thanks very much Scott, this clears things up nicely (in my head at least).

I think I had missed somehow the first couple of posts between yourself and
Juan.

I at least have learned something here so thanks for that ( to you and everybody
else)

I hope everyone else finds what they're looking for

 

[Juan T. Llibre]

re:
!>I guess so. I have lots of books that have incorrect information in them.

It's just that there were 6 authors, 10 technical reviewers, an editorial review board and a
technical lead for the last book...on the most acclaimed ASP.NET book publisher of all : Wrox.

That something that basic would have escaped all of us, doesn't make sense.



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.]

I can't change the experience I've had with VS 2003 and the 1.1 Framework
Juan.

I have always found that the assemblies are generated just as I have
described. How hard you worked on your book doesn't change that.

 

[Juan T. Llibre]

re:
!> Bruce has insisted that even when you do use a compiled assembly,
!> you'll still get one per page - which I don't think is correct.

Bruce isn't the only one saying that. I am saying it, too.

For a moment I thought that maybe whether codebehind was used, or not,
would be the key difference, but the 1.1 app I'm using has both inline code
pages and codebehind pages...and still has one assembly per page in the
ASP.NET temp files directory.

The app is compiled previous to deployment, as are all VS 2003-compiled apps.

I should add that the app was written using ASP.NET "best practices",
and that a senior member of Microsoft's ASP.NET Development Team
( the team that wrote ASP.NET ) participated in the application's architecture
and programming.

Are you using the .Net Framework 1.1' SP1 and the Security update for SP1 ?




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/
======================================

 

[Juan T. Llibre]

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.




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/
======================================

 

[Juan T. Llibre]

re:
!> I have always found that the assemblies are generated just as I have described.

Right. I can say the same thing.

All that needs to be accounted for is why I wind up with an assembly
per page in the ASP.NET temp files directory...while you don't.




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/
======================================

 

[Rory Becker]

For a moment I thought that maybe whether codebehind was used, or not,

would be the key difference, but the 1.1 app I'm using has both inline
code pages and codebehind pages...and still has one assembly per page
in the ASP.NET temp files directory.

I had also thought that this might be the key difference. I have not been
involved in many different projects but have been involved in a particular
project since ASP.Net 1.0

One (possibly strange) thing that we have done.... We do not use "Any" Code-inline.
Which is to say that all our code is in the codebehind files.

This may be different to what you have done and might possibly explain the
difference.

If not... I would be interested to see the simplest possible example of a
webapp which exhibits the behaviour you describe.

Thanks

 

[Scott M.]

Are you using the .Net Framework 1.1' SP1 and the Security update for SP1

?

VS 2003 1.1 SP1 fully updated and patched. But, I experienced the same
behavior from day one of VS .NET 2003.

 

[Scott M.]

One (possibly strange) thing that we have done.... We do not use "Any"

Code-inline. Which is to say that all our code is in the codebehind files.

This may be different to what you have done and might possibly explain the
difference.

The same is true for me Rory. I never use the inline model - always
code-behind.

 

[Scott M.]

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?

 

[Mark Rae [MVP]]

All that needs to be accounted for is why I wind up with an assembly
per page in the ASP.NET temp files directory...while you don't.

FWIW, I've been watching this thread with interest, and still can't find any
way to create a web application (with no additional referenced assemblies)
containing more than one aspx page which produces anything other than one
DLL...

There must be some setting somewhere...

There's no other way I can think of where several very experienced people
whose opinion I respect can disagree totally on something which, as you
rightly point out, is about as fundamental as it gets...

 

[Juan T. Llibre]

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.

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 using codebehind is a waste of time, given that the code
in codebehind files has to be compiled twice before it can be used.

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

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

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/
======================================

 

[Juan T. Llibre]

re:
!> There's no other way I can think of where several very experienced people
!> whose opinion I respect can disagree totally on something

Well, we're not actually disagreeing.
We're just reporting different experiences.



re:
!> is about as fundamental as it gets...

It sure is.

re:
!> There must be some setting somewhere...

I don't recall setting anything which would change the compilation model.





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/
======================================

 

[Rory Becker]

!> 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.

I think we have our answer here.

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

At runtime sure. but at design time I find that it helps to seperate the
markup and the code.

Also we distribute our code and it was suggested (before the whole ease of
decompilation of IL was discovered) that we didn't want to give our source
code away as it would have been is laid bare in the Aspx files.

Also how is code sharable between pages when there is no code behind?

Are you seriously telling me that all your pages are that different?

 

[Rory Becker]

Also we distribute our codeI should have said we distribute our binaries

 

[Scott M.]

Inline....

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!).

 

[Juan T. Llibre]

re:
!> Also how is code sharable between pages when there is no code behind?

I compile classes into assemblies. I can call their methods/properties from any page.
It seems much more efficient, to me, to do it that way.

I can reuse the assemblies in other apps, too.

re:

Are you seriously telling me that all your pages are that different?

See above.



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/
======================================

 

[Juan T. Llibre]

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 ) ?

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.

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.

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 ?

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.

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.

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.




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.]

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