FP2003 and DWT requirements?

[Gerry Hickman]

I forgot to post this link; it explains the migration of Hotmail from
UNIX to Windows - quite interesting...

http://www.securityoffice.net/mssecrets/hotmail.html#_Toc491601845

 

[Thomas A. Rowe]

I will continue to use FP2000 for all development, and I have no plans to move to ASP.Net in the
near future. I do not see .NET as ruining anything, it is just another technology choice available
to those that want to learn and use it.

--
==============================================
Thomas A. Rowe (Microsoft MVP - FrontPage)
==============================================
If you feel your current issue is a results of installing
a Service Pack or security update, please contact
Microsoft Product Support Services:
http://support.microsoft.com
If the problem can be shown to have been caused by a
security update, then there is usually no charge for the call.
==============================================

 

[Jim Cheshire]

Hi Thomas,


Now we're talking!

I agree Classic ASP and Frontpage make an excellent development
system. It's a shame .NET has ruined this powerful, faster,
less-bloated, less-proprietary way of doing things.

Gerry,

You need to do some learning before you post things like this. Almost all
of your posts are baseless and about half are technically inaccurate.

From your statement above, I can safely conclude that you know next to
nothing about ASP.NET.

--
Jim Cheshire
JIMCO Software
http://www.jimcosoftware.com
http://www.jimcoaddins.com

The premiere add-in and software source
for Microsoft FrontPage.

 

[Gerry Hickman]

From your statement above, I can safely conclude that you know next to
nothing about ASP.NET.

Maybe you can enlighten us as to how to create ASP.NET application
within Frontpage, how to build DLLs in the /bin folder, and how to debug
them.

 

[Gerry Hickman]

I will continue to use FP2000 for all development, and I have no plans to move to ASP.Net in the
near future. I do not see .NET as ruining anything, it is just another technology choice available
to those that want to learn and use it.

It "ruins" the ability to use Frontpage as a "web development" system -
that's what we were talking about. The whole basis of the discussion was
whether "web authroing" = "web development". I explained the difference
in the context of Microsoft's current tool set.

 

[Jim Cheshire]

Maybe you can enlighten us as to how to create ASP.NET application
within Frontpage, how to build DLLs in the /bin folder, and how to
debug them.

There is no requirement for DLLs in order to develop ASP.NET applications.
If you choose, you can develop an entire ASP.NET application in FrontPage
quite easily. If you do opt for the code-behind model, FrontPage is even a
more logical choice because it has a great HTML designer and you can simply
write your code-behind in a text editor or VS.NET.

If you want to debug your applicaton, you have a ton of options. You can
use VS.NET if you've got it. If you don't, you can use the CLR debugger
which ships free with the .NET Framework SDK or you can use cordbg, a
command line debugger which also ships with the Framework. You can also use
Windbg and the SOS extension which are also free from Microsoft.

In the end, I can't enlighten you. You're going to have to do some study on
your own and enlighten yourself.

--
Jim Cheshire
JIMCO Software
http://www.jimcosoftware.com
http://www.jimcoaddins.com

The premiere add-in and software source
for Microsoft FrontPage.

 

[Thomas A. Rowe]

It doesn't ruin the use of FP as a development system. You need to use the best tools for the
project at hand. MS makes specific applications to help with ASP.net development.

--
==============================================
Thomas A. Rowe (Microsoft MVP - FrontPage)
==============================================
If you feel your current issue is a results of installing
a Service Pack or security update, please contact
Microsoft Product Support Services:
http://support.microsoft.com
If the problem can be shown to have been caused by a
security update, then there is usually no charge for the call.
==============================================

 

[Gerry Hickman]

Hi Thomas,

It doesn't ruin the use of FP as a development system. You need to use the best tools for the
project at hand. MS makes specific applications to help with ASP.net development.

That's right, but earlier you claimed that it made no difference whether
you were "authoring" or "developing", but now you explain there's a
"specific application" for the latter. Let's not forget Interdev either.

