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

Maintaining ASP.NET Sites

P: n/a
They say it's easier, but has anyone tried
maintaining an ASP.NET site without the
source code of the dlls? This was not a problem
with classic ASP, all the code was almost always
just in text files, easily viewable and most importantly
readily AVAILABLE on the site, to anyone access to
the site's folder.

But just imagine, bunch of companies out there, managed
by non-technical people, who have had a bunch of outside
developers doing work on their site. At the
end of the day, they have several dlls sitting in the bin folder,
and no source code or project files available. Now you're a new
developer hired to fix bugs and extend the site. How do you
maintain these sites now without the source code of the codebehind
files? How do you understand them? Yes, you can add to it, yes even
extend the classes. But how do you fix bugs in the dlls without the
source code??? How do you even understand what the code does
exactly without the source code??? It's a nightmare!

In this respect I think classic ASP is way superior to ASP.NET.
Jan 13 '06 #1
Share this Question
Share on Google+
27 Replies


P: n/a
The new developer that gets hired gets the source code that is left by the
outsourced developers. Those outsourced developers would be required to
provide the source code to the DLLs, and the non-technical people would be
in posession of this code when the old developers left the project. Thus,
the new develop would receive the source code and go from there.

I don't understand why you wouldn't have the source code??

And by the way, you can code in ASP.NET exactly like you did in ASP. You
don't have to use codebehind. You can have 100% of the code in the .aspx
files, and no DLLs whatsoever.

Maybe you should do your research before declaring ASP superior...

"Raymond" <no*****@33.net> wrote in message news:3jSxf.37$MG1.28@trnddc05...
They say it's easier, but has anyone tried
maintaining an ASP.NET site without the
source code of the dlls? This was not a problem
with classic ASP, all the code was almost always
just in text files, easily viewable and most importantly
readily AVAILABLE on the site, to anyone access to
the site's folder.

But just imagine, bunch of companies out there, managed
by non-technical people, who have had a bunch of outside
developers doing work on their site. At the
end of the day, they have several dlls sitting in the bin folder,
and no source code or project files available. Now you're a new
developer hired to fix bugs and extend the site. How do you
maintain these sites now without the source code of the codebehind
files? How do you understand them? Yes, you can add to it, yes even
extend the classes. But how do you fix bugs in the dlls without the
source code??? How do you even understand what the code does
exactly without the source code??? It's a nightmare!

In this respect I think classic ASP is way superior to ASP.NET.

Jan 13 '06 #2

P: n/a
not having source code is an option with asp.net. turn off dll support on
your asp.net servers, and the source code will be required.

-- brcue (sqlwork.com)
"Raymond" <no*****@33.net> wrote in message news:3jSxf.37$MG1.28@trnddc05...
They say it's easier, but has anyone tried
maintaining an ASP.NET site without the
source code of the dlls? This was not a problem
with classic ASP, all the code was almost always
just in text files, easily viewable and most importantly
readily AVAILABLE on the site, to anyone access to
the site's folder.

But just imagine, bunch of companies out there, managed
by non-technical people, who have had a bunch of outside
developers doing work on their site. At the
end of the day, they have several dlls sitting in the bin folder,
and no source code or project files available. Now you're a new
developer hired to fix bugs and extend the site. How do you
maintain these sites now without the source code of the codebehind
files? How do you understand them? Yes, you can add to it, yes even
extend the classes. But how do you fix bugs in the dlls without the
source code??? How do you even understand what the code does
exactly without the source code??? It's a nightmare!

In this respect I think classic ASP is way superior to ASP.NET.

Jan 13 '06 #3

P: n/a

That's very nice in theory, but I'm afraid that in the real world
it often doesn't work that way. The source code is often
not available to new developers for one reason or another.

"Marina" <so*****@nospam.com> wrote in message
news:ue*************@tk2msftngp13.phx.gbl...
The new developer that gets hired gets the source code that is left by the
outsourced developers. Those outsourced developers would be required to
provide the source code to the DLLs, and the non-technical people would be
in posession of this code when the old developers left the project. Thus,
the new develop would receive the source code and go from there.

I don't understand why you wouldn't have the source code??

And by the way, you can code in ASP.NET exactly like you did in ASP. You
don't have to use codebehind. You can have 100% of the code in the .aspx
files, and no DLLs whatsoever.

Maybe you should do your research before declaring ASP superior...

"Raymond" <no*****@33.net> wrote in message

news:3jSxf.37$MG1.28@trnddc05...
They say it's easier, but has anyone tried
maintaining an ASP.NET site without the
source code of the dlls? This was not a problem
with classic ASP, all the code was almost always
just in text files, easily viewable and most importantly
readily AVAILABLE on the site, to anyone access to
the site's folder.

But just imagine, bunch of companies out there, managed
by non-technical people, who have had a bunch of outside
developers doing work on their site. At the
end of the day, they have several dlls sitting in the bin folder,
and no source code or project files available. Now you're a new
developer hired to fix bugs and extend the site. How do you
maintain these sites now without the source code of the codebehind
files? How do you understand them? Yes, you can add to it, yes even
extend the classes. But how do you fix bugs in the dlls without the
source code??? How do you even understand what the code does
exactly without the source code??? It's a nightmare!

In this respect I think classic ASP is way superior to ASP.NET.


Jan 13 '06 #4

P: n/a
Too late, you're the NEW developer. Dlls
have already been made and deployed into
the site. Now you have to fix bugs in them
without any source code. What do you do?
"Bruce Barker" <br******************@safeco.com> wrote in message
news:Oh**************@TK2MSFTNGP10.phx.gbl...
not having source code is an option with asp.net. turn off dll support on
your asp.net servers, and the source code will be required.

-- brcue (sqlwork.com)
"Raymond" <no*****@33.net> wrote in message

news:3jSxf.37$MG1.28@trnddc05...
They say it's easier, but has anyone tried
maintaining an ASP.NET site without the
source code of the dlls? This was not a problem
with classic ASP, all the code was almost always
just in text files, easily viewable and most importantly
readily AVAILABLE on the site, to anyone access to
the site's folder.

But just imagine, bunch of companies out there, managed
by non-technical people, who have had a bunch of outside
developers doing work on their site. At the
end of the day, they have several dlls sitting in the bin folder,
and no source code or project files available. Now you're a new
developer hired to fix bugs and extend the site. How do you
maintain these sites now without the source code of the codebehind
files? How do you understand them? Yes, you can add to it, yes even
extend the classes. But how do you fix bugs in the dlls without the
source code??? How do you even understand what the code does
exactly without the source code??? It's a nightmare!

In this respect I think classic ASP is way superior to ASP.NET.


Jan 13 '06 #5

P: n/a
An ASP application goes very easy to a complete mess...
Having source code with the page code is a thing that is being avoided in
many plataforms on these days, MVC is an attempt to improve this.
If you really can't access the source code and really need to change it, you
can do a "prohibited" operation, but that solves your problem if the DLL is
not obsfucated.
The key word in google is: Reflector

"Raymond" <no*****@33.net> wrote in message news:3jSxf.37$MG1.28@trnddc05...
They say it's easier, but has anyone tried
maintaining an ASP.NET site without the
source code of the dlls? This was not a problem
with classic ASP, all the code was almost always
just in text files, easily viewable and most importantly
readily AVAILABLE on the site, to anyone access to
the site's folder.

But just imagine, bunch of companies out there, managed
by non-technical people, who have had a bunch of outside
developers doing work on their site. At the
end of the day, they have several dlls sitting in the bin folder,
and no source code or project files available. Now you're a new
developer hired to fix bugs and extend the site. How do you
maintain these sites now without the source code of the codebehind
files? How do you understand them? Yes, you can add to it, yes even
extend the classes. But how do you fix bugs in the dlls without the
source code??? How do you even understand what the code does
exactly without the source code??? It's a nightmare!