I don't think many web developers would agree with you that Frontpage is
suitable as a web developmenet application. It's true that traditional
ASP can be used with Frontpage, but this only really works in the
context of "interpreted pages" - a somewhat disparate "page by page" way
of working, and long since shunned by Microsoft as "last year's model".

I think your strategy of FP2000 with traditional ASP is a good one
though, there are certain advantages over .NET, but perhaps only for
smaller projects.

Full-blown web applications (prior to .NET) would tend to utilize a
"middle tier" of business logic, but this tier cannot be developed in
Frontpage - back then it was usually ATL/COM (or VB6 if you were a
beginner).

Some advantages of .NET over traditional ASP include:

1. Separation of the display layer from the code and business logic

The ASPX page only has the design and visual elements, all the actual
"code" is in a separate file, there's even a third file for resources,
but all these files are "grouped" together as a single "web form".

2. Use of XML configuration files which can easily be copied from one
application to the next.

3. Provision of VIEWSTATE, a bit like session management but for the
client end.

4. Ability to develop "custom controls" (including web controls) without
the need to understnad ATL/COM.

5. Session management is possible from Frontpage and ASP, but it's
totally streamlined and scalable in .NET

6. With .NET there are certain libraries that were not available under
traditional ASP. For example you can draw a graph and have it rendered
as a GIF.

But probably the main thing (most would argue) is that way certain types
of controls are abstracted from what's going on behind the scenes - e.g.
the DataGrid control, where you can populate with data from hetrogeneous
sources, filter and sort, with very little coding. Personally, I find
these things somewhat limited.

The bottom line is that Frontpage does not have a future in Microsoft's
vision of web development.

 

[Gerry Hickman]

Hi Jim,

There is no requirement for DLLs in order to develop ASP.NET applications.
If you choose, you can develop an entire ASP.NET application in FrontPage
quite easily. If you do opt for the code-behind model, FrontPage is even a
more logical choice because it has a great HTML designer and you can simply
write your code-behind in a text editor or VS.NET.

But this only works with the "interpreted" page by page model.
(Microsoft push JScript.NET for this).

Earlier you made it clear your interest was in the "enterprise" end of
the market, and that's not the model they use. Prior to .NET they used
ATL/COM/ISAPI, and now they use compiled .NET DLLs which have to be
"built" in the /bin folder of the web application, not to mention
setting up the project and web config files in the first place. There's
then the small matter of adding "references" to your project and getting
TYPELIB info for the intellisense. None of this works in Frontpage.

Forget all that, can you imagine people trying to add a web control to a
design view in Frontpage and having to remember all the syntax and
properties for it? Not to mention trying to customize it quickly and easily.

If you want to debug your applicaton, you have a ton of options. You can
use VS.NET if you've got it.

Well, we're discussing Frontpage here, if they've got VS.NET, they won't
be interested in this debate.

If you don't, you can use the CLR debugger
which ships free with the .NET Framework SDK or you can use cordbg, a
command line debugger which also ships with the Framework. You can also use
Windbg and the SOS extension which are also free from Microsoft.

Now we're into the realms of fantasy. Yes, they could use the command
line, but this goes against every Microsoft ethos in the book, and in
real life would be a totally absurd way of working. Can you imagine
building on the command line every time you adjust a code-behind page in
Frontpage, and then fire up the command line debugger, attach to the
process, and then what! I also have to wonder if this works over
HTTP/1.1, as this was the whole premise of this debate in the first
place - my guess is that it does not.

It's still an interesting idea; I'd like to know if you've actually
tried this way of working on a big web project?

 

[Jim Cheshire]

But this only works with the "interpreted" page by page model.
(Microsoft push JScript.NET for this).

Not true at all. You can use two different methods for this:

1. Compile on demand
2. Inline code

In the case of compile on demand, you still use the code-behind model, but
you specific a src file in the @Page directive. When the page is browsed,
the page compiles into a dynamic assembly and executes from there.