In this respect I think classic ASP is way superior to ASP.NET.

Jan 13 '06 #6

P: n/a
If this is ever the case, then someone in management didn't do their job
right if they allowed only the result of compiling the source code to
remain, and not the source code itself.

Basically, the only option is to start from scratch and rewrite the
application, since you obviously can't hack the DLL. And whoever allowed
this to happen just learned a valuable lesson.

This, however has nothing to do with shortcomings of ASP.NET. Like I said,
ASP.NET can be written exactly as ASP was, with 100% of the code in plain
text in the .aspx - so this is always an option.
"Raymond" <no*****@33.net> wrote in message news:FvSxf.38$MG1.2@trnddc05...

That's very nice in theory, but I'm afraid that in the real world
it often doesn't work that way. The source code is often
not available to new developers for one reason or another.

"Marina" <so*****@nospam.com> wrote in message
news:ue*************@tk2msftngp13.phx.gbl...
The new developer that gets hired gets the source code that is left by
the
outsourced developers. Those outsourced developers would be required to
provide the source code to the DLLs, and the non-technical people would
be
in posession of this code when the old developers left the project. Thus,
the new develop would receive the source code and go from there.

I don't understand why you wouldn't have the source code??

And by the way, you can code in ASP.NET exactly like you did in ASP. You
don't have to use codebehind. You can have 100% of the code in the .aspx
files, and no DLLs whatsoever.

Maybe you should do your research before declaring ASP superior...

"Raymond" <no*****@33.net> wrote in message

news:3jSxf.37$MG1.28@trnddc05...
> They say it's easier, but has anyone tried
> maintaining an ASP.NET site without the
> source code of the dlls? This was not a problem
> with classic ASP, all the code was almost always
> just in text files, easily viewable and most importantly
> readily AVAILABLE on the site, to anyone access to
> the site's folder.
>
> But just imagine, bunch of companies out there, managed
> by non-technical people, who have had a bunch of outside
> developers doing work on their site. At the
> end of the day, they have several dlls sitting in the bin folder,
> and no source code or project files available. Now you're a new
> developer hired to fix bugs and extend the site. How do you
> maintain these sites now without the source code of the codebehind
> files? How do you understand them? Yes, you can add to it, yes even
> extend the classes. But how do you fix bugs in the dlls without the
> source code??? How do you even understand what the code does
> exactly without the source code??? It's a nightmare!
>
> In this respect I think classic ASP is way superior to ASP.NET.
>
>



Jan 13 '06 #7

P: n/a
Well, at this point what you do is whip out Lutz Roeder's Reflector, along
with the Assembly Decompiler add-in, and decompile all the DLLs so that you
can build a proper source solution.

And then, you require the source code as a matter of basic policy, or nobody
gets to work on your project.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Raymond" wrote:
Too late, you're the NEW developer. Dlls
have already been made and deployed into
the site. Now you have to fix bugs in them
without any source code. What do you do?
"Bruce Barker" <br******************@safeco.com> wrote in message
news:Oh**************@TK2MSFTNGP10.phx.gbl...
not having source code is an option with asp.net. turn off dll support on
your asp.net servers, and the source code will be required.

-- brcue (sqlwork.com)
"Raymond" <no*****@33.net> wrote in message

news:3jSxf.37$MG1.28@trnddc05...
They say it's easier, but has anyone tried
maintaining an ASP.NET site without the
source code of the dlls? This was not a problem
with classic ASP, all the code was almost always
just in text files, easily viewable and most importantly
readily AVAILABLE on the site, to anyone access to
the site's folder.

But just imagine, bunch of companies out there, managed
by non-technical people, who have had a bunch of outside
developers doing work on their site. At the
end of the day, they have several dlls sitting in the bin folder,
and no source code or project files available. Now you're a new
developer hired to fix bugs and extend the site. How do you
maintain these sites now without the source code of the codebehind
files? How do you understand them? Yes, you can add to it, yes even
extend the classes. But how do you fix bugs in the dlls without the
source code??? How do you even understand what the code does
exactly without the source code??? It's a nightmare!

In this respect I think classic ASP is way superior to ASP.NET.



Jan 13 '06 #8

P: n/a
I programmed classic ASP for several years, very
intensely, including maintaining the types of code
that you call complete mess. I never found any
complete mess code that I couldn't understand
and maintain with some effort. Now with ASP.NET
I have to disassemble serveral DLLs, dozens of
classes, and make sure I can compile them back to
same DLLs, before even attempting to fix and understand
the code, to even fix the most minor of issues,
which frankly is much more daunting and troublesome.

"Ravi Ambros Wallau" <rw*****@springwireless.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
An ASP application goes very easy to a complete mess...
Having source code with the page code is a thing that is being avoided in
many plataforms on these days, MVC is an attempt to improve this.
If you really can't access the source code and really need to change it, you can do a "prohibited" operation, but that solves your problem if the DLL is not obsfucated.
The key word in google is: Reflector

"Raymond" <no*****@33.net> wrote in message

news:3jSxf.37$MG1.28@trnddc05...
They say it's easier, but has anyone tried
maintaining an ASP.NET site without the
source code of the dlls? This was not a problem
with classic ASP, all the code was almost always
just in text files, easily viewable and most importantly
readily AVAILABLE on the site, to anyone access to
the site's folder.

But just imagine, bunch of companies out there, managed
by non-technical people, who have had a bunch of outside
developers doing work on their site. At the
end of the day, they have several dlls sitting in the bin folder,
and no source code or project files available. Now you're a new
developer hired to fix bugs and extend the site. How do you
maintain these sites now without the source code of the codebehind
files? How do you understand them? Yes, you can add to it, yes even
extend the classes. But how do you fix bugs in the dlls without the
source code??? How do you even understand what the code does
exactly without the source code??? It's a nightmare!

In this respect I think classic ASP is way superior to ASP.NET.


Jan 13 '06 #9

P: n/a
I don't think it's a natural choice to put all the code within the page.

NO reutilization;
NO separation between presentation layers;
NO possibility to have a guy drawing pages and another guy making the code.

Would you like to write all access to the data in your ASPX page? Possible
for few pages, completely insane for 100+ pages.
When you used to do ASP pages, didn't you used any COM+ componentes?

I think it's possible to maintain a good structure with ASP. But things goes
out of control very easy if control is not intensive.

"Raymond" <no*****@33.net> wrote in message news:rjTxf.49$Di.33@trnddc06...
I programmed classic ASP for several years, very
intensely, including maintaining the types of code
that you call complete mess. I never found any
complete mess code that I couldn't understand
and maintain with some effort. Now with ASP.NET
I have to disassemble serveral DLLs, dozens of
classes, and make sure I can compile them back to
same DLLs, before even attempting to fix and understand
the code, to even fix the most minor of issues,
which frankly is much more daunting and troublesome.

"Ravi Ambros Wallau" <rw*****@springwireless.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
An ASP application goes very easy to a complete mess...
Having source code with the page code is a thing that is being avoided in
many plataforms on these days, MVC is an attempt to improve this.
If you really can't access the source code and really need to change it,

you
can do a "prohibited" operation, but that solves your problem if the DLL

is
not obsfucated.
The key word in google is: Reflector

"Raymond" <no*****@33.net> wrote in message

news:3jSxf.37$MG1.28@trnddc05...
> They say it's easier, but has anyone tried
> maintaining an ASP.NET site without the
> source code of the dlls? This was not a problem
> with classic ASP, all the code was almost always
> just in text files, easily viewable and most importantly
> readily AVAILABLE on the site, to anyone access to
> the site's folder.
>
> But just imagine, bunch of companies out there, managed
> by non-technical people, who have had a bunch of outside
> developers doing work on their site. At the
> end of the day, they have several dlls sitting in the bin folder,
> and no source code or project files available. Now you're a new
> developer hired to fix bugs and extend the site. How do you
> maintain these sites now without the source code of the codebehind
> files? How do you understand them? Yes, you can add to it, yes even
> extend the classes. But how do you fix bugs in the dlls without the
> source code??? How do you even understand what the code does
> exactly without the source code??? It's a nightmare!
>
> In this respect I think classic ASP is way superior to ASP.NET.
>
>



Jan 13 '06 #10

P: n/a
Team development with ASP was no problem,
as long it was done right. Frankly, it was not too
difficult doing it right, as long as you were
following a few simple Source Safe practices.

We must've done thousands upon thousands of updates to
several hundred ASP files over 5 years, on several sites, using a team
that often included up to 5-8 developers working on the same site.
So I'm astonished when people say that classic ASP site maintenance
was much harder than ASP.NET. It's a completely
bogus issue, unless you were doing a lot of COM component
updates. Yes, we used them, but sparingly. They were a hassle to
update, since they required server restarts.

Reutilization with ASP? Server side includes! We used them
all over the place. You could also accomplish quite a bit
of the code/presentation separation using SSI,
Server.Transfer and Execute methods, in addition to script
components, and vbscript classes. Was really never a problem
for me, even if code/UI were mixed.

"Ravi Ambros Wallau" <rw*****@springwireless.net> wrote in message
news:Op*************@TK2MSFTNGP15.phx.gbl...
I don't think it's a natural choice to put all the code within the page.

NO reutilization;
NO separation between presentation layers;
NO possibility to have a guy drawing pages and another guy making the code.
Would you like to write all access to the data in your ASPX page? Possible
for few pages, completely insane for 100+ pages.
When you used to do ASP pages, didn't you used any COM+ componentes?

I think it's possible to maintain a good structure with ASP. But things goes out of control very easy if control is not intensive.

"Raymond" <no*****@33.net> wrote in message

news:rjTxf.49$Di.33@trnddc06...
I programmed classic ASP for several years, very
intensely, including maintaining the types of code
that you call complete mess. I never found any
complete mess code that I couldn't understand
and maintain with some effort. Now with ASP.NET
I have to disassemble serveral DLLs, dozens of
classes, and make sure I can compile them back to
same DLLs, before even attempting to fix and understand
the code, to even fix the most minor of issues,
which frankly is much more daunting and troublesome.

"Ravi Ambros Wallau" <rw*****@springwireless.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
An ASP application goes very easy to a complete mess...
Having source code with the page code is a thing that is being avoided in many plataforms on these days, MVC is an attempt to improve this.
If you really can't access the source code and really need to change
it, you
can do a "prohibited" operation, but that solves your problem if the
DLL is
not obsfucated.
The key word in google is: Reflector

"Raymond" <no*****@33.net> wrote in message

news:3jSxf.37$MG1.28@trnddc05...
> They say it's easier, but has anyone tried
> maintaining an ASP.NET site without the
> source code of the dlls? This was not a problem
> with classic ASP, all the code was almost always
> just in text files, easily viewable and most importantly
> readily AVAILABLE on the site, to anyone access to
> the site's folder.
>
> But just imagine, bunch of companies out there, managed
> by non-technical people, who have had a bunch of outside
> developers doing work on their site. At the
> end of the day, they have several dlls sitting in the bin folder,
> and no source code or project files available. Now you're a new
> developer hired to fix bugs and extend the site. How do you
> maintain these sites now without the source code of the codebehind
> files? How do you understand them? Yes, you can add to it, yes even
> extend the classes. But how do you fix bugs in the dlls without the
> source code??? How do you even understand what the code does
> exactly without the source code??? It's a nightmare!
>
> In this respect I think classic ASP is way superior to ASP.NET.
>
>



Jan 13 '06 #11