In the case of inline code, the ASP.NET code is embedded in the page inside
of a <script> block with a runat attribute set to "server". When the page
is browsed, it is compiled into a dynamic assembly and executed from there.

In both of the above, you can use the CLR Debugger (a robust debugger with
many of the same features as VS.NET) or CorDbg to debug it.

There are drawbacks to developing in this manner, primarily that you don't
get the benefit of batch compilation. If you have a lot of pages, it can
also cause memory fragmentation which can lead to OutOfMemory exceptions in
cases of a very large application. However, for many developers, using this
method is a very real scenario and I run into people every day who are doing
it.

--
Jim Cheshire
JIMCO Software
http://www.jimcosoftware.com
http://www.jimcoaddins.com

The premiere add-in and software source
for Microsoft FrontPage.

 

[Thomas A. Rowe]

It still makes no difference.

--
==============================================
Thomas A. Rowe (Microsoft MVP - FrontPage)
==============================================
If you feel your current issue is a results of installing
a Service Pack or security update, please contact
Microsoft Product Support Services:
http://support.microsoft.com
If the problem can be shown to have been caused by a
security update, then there is usually no charge for the call.
==============================================

 

[Gerry Hickman]

Hi Jim,

Not true at all. You can use two different methods for this:

1. Compile on demand
2. Inline code

In the case of compile on demand, you still use the code-behind model, but
you specific a src file in the @Page directive. When the page is browsed,
the page compiles into a dynamic assembly and executes from there.

Yes, "page by page" as I explained above. This is not a "web
application" and anyway compiling page by page is too slow.

In the case of inline code, the ASP.NET code is embedded in the page inside
of a <script> block with a runat attribute set to "server". When the page
is browsed, it is compiled into a dynamic assembly and executed from there.

Sounds like page by page to me, and defeats the whole point of .NET
being able to create a centralized assembly for the whole app.

In both of the above, you can use the CLR Debugger (a robust debugger with
many of the same features as VS.NET) or CorDbg to debug it.

Yes, if you've got hours to waste, and don't mind having to keep jumping
in and out of Frontpage every time you make some code changes. I also
could not work out how to get these debuggers to attach to remote IIS
over DCOM (like wot u can do with VS.NET), it's not much use for
distributed and "enterprise" apps if you can't get it to work on
distributed systems?

There are drawbacks to developing in this manner, primarily that you don't
get the benefit of batch compilation.
Yes.

If you have a lot of pages, it can
also cause memory fragmentation which can lead to OutOfMemory exceptions in
cases of a very large application. However, for many developers, using this
method is a very real scenario and I run into people every day who are doing
it.

I'd like to stand behind them while they're "doing it", and see how they
get on, especially in the context of "enterprise web applications",
which is what the discussion was about.

However, it's important not to be negative about these ideas, because if
Frontpage really can be an enterprise web development tool, it would be
a good alternative to Visual Studio for those who are not on volume
licensing or larger budgets.

 

[Gerry Hickman]

Hi Thomas,

It still makes no difference.

Well, I've explained in detail why it does, so feel free to reply in-
line explaining the parts that you feel are incorrect, or just read up
on Microsoft's .NET intro pages to see how and why their .NET vision
does not fit with Frontpage for web application development.

 

[Gerry Hickman]

That's interesting about Windows update being the busiest. I hadn't
really thought about it (as you say it's not a traditional .com site).

After further consideration, I'm not convinced Windows Update is the
"busiest" site (what ever that's supposed to mean). If we're talking
serviced HTTP requests, then my guess is that Google would be busier,
otherwise it means nearly every person in every office in the world is
checking Windows Update every 20 minutes or so!

If we're talking "bytes transferred", then Windows Update would probably
transfer more than Google, that's because

a) Windows is so full of holes it needs patching all the time
b) Google is very efficient, whereas Microsoft is bloatsville

However, most of these transfers are done by BITS as opposed to HTTP,
and probably from a separate server, so it's hardly a good example of a
busy web server.

Microsoft's web site _is_ a good example of a big big site running on
pure Windows, and it's slowness shows that Windows is not a very good
platform for the web. Google services far more requests than Microsoft,
and yet their pages appear INSTANTLY with no lag at all.

Microsoft's search facility is also inferior to Google's even when
searching the Microsoft site itself, and that's CRAZY!

The things that's confusing me though, is why Google are running Linux
as opposed to FreeBSD or Solaris?

 

[Jim Cheshire]

Hi Jim,



Yes, "page by page" as I explained above. This is not a "web
application" and anyway compiling page by page is too slow.


Sounds like page by page to me, and defeats the whole point of .NET
being able to create a centralized assembly for the whole app.

Gerry,

In fact, this is the default setting in the next version of Visual Studio
..NET. Most developers inside of Microsoft prefer the inline code model to
the code-behind model. Your "centralized assembly" is merely a compilation
of the IL code. When the application runs (assuming batching is enabled),
you don't run from one assembly.

--
Jim Cheshire
JIMCO Software
http://www.jimcosoftware.com
http://www.jimcoaddins.com

The premiere add-in and software source
for Microsoft FrontPage.

 

[Jim Cheshire]

After further consideration, I'm not convinced Windows Update is the
"busiest" site (what ever that's supposed to mean). If we're talking
serviced HTTP requests, then my guess is that Google would be busier,
otherwise it means nearly every person in every office in the world is
checking Windows Update every 20 minutes or so!

Gerry,

Your problem is that you base everything off of "guessing" at things. My
comment was based on real data. I assure you that Microsoft keeps very
close tabs of this kind of thing.

Real statistics (as opposed to guesses) show that Microsoft's sites are more
reliable than Google (though not by much) and that they push more bandwidth
faster than Google.

So much for your guess.

--
Jim Cheshire
JIMCO Software
http://www.jimcosoftware.com
http://www.jimcoaddins.com

The premiere add-in and software source
for Microsoft FrontPage.

 

[Gerry Hickman]

Your problem is that you base everything off of "guessing" at things. My
comment was based on real data.

You have not backed up your claim with ANYTHING. Where is this "real
data". I suggest it's a fabrication, and anyone who works on big web
sites will see your claim does not make any sense.

 

[Gerry Hickman]

In fact, this is the default setting in the next version of Visual Studio
.NET. Most developers inside of Microsoft prefer the inline code model to
the code-behind model. Your "centralized assembly" is merely a compilation
of the IL code. When the application runs (assuming batching is enabled),
you don't run from one assembly.

This will be interesting to see then. "Back to ASP", LOL!

As long as the compile time is quick, and provisions are made for
managing state, it could be a good thing. Unfortunately, Frontpage will
still not be a suitable client app from which to develop .NET 2.0
applications.

 

[Jim Cheshire]

You have not backed up your claim with ANYTHING. Where is this "real
data". I suggest it's a fabrication, and anyone who works on big web
sites will see your claim does not make any sense.

I backed it up straight from the source. I also have considerable
experience in working with the world's largest corporations on difficult
ASP.NET issues with scalability, performance, etc.

Here's a tip for you. If you want to learn something, listen to those who
have more experience than you do rather than clinging to your own
suppositions at all costs.

--
Jim Cheshire
JIMCO Software
http://www.jimcosoftware.com
http://www.jimcoaddins.com

The premiere add-in and software source
for Microsoft FrontPage.

 

[Jim Cheshire]

This will be interesting to see then. "Back to ASP", LOL!

As long as the compile time is quick, and provisions are made for
managing state, it could be a good thing. Unfortunately, Frontpage
will still not be a suitable client app from which to develop .NET 2.0
applications.

Provisions made for managing state!?

As for FP not being a suitable application, I suspect (based upon your other
comments in this post and in others) that you know next to nothing about the
architecture of ASP.NET, so I wouldn't consider you a valid source for that.

--
Jim Cheshire
JIMCO Software
http://www.jimcosoftware.com
http://www.jimcoaddins.com

The premiere add-in and software source
for Microsoft FrontPage.