P: n/a
Peter Bromberg [C# MVP] wrote:
Well, at this point what you do is whip out Lutz Roeder's Reflector, along
with the Assembly Decompiler add-in, and decompile all the DLLs so thatyou
can build a proper source solution.

And then, you require the source code as a matter of basic policy, or nobody
gets to work on your project.
Peter


Ooo! Good call! I was about to say something similar, but you’ve even
got the progs pegged! (I wouldn’t have know which proggies to use...)

...Geshel
--
************************************************** *********************
* My reply-to is an automatically monitored spam honeypot. Do not use *
* it unless you want to be blacklisted by SpamCop. Please reply to my *
* first name at my last name dot org. *
************************************************** *********************
“Anyone who believes in Intelligent Design (“creationism”) is just as
ignorant and ill-educated as someone who believes that the world is
flat, that the Sun circles the Earth or that there really is a tooth
fairy. Darwinism has an overwhelming foundation of evidence that can be
tested and reproduced. Intelligent Design, on the other hand, has no
evidence at all; not one single shred of testable proof. As such,
Intelligent Design is Religious Mythology, and has no right whatsoever
to be in our Science classrooms.” - 99.99+% of Scientists
************************************************** *********************
Mignon McLaughlin once said that “A nymphomaniac is a woman [who is] as
obsessed with sex as the average man.” Unfortunately, since true
nymphomaniacs are so rare, this means that it takes an extraordinary
woman to keep up with an ordinary man.
************************************************** *********************
Jan 13 '06 #12

P: n/a
you are right.

Classic ASP was simpler and therefore easier to learn, use and maintain.

ASP.net is hard to learn and use. ASP.net is improving but has a ways to go. Version 1 was a start, 2.0 is better, hopefully
version 3 will be better yet.

The biggest problem I see is the divided development community. Different languages and different development tools hinder
communication and learning.

Learning tools like Web developer express are painful to use because they are so sluggish in performance and make new users cringe
with annoying slow response time.

There is still not a good file based sql database which can be easily deployed. Access is still the only file based option, which
isn't all bad. SQL server Express is not supported by web hosts because of claimed security reasons
=====================================
Knowledge comes and goes, but wisdom lingers

"Raymond" <no*****@33.net> wrote in message news:mjUxf.155$US3.103@trnddc04...
Team development with ASP was no problem,
as long it was done right. Frankly, it was not too
difficult doing it right, as long as you were
following a few simple Source Safe practices.

We must've done thousands upon thousands of updates to
several hundred ASP files over 5 years, on several sites, using a team
that often included up to 5-8 developers working on the same site.
So I'm astonished when people say that classic ASP site maintenance
was much harder than ASP.NET. It's a completely
bogus issue, unless you were doing a lot of COM component
updates. Yes, we used them, but sparingly. They were a hassle to
update, since they required server restarts.

Reutilization with ASP? Server side includes! We used them
all over the place. You could also accomplish quite a bit
of the code/presentation separation using SSI,
Server.Transfer and Execute methods, in addition to script
components, and vbscript classes. Was really never a problem
for me, even if code/UI were mixed.

"Ravi Ambros Wallau" <rw*****@springwireless.net> wrote in message
news:Op*************@TK2MSFTNGP15.phx.gbl...
I don't think it's a natural choice to put all the code within the page.

NO reutilization;
NO separation between presentation layers;
NO possibility to have a guy drawing pages and another guy making the

code.

Would you like to write all access to the data in your ASPX page? Possible
for few pages, completely insane for 100+ pages.
When you used to do ASP pages, didn't you used any COM+ componentes?

I think it's possible to maintain a good structure with ASP. But things

goes
out of control very easy if control is not intensive.

"Raymond" <no*****@33.net> wrote in message

news:rjTxf.49$Di.33@trnddc06...
>I programmed classic ASP for several years, very
> intensely, including maintaining the types of code
> that you call complete mess. I never found any
> complete mess code that I couldn't understand
> and maintain with some effort. Now with ASP.NET
> I have to disassemble serveral DLLs, dozens of
> classes, and make sure I can compile them back to
> same DLLs, before even attempting to fix and understand
> the code, to even fix the most minor of issues,
> which frankly is much more daunting and troublesome.
>
> "Ravi Ambros Wallau" <rw*****@springwireless.net> wrote in message
> news:%2****************@tk2msftngp13.phx.gbl...
>> An ASP application goes very easy to a complete mess...
>> Having source code with the page code is a thing that is being avoided in >> many plataforms on these days, MVC is an attempt to improve this.
>> If you really can't access the source code and really need to change it, > you
>> can do a "prohibited" operation, but that solves your problem if the DLL > is
>> not obsfucated.
>> The key word in google is: Reflector
>>
>> "Raymond" <no*****@33.net> wrote in message
> news:3jSxf.37$MG1.28@trnddc05...
>> > They say it's easier, but has anyone tried
>> > maintaining an ASP.NET site without the
>> > source code of the dlls? This was not a problem
>> > with classic ASP, all the code was almost always
>> > just in text files, easily viewable and most importantly
>> > readily AVAILABLE on the site, to anyone access to
>> > the site's folder.
>> >
>> > But just imagine, bunch of companies out there, managed
>> > by non-technical people, who have had a bunch of outside
>> > developers doing work on their site. At the
>> > end of the day, they have several dlls sitting in the bin folder,
>> > and no source code or project files available. Now you're a new
>> > developer hired to fix bugs and extend the site. How do you
>> > maintain these sites now without the source code of the codebehind
>> > files? How do you understand them? Yes, you can add to it, yes even
>> > extend the classes. But how do you fix bugs in the dlls without the
>> > source code??? How do you even understand what the code does
>> > exactly without the source code??? It's a nightmare!
>> >
>> > In this respect I think classic ASP is way superior to ASP.NET.
>> >
>> >
>>
>>
>
>



Jan 14 '06 #13

P: n/a
I just did a project that uses a simple file based
database using Datasets serialized to XML files. It
works okay for very basic stuff, though obviously
it's not a real database that can be managed without
some custom programming.

As for ASP.NET. I said it this three years ago
on these .net newsgroups, switching to it is not
nearly as compelling as ASP was in about '99.
That's why it hasn't taken off as Microsoft had
predicted. I remember projections back in 2002
and '03 from MS that had ASP.NET adoption
way higher by 2004 than it is right now in 2006.

It's not that I don't like it from a technical perspective,
I definitely like the common library, C#, the ease of
component creation relative to COM, Web
Services, besides other aspects. Windows app
creation is definitely much easier, and VS 2003
is the best dev tool I've used so far. Nevertheless,
from a practical point of view, for most sites, they're
better off with just classic ASP.

"Jon Paal" <Jon nospam Paal @ everywhere dot com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
you are right.

Classic ASP was simpler and therefore easier to learn, use and maintain.

ASP.net is hard to learn and use. ASP.net is improving but has a ways to go. Version 1 was a start, 2.0 is better, hopefully version 3 will be better yet.

The biggest problem I see is the divided development community. Different languages and different development tools hinder communication and learning.

Learning tools like Web developer express are painful to use because they are so sluggish in performance and make new users cringe with annoying slow response time.

There is still not a good file based sql database which can be easily deployed. Access is still the only file based option, which isn't all bad. SQL server Express is not supported by web hosts because of claimed security reasons

=====================================
Knowledge comes and goes, but wisdom lingers

"Raymond" <no*****@33.net> wrote in message

news:mjUxf.155$US3.103@trnddc04...
Team development with ASP was no problem,
as long it was done right. Frankly, it was not too
difficult doing it right, as long as you were
following a few simple Source Safe practices.

We must've done thousands upon thousands of updates to
several hundred ASP files over 5 years, on several sites, using a team
that often included up to 5-8 developers working on the same site.
So I'm astonished when people say that classic ASP site maintenance
was much harder than ASP.NET. It's a completely
bogus issue, unless you were doing a lot of COM component
updates. Yes, we used them, but sparingly. They were a hassle to
update, since they required server restarts.

Reutilization with ASP? Server side includes! We used them
all over the place. You could also accomplish quite a bit
of the code/presentation separation using SSI,
Server.Transfer and Execute methods, in addition to script
components, and vbscript classes. Was really never a problem
for me, even if code/UI were mixed.

"Ravi Ambros Wallau" <rw*****@springwireless.net> wrote in message
news:Op*************@TK2MSFTNGP15.phx.gbl...
I don't think it's a natural choice to put all the code within the page.
NO reutilization;
NO separation between presentation layers;
NO possibility to have a guy drawing pages and another guy making the

code.

Would you like to write all access to the data in your ASPX page? Possible for few pages, completely insane for 100+ pages.
When you used to do ASP pages, didn't you used any COM+ componentes?

I think it's possible to maintain a good structure with ASP. But things

goes
out of control very easy if control is not intensive.

"Raymond" <no*****@33.net> wrote in message

news:rjTxf.49$Di.33@trnddc06...
>I programmed classic ASP for several years, very
> intensely, including maintaining the types of code
> that you call complete mess. I never found any
> complete mess code that I couldn't understand
> and maintain with some effort. Now with ASP.NET
> I have to disassemble serveral DLLs, dozens of
> classes, and make sure I can compile them back to
> same DLLs, before even attempting to fix and understand
> the code, to even fix the most minor of issues,
> which frankly is much more daunting and troublesome.
>
> "Ravi Ambros Wallau" <rw*****@springwireless.net> wrote in message
> news:%2****************@tk2msftngp13.phx.gbl...
>> An ASP application goes very easy to a complete mess...
>> Having source code with the page code is a thing that is being avoided
in
>> many plataforms on these days, MVC is an attempt to improve this.
>> If you really can't access the source code and really need to change

it,
> you
>> can do a "prohibited" operation, but that solves your problem if the

DLL
> is
>> not obsfucated.
>> The key word in google is: Reflector
>>
>> "Raymond" <no*****@33.net> wrote in message
> news:3jSxf.37$MG1.28@trnddc05...
>> > They say it's easier, but has anyone tried
>> > maintaining an ASP.NET site without the
>> > source code of the dlls? This was not a problem
>> > with classic ASP, all the code was almost always
>> > just in text files, easily viewable and most importantly
>> > readily AVAILABLE on the site, to anyone access to
>> > the site's folder.
>> >
>> > But just imagine, bunch of companies out there, managed
>> > by non-technical people, who have had a bunch of outside
>> > developers doing work on their site. At the
>> > end of the day, they have several dlls sitting in the bin folder,
>> > and no source code or project files available. Now you're a new
>> > developer hired to fix bugs and extend the site. How do you
>> > maintain these sites now without the source code of the codebehind
>> > files? How do you understand them? Yes, you can add to it, yes

even >> > extend the classes. But how do you fix bugs in the dlls without the >> > source code??? How do you even understand what the code does
>> > exactly without the source code??? It's a nightmare!
>> >
>> > In this respect I think classic ASP is way superior to ASP.NET.
>> >
>> >
>>
>>
>
>



Jan 15 '06 #14

P: n/a
Raymond wrote:
That's very nice in theory, but I'm afraid that in the real world
it often doesn't work that way. The source code is often
not available to new developers for one reason or another.


That's a management/policy issue like others said before. We've NEVER
had such a problem before, and we're not expecting it to happen either.
if the previous developers (I'm not talking about ASP.Net in specific
here) leave you no source code and documentation there's a very big
problem. Either they've deleted it (and it is company property) *and*
that there is seemingly no standard backup procedures in place (even for
critical things like that, and no auditing either), it most likely also
means there is no source code control/management program in place (and
perhaps issues with team development), etc. I don't see why code would
all of a sudden go "missing" (can you imagine, say, a new developer
coming to work on Windows (or any other app) and all they have is some
DLLs and no code left anymore? No? well, it's the exact same thing). If
you want you can use it somewhat like classic ASP with all the code in
the aspx page itself. The ability for the code to be compiled is NOT a
bad thing. It rather sounds like your company has some serious IT issues
to look into. Code disappearing like that is practically impossible if
you use source control/backups and all. You can't exactly blame these
problems on the technology for not having made it impossible by
crippling itself...
Jan 15 '06 #15

P: n/a

Well I can blame it on the technology, because
compilation to dlls is how most ASP.NET sites
are done, and that's not the case with classic ASP.

Like I said, these companies are managed by
very non-technical people. They are small
and have no in-house technical staff whatsoever.
They are entirely at the mercy of the developers
they contract. Once or if you come across this,
as I have, you'll appreciate how things work
in the real world.
"john smith" <jo**@smith.com> wrote in message
news:ON**************@TK2MSFTNGP09.phx.gbl...
Raymond wrote:
That's very nice in theory, but I'm afraid that in the real world
it often doesn't work that way. The source code is often
not available to new developers for one reason or another.


That's a management/policy issue like others said before. We've NEVER
had such a problem before, and we're not expecting it to happen either.
if the previous developers (I'm not talking about ASP.Net in specific
here) leave you no source code and documentation there's a very big
problem. Either they've deleted it (and it is company property) *and*
that there is seemingly no standard backup procedures in place (even for
critical things like that, and no auditing either), it most likely also
means there is no source code control/management program in place (and
perhaps issues with team development), etc. I don't see why code would
all of a sudden go "missing" (can you imagine, say, a new developer
coming to work on Windows (or any other app) and all they have is some
DLLs and no code left anymore? No? well, it's the exact same thing). If
you want you can use it somewhat like classic ASP with all the code in
the aspx page itself. The ability for the code to be compiled is NOT a
bad thing. It rather sounds like your company has some serious IT issues
to look into. Code disappearing like that is practically impossible if
you use source control/backups and all. You can't exactly blame these
problems on the technology for not having made it impossible by
crippling itself...

Jan 15 '06 #16

P: n/a
Also, go to the MSDN online library.
http://msdn.microsoft.com/library/default.asp
The whole things is running classic ASP,
by the people who invented, released, and
promoted ASP.NET 4 years ago!

What's funny is that I remember they switched
to using ASPX there a couple of years ago, and now
they themselves have gone back to using classic
ASP there. <LOL>
"john smith" <jo**@smith.com> wrote in message
news:ON**************@TK2MSFTNGP09.phx.gbl...
Raymond wrote:
That's very nice in theory, but I'm afraid that in the real world
it often doesn't work that way. The source code is often
not available to new developers for one reason or another.


That's a management/policy issue like others said before. We've NEVER
had such a problem before, and we're not expecting it to happen either.
if the previous developers (I'm not talking about ASP.Net in specific
here) leave you no source code and documentation there's a very big
problem. Either they've deleted it (and it is company property) *and*
that there is seemingly no standard backup procedures in place (even for
critical things like that, and no auditing either), it most likely also
means there is no source code control/management program in place (and
perhaps issues with team development), etc. I don't see why code would
all of a sudden go "missing" (can you imagine, say, a new developer
coming to work on Windows (or any other app) and all they have is some
DLLs and no code left anymore? No? well, it's the exact same thing). If
you want you can use it somewhat like classic ASP with all the code in
the aspx page itself. The ability for the code to be compiled is NOT a
bad thing. It rather sounds like your company has some serious IT issues
to look into. Code disappearing like that is practically impossible if
you use source control/backups and all. You can't exactly blame these
problems on the technology for not having made it impossible by
crippling itself...


Jan 16 '06 #17

P: n/a
Raymond wrote:
Well I can blame it on the technology, because
compilation to dlls is how most ASP.NET sites
are done, and that's not the case with classic ASP.

Like I said, these companies are managed by
very non-technical people. They are small
and have no in-house technical staff whatsoever.
They are entirely at the mercy of the developers
they contract. Once or if you come across this,
as I have, you'll appreciate how things work
in the real world.


No you can't blame it on the technology just because it doesn't prevent
people from making bad decisions, not implementing best practices,
having non-technical (i.e. people that aren't qualified, under-qualified
or even incompetent) making decisions and policies, etc. If they
decide to contract, they only had to ask for the source code (which they
should get in almost all cases anyways - except for 3rd party libs used
and such). That's poor requirements (and perhaps not contracting with
the right people - any decent contractor would ask questions like this).
None of that can be blamed on the technology itself. ASP.Net is vastly
superior to ASP in every aspect (a truly amazing framework, great
performance/maintainability, great languages, etc etc). So what you're
saying is they should have made it impossible to compile apps (which was
also possible in ASP as a COM DLL which you don't seem to object to)
instead of making it an option like it is currently (just because some
people have no clue), hence making the platform much slower overall and
lacking in comparison with Java and others (making themselves a not as
good/attractive solution as other development/hosting platforms i.e. a
second rate platform instead of becoming the absolute best in the
market)? And that would be better? Okie!

Didn't know I lived in the fake world, but I suppose it's good to know!
Jan 16 '06 #18

P: n/a
On Sun, 15 Jan 2006 23:56:40 GMT, "Raymond" <no*****@33.net> wrote:

What's funny is that I remember they switched
to using ASPX there a couple of years ago, and now
they themselves have gone back to using classic
ASP there. <LOL>


ASP.NET is behind the vast majority of MSDN. Read about it here:
http://msdn.microsoft.com/msdnmag/is...02/InsideMSDN/

--
Scott
http://www.OdeToCode.com/blogs/scott/

Jan 16 '06 #19

P: n/a
On Sun, 15 Jan 2006 23:26:41 GMT, "Raymond" <no*****@33.net> wrote:

Like I said, these companies are managed by
very non-technical people. They are small
and have no in-house technical staff whatsoever.
They are entirely at the mercy of the developers
they contract. Once or if you come across this,
as I have, you'll appreciate how things work
in the real world.


I've seen the same scenario happen with VB6 solutions. The problem is
generally "you get what you pay for".

--
Scott
http://www.OdeToCode.com/blogs/scott/
Jan 16 '06 #20

P: n/a
Since I've several of your responses as well as your original post, I
thought I would just respond to all here.

First of all, your original premise has nothing to do with the technology.
If you went into a business that had only a COM DLL and nothing else (yes, I
have seen classic ASP applications just like this), then you have the same
issue as you seem to claim to be unique to ASP.NET. Secondly, when you go
to these businesses, are you sure that these websites are not third-party
applications and they want to hack the code?

As for the viability of ASP.NET, you need to look at more websites. I see
more and more businesses, including Fortune 500 companies, using ASP.NET in
their website development. .NET has taken off and it has apparently left
you behind. Classic ASP is scripted and will generally be slower than
ASP.NET. The ability to split code from HTML is probably the best general
feature that ASP.NET offers. Technologically, ASP.NET is superior,
especially since classic ASP will not be updated any more.

Sometimes, we fear what we cannot understand.....
--
Christopher A. Reed
"The oxen are slow, but the earth is patient."

"Raymond" <no*****@33.net> wrote in message
news:vJzyf.7394$6L1.874@trnddc02...
I just did a project that uses a simple file based
database using Datasets serialized to XML files. It
works okay for very basic stuff, though obviously
it's not a real database that can be managed without
some custom programming.

As for ASP.NET. I said it this three years ago
on these .net newsgroups, switching to it is not
nearly as compelling as ASP was in about '99.
That's why it hasn't taken off as Microsoft had
predicted. I remember projections back in 2002
and '03 from MS that had ASP.NET adoption
way higher by 2004 than it is right now in 2006.

It's not that I don't like it from a technical perspective,
I definitely like the common library, C#, the ease of
component creation relative to COM, Web
Services, besides other aspects. Windows app
creation is definitely much easier, and VS 2003
is the best dev tool I've used so far. Nevertheless,
from a practical point of view, for most sites, they're
better off with just classic ASP.

Jan 16 '06 #21

P: n/a

I just did a project that uses a simple file based
database using Datasets serialized to XML files. It
works okay for very basic stuff, though obviously
it's not a real database that can be managed without
some custom programming.
I agree

As for ASP.NET. I said it this three years ago
on these .net newsgroups, switching to it is not
nearly as compelling as ASP was in about '99.
That's why it hasn't taken off as Microsoft had
predicted. I remember projections back in 2002
and '03 from MS that had ASP.NET adoption
way higher by 2004 than it is right now in 2006.
I agree - plus, I am finding that my customers don't like getting their work delivered as ASP.net, because they can't work with it
and they generally prefer to have the ability of tweaking a few things. So right now I have a hard time selling this technology!

It's not that I don't like it from a technical perspective,
I definitely like the common library, C#, the ease of
component creation relative to COM, Web
Services, besides other aspects. Windows app
creation is definitely much easier, and VS 2003
is the best dev tool I've used so far. Nevertheless,
from a practical point of view, for most sites, they're
better off with just classic ASP.
I have had such a miserable experience with the lite version (express), I have no desire to try the fully loaded Visual Studio.

"Jon Paal" <Jon nospam Paal @ everywhere dot com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
you are right.

Classic ASP was simpler and therefore easier to learn, use and maintain.

ASP.net is hard to learn and use. ASP.net is improving but has a ways to

go. Version 1 was a start, 2.0 is better, hopefully
version 3 will be better yet.

The biggest problem I see is the divided development community.

Different languages and different development tools hinder
communication and learning.

Learning tools like Web developer express are painful to use because they

are so sluggish in performance and make new users cringe
with annoying slow response time.

There is still not a good file based sql database which can be easily

deployed. Access is still the only file based option, which
isn't all bad. SQL server Express is not supported by web hosts because

of claimed security reasons


=====================================
Knowledge comes and goes, but wisdom lingers

"Raymond" <no*****@33.net> wrote in message

news:mjUxf.155$US3.103@trnddc04...
> Team development with ASP was no problem,
> as long it was done right. Frankly, it was not too
> difficult doing it right, as long as you were
> following a few simple Source Safe practices.
>
> We must've done thousands upon thousands of updates to
> several hundred ASP files over 5 years, on several sites, using a team
> that often included up to 5-8 developers working on the same site.
> So I'm astonished when people say that classic ASP site maintenance
> was much harder than ASP.NET. It's a completely
> bogus issue, unless you were doing a lot of COM component
> updates. Yes, we used them, but sparingly. They were a hassle to
> update, since they required server restarts.
>
> Reutilization with ASP? Server side includes! We used them
> all over the place. You could also accomplish quite a bit
> of the code/presentation separation using SSI,
> Server.Transfer and Execute methods, in addition to script
> components, and vbscript classes. Was really never a problem
> for me, even if code/UI were mixed.
>
>
>
> "Ravi Ambros Wallau" <rw*****@springwireless.net> wrote in message
> news:Op*************@TK2MSFTNGP15.phx.gbl...
>> I don't think it's a natural choice to put all the code within the page. >>
>> NO reutilization;
>> NO separation between presentation layers;
>> NO possibility to have a guy drawing pages and another guy making the
> code.
>>
>> Would you like to write all access to the data in your ASPX page? Possible >> for few pages, completely insane for 100+ pages.
>> When you used to do ASP pages, didn't you used any COM+ componentes?
>>
>> I think it's possible to maintain a good structure with ASP. But things
> goes
>> out of control very easy if control is not intensive.
>>
>> "Raymond" <no*****@33.net> wrote in message
> news:rjTxf.49$Di.33@trnddc06...
>> >I programmed classic ASP for several years, very
>> > intensely, including maintaining the types of code
>> > that you call complete mess. I never found any
>> > complete mess code that I couldn't understand
>> > and maintain with some effort. Now with ASP.NET
>> > I have to disassemble serveral DLLs, dozens of
>> > classes, and make sure I can compile them back to
>> > same DLLs, before even attempting to fix and understand
>> > the code, to even fix the most minor of issues,
>> > which frankly is much more daunting and troublesome.
>> >
>> > "Ravi Ambros Wallau" <rw*****@springwireless.net> wrote in message
>> > news:%2****************@tk2msftngp13.phx.gbl...
>> >> An ASP application goes very easy to a complete mess...
>> >> Having source code with the page code is a thing that is being avoided > in
>> >> many plataforms on these days, MVC is an attempt to improve this.
>> >> If you really can't access the source code and really need to change
> it,
>> > you
>> >> can do a "prohibited" operation, but that solves your problem if the
> DLL
>> > is
>> >> not obsfucated.
>> >> The key word in google is: Reflector
>> >>
>> >> "Raymond" <no*****@33.net> wrote in message
>> > news:3jSxf.37$MG1.28@trnddc05...
>> >> > They say it's easier, but has anyone tried
>> >> > maintaining an ASP.NET site without the
>> >> > source code of the dlls? This was not a problem
>> >> > with classic ASP, all the code was almost always
>> >> > just in text files, easily viewable and most importantly
>> >> > readily AVAILABLE on the site, to anyone access to
>> >> > the site's folder.
>> >> >
>> >> > But just imagine, bunch of companies out there, managed
>> >> > by non-technical people, who have had a bunch of outside
>> >> > developers doing work on their site. At the
>> >> > end of the day, they have several dlls sitting in the bin folder,
>> >> > and no source code or project files available. Now you're a new
>> >> > developer hired to fix bugs and extend the site. How do you
>> >> > maintain these sites now without the source code of the codebehind
>> >> > files? How do you understand them? Yes, you can add to it, yes even >> >> > extend the classes. But how do you fix bugs in the dlls without the >> >> > source code??? How do you even understand what the code does
>> >> > exactly without the source code??? It's a nightmare!
>> >> >
>> >> > In this respect I think classic ASP is way superior to ASP.NET.
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>



Jan 19 '06 #22

P: n/a
I thought this thread was a good example of the "Annie Get Your Gun
Syndrome"... "Anything you can do, I can do better..."

In a perfect world, code is written, stored in a safe place, fully
accessible only by those who need it. This code was well written, well
formatted & indented, richly filled with comments detailing every change
and the revision the changes belong to. Its easy to read, easy to
retrieve. The comments in the code detailed function calls & Subs
called. It also listed every link to an external file and detailed the
use of same. If you had any question at all, the answer was spelled out
right there in the code. As a new developer, you had it all.
Unfortunately, this isn't real world.

Best Practices aside, not everyone implements them. Reasons usually are
cost driven. Most often, management understands they are throwing a
pair of dice something will not go wrong. So there isn't enough time to
document, the users want features implemented now, not a week later so
you can document your changes, verify backups, update change control and
document your database.

Look at .Net as a product. Not a development tool, a product that lives
and breathes on retail shelves. Where did some of the features come
from? Anyone ever notice that C# is pretty much Java? Why don't you
need to register DLL's any longer if you use .Net? I can remember way
back when I did my first website, I wanted a COM component installed on
the server. The host said "No, sorry, we don't install any 3rd party
COM components on OUR servers."

Part of the features of the .Net environment were created to get around
a lot of limitations website developers had with 3rd party hosting
companies. .Net provides a language that was easy to migrate from Java
(after all, why use that, it isn't Microsoft) and make it possible for
more and more websites to get from everything else and into .Net.
Software is a volume game. You need to sell lots and lots of copies to
make lots and lots of money. Selling software volume licenses isn't
enough, you need people buying retail copies. So forget cfm, php, asp,
etc, etc, etc. Move to .Net today. All you small developers, forget
Java and Cold Fusion, it's time to come up in the world and use .Net.

Unfortunately, there go those best practices again. .Net is high
maintenance. It is really for ENTERPRISE development where you can
maintain those Best Practices. Even then, it is still hard to migrate
from anything to .Net. I have spoken with dozens of .Net developers
over the years. Everyone that tried a large migration from VB 6 or ASP
Classic to .Net had problems from the start. In the end, everyone
started from scratch. And all those websites that are moving to .Net
every day? Some are still doing it after 3 years and aren't even half
complete. So that small one man shop maintaining a dozen sites for
clients? He probably wont be moving any to .Net anytime soon. Hell
play with it, start to make some changes to some sites to get a feel for
it. But I doubt very many of those guys are moving to .Net.

If you look at some sites, eBay comes to mind, they were a huge ASP
shop, using some heavy CGI implementations on the backend. They have
said no to .Net and moved from Windows to Java on Sun hardware. And
there is this one teeny tiny issue with .Net. Buy into it and youre on
Windows Server. Im not putting down Windows 2003 Server. I use it for
my websites. But with .Net, there isnt any viable option for another
hardware and/or OS platform except windows. Yes, I know there are a few
options out there. Novell has Mono, the open source solution to run
..Net on Sun Solaris, Linyx and Mac. But these are too new and lack
sufficient field implementation for serious use. Time will tell with
these.

I contract for a LARGE phone company. Name starts with "V". You can
figure it out. A lot of the company has moved to .Net. A lot hasn't.
We are a 3 man IT shop (a Directror, 1 Developer, thats me and 1 Help
Desk person) that works on its own without any direction from Corporate
IT. We work directly for a business unit. I work on an intranet site
that manages the work for a nationwide project. It's pure, classic ASP.
We considered moving to .Net. We ended up saying "No, stay in ASP".
Why? There go those damn "Best Practices" again getting in the way.
There isn't time to migrate to .Net. It would take us (as in me since
Im the only developer) 9 dedicated months to build the framework. In
the meantime, the work continues in the field and the users want changes
to the application on a weekly basis to support the work. We implement
at least 20 enhancements a month to this application and about a dozen
changes and/or fixes due to business rule changes.

Unless youre an Enterprise with a few million to throw at .Net, you
wont be headed there anytime soon. Yeah, I know some small guys using
..Net by themselves. Go to any hosting company and ask them how many
sites served by a single server are using .Net. Not too many.

Like I said, Anything you can do I can do it too. In some ways,
better or more efficiently than .Net. In other ways more efficiently
but not better, and some ways better than .Net but not as efficiently.
Its a trade off. Because in the end, it doesnt matter what platform
is better, the work still has a deadline that needs to be met. And you
use the tool that allows you to meet your customers needs now, not in 9
months. Because if you dont, someone else surely will.


*** Sent via Developersdex http://www.developersdex.com ***
Jan 24 '06 #23

P: n/a
> Unless you're an Enterprise with a few million to throw at .Net, you
won't be headed there anytime soon. Yeah, I know some small guys using
Net by themselves. Go to any hosting company and ask them how many
sites served by a single server are using .Net. Not too many.
First, Good post Dan. I agree with much of it.

That said, we're in a simliar environment as you...2 person dev team. We
decided to go with .net for no particular reason, actually. Just that we had
to start from scratch, so figured since we're an MS shop, we might as well.

So, I think there are small firms/groups using .net, but I completely agree,
it's not really something you 'migrate to' as much as 'time to start a new
project, now's the time to switch to .net'
Like I said, "Anything you can do." I can do it too. In some ways,
better or more efficiently than .Net.
I completely agree. .net is great, but, as you said, really designed for
that ideal best-practices fully managed environment.

For many web sites, I feel .net is actually overkill.
Because in the end, it doesn't matter what platform
is better, the work still has a deadline that needs to be met. And you
use the tool that allows you to meet your customers needs now, not in 9
months. Because if you don't, someone else surely will.


Well said.

-Darrel
Jan 25 '06 #24

P: n/a
It's time to pull out the popcorn.
"Raymond" <no*****@33.net> wrote in message
news:RSAyf.3251$MG1.2630@trnddc05...

Well I can blame it on the technology, because
compilation to dlls is how most ASP.NET sites
are done, and that's not the case with classic ASP.

Like I said, these companies are managed by
very non-technical people. They are small
and have no in-house technical staff whatsoever.
They are entirely at the mercy of the developers
they contract. Once or if you come across this,
as I have, you'll appreciate how things work
in the real world.
"john smith" <jo**@smith.com> wrote in message
news:ON**************@TK2MSFTNGP09.phx.gbl...
Raymond wrote:
> That's very nice in theory, but I'm afraid that in the real world
> it often doesn't work that way. The source code is often
> not available to new developers for one reason or another.


That's a management/policy issue like others said before. We've NEVER
had such a problem before, and we're not expecting it to happen either.
if the previous developers (I'm not talking about ASP.Net in specific
here) leave you no source code and documentation there's a very big
problem. Either they've deleted it (and it is company property) *and*
that there is seemingly no standard backup procedures in place (even for
critical things like that, and no auditing either), it most likely also
means there is no source code control/management program in place (and
perhaps issues with team development), etc. I don't see why code would
all of a sudden go "missing" (can you imagine, say, a new developer
coming to work on Windows (or any other app) and all they have is some
DLLs and no code left anymore? No? well, it's the exact same thing). If
you want you can use it somewhat like classic ASP with all the code in
the aspx page itself. The ability for the code to be compiled is NOT a
bad thing. It rather sounds like your company has some serious IT issues
to look into. Code disappearing like that is practically impossible if
you use source control/backups and all. You can't exactly blame these
problems on the technology for not having made it impossible by
crippling itself...


Feb 23 '06 #25

P: n/a
I think MS just hasn't converted all their classic ASP applications to .NET.
I mean, if something is running fine and doesn't require much maintenance,
why would Microsoft need to rewrite the webpage? I suppose if they're bored
or just one a standard design across all their sites. As you will likely
fine... Microsoft website, including MSDN, etc., belong to many subsidiaries
of Microsoft. There isn't one "webmaster" guy that manages the entire web
farm. There are hundreds of small subsidaries that have their own virtual
directory.

As long as their applications perform within specs and following their
design and branding practices, then you will likely find a mix of ASP and
ASPX.

I think there was an interview on Channel9 with the IIS testing group
regarding some of this.
"Raymond" <no*****@33.net> wrote in message
news:YiByf.3255$MG1.89@trnddc05...
Also, go to the MSDN online library.
http://msdn.microsoft.com/library/default.asp
The whole things is running classic ASP,
by the people who invented, released, and
promoted ASP.NET 4 years ago!

What's funny is that I remember they switched
to using ASPX there a couple of years ago, and now
they themselves have gone back to using classic
ASP there. <LOL>
"john smith" <jo**@smith.com> wrote in message
news:ON**************@TK2MSFTNGP09.phx.gbl...
Raymond wrote:
> That's very nice in theory, but I'm afraid that in the real world
> it often doesn't work that way. The source code is often
> not available to new developers for one reason or another.


That's a management/policy issue like others said before. We've NEVER
had such a problem before, and we're not expecting it to happen either.
if the previous developers (I'm not talking about ASP.Net in specific
here) leave you no source code and documentation there's a very big
problem. Either they've deleted it (and it is company property) *and*
that there is seemingly no standard backup procedures in place (even for
critical things like that, and no auditing either), it most likely also
means there is no source code control/management program in place (and
perhaps issues with team development), etc. I don't see why code would
all of a sudden go "missing" (can you imagine, say, a new developer
coming to work on Windows (or any other app) and all they have is some
DLLs and no code left anymore? No? well, it's the exact same thing). If
you want you can use it somewhat like classic ASP with all the code in
the aspx page itself. The ability for the code to be compiled is NOT a
bad thing. It rather sounds like your company has some serious IT issues
to look into. Code disappearing like that is practically impossible if
you use source control/backups and all. You can't exactly blame these
problems on the technology for not having made it impossible by
crippling itself...


Feb 23 '06 #26

P: n/a
Hmmm ---

You make reference to having "Best Practices for SourceSafe" and doing
"Thousands upon thousands of updates to several hundred ASP files over 5
years", but you failed to notice that one of your developers and/or vendors
published part of your website as a .DLL? Why is this ASP.NET's fault for
your companies inability to demand from someone that is updating your site
to document what they're doing?

I have a real problem with outsiders remotely accessing our servers and
installing junk. For starters... they never tell anyone what they're doing.
They change junk and don't tell anyone. They create folders and
dependencies that when changed, will cause the application to fail... which
in return will cause me to have to call them and pay them more money to
support and application that they impropertly delivered to begin with.
Catch-22. I see this all the time in IT.

I demand that they give me their setups, program files, source,
documentation, and whatever else they require for me to setup their
application and then I install it. I know I'm the one that will be getting
the 1AM phone call when something breaks or have to come in on a weekend to
fix something. Having someone else do it for me is a recipe for disaster
and you end up spending more money and time for it in the long run.

You sound like you're fairly component with ASP but you still failed to
notice that an application that is running on your webserver does not have
any source -- or you simply assumed that it did.

I don't believe you can blame the technology for incompetence.
"Raymond" <no*****@33.net> wrote in message
news:mjUxf.155$US3.103@trnddc04...
Team development with ASP was no problem,
as long it was done right. Frankly, it was not too
difficult doing it right, as long as you were
following a few simple Source Safe practices.

We must've done thousands upon thousands of updates to
several hundred ASP files over 5 years, on several sites, using a team
that often included up to 5-8 developers working on the same site.
So I'm astonished when people say that classic ASP site maintenance
was much harder than ASP.NET. It's a completely
bogus issue, unless you were doing a lot of COM component
updates. Yes, we used them, but sparingly. They were a hassle to
update, since they required server restarts.

Reutilization with ASP? Server side includes! We used them
all over the place. You could also accomplish quite a bit
of the code/presentation separation using SSI,
Server.Transfer and Execute methods, in addition to script
components, and vbscript classes. Was really never a problem
for me, even if code/UI were mixed.

"Ravi Ambros Wallau" <rw*****@springwireless.net> wrote in message
news:Op*************@TK2MSFTNGP15.phx.gbl...
I don't think it's a natural choice to put all the code within the page.

NO reutilization;
NO separation between presentation layers;
NO possibility to have a guy drawing pages and another guy making the

code.

Would you like to write all access to the data in your ASPX page?
Possible
for few pages, completely insane for 100+ pages.
When you used to do ASP pages, didn't you used any COM+ componentes?

I think it's possible to maintain a good structure with ASP. But things

goes
out of control very easy if control is not intensive.

"Raymond" <no*****@33.net> wrote in message

news:rjTxf.49$Di.33@trnddc06...
>I programmed classic ASP for several years, very
> intensely, including maintaining the types of code
> that you call complete mess. I never found any
> complete mess code that I couldn't understand
> and maintain with some effort. Now with ASP.NET
> I have to disassemble serveral DLLs, dozens of
> classes, and make sure I can compile them back to
> same DLLs, before even attempting to fix and understand
> the code, to even fix the most minor of issues,
> which frankly is much more daunting and troublesome.
>
> "Ravi Ambros Wallau" <rw*****@springwireless.net> wrote in message
> news:%2****************@tk2msftngp13.phx.gbl...
>> An ASP application goes very easy to a complete mess...
>> Having source code with the page code is a thing that is being avoided in >> many plataforms on these days, MVC is an attempt to improve this.
>> If you really can't access the source code and really need to change it, > you
>> can do a "prohibited" operation, but that solves your problem if the DLL > is
>> not obsfucated.
>> The key word in google is: Reflector
>>
>> "Raymond" <no*****@33.net> wrote in message
> news:3jSxf.37$MG1.28@trnddc05...
>> > They say it's easier, but has anyone tried
>> > maintaining an ASP.NET site without the
>> > source code of the dlls? This was not a problem
>> > with classic ASP, all the code was almost always
>> > just in text files, easily viewable and most importantly
>> > readily AVAILABLE on the site, to anyone access to
>> > the site's folder.
>> >
>> > But just imagine, bunch of companies out there, managed
>> > by non-technical people, who have had a bunch of outside
>> > developers doing work on their site. At the
>> > end of the day, they have several dlls sitting in the bin folder,
>> > and no source code or project files available. Now you're a new
>> > developer hired to fix bugs and extend the site. How do you
>> > maintain these sites now without the source code of the codebehind
>> > files? How do you understand them? Yes, you can add to it, yes even
>> > extend the classes. But how do you fix bugs in the dlls without the
>> > source code??? How do you even understand what the code does
>> > exactly without the source code??? It's a nightmare!
>> >
>> > In this respect I think classic ASP is way superior to ASP.NET.
>> >
>> >
>>
>>
>
>



Feb 23 '06 #27

P: n/a
You missed the point, they DID convert. It didn't
work well, then they converted back.

"dm1608" <dm****@spam.net> wrote in message
news:uK*************@TK2MSFTNGP09.phx.gbl...
I think MS just hasn't converted all their classic ASP applications to ..NET. I mean, if something is running fine and doesn't require much maintenance,
why would Microsoft need to rewrite the webpage? I suppose if they're bored or just one a standard design across all their sites. As you will likely
fine... Microsoft website, including MSDN, etc., belong to many subsidiaries of Microsoft. There isn't one "webmaster" guy that manages the entire web
farm. There are hundreds of small subsidaries that have their own virtual
directory.

As long as their applications perform within specs and following their
design and branding practices, then you will likely find a mix of ASP and
ASPX.

I think there was an interview on Channel9 with the IIS testing group
regarding some of this.

Mar 1 '06 #28

This discussion thread is closed

Replies have been disabled for this discussion.