ASP.NET Development

[Guest]

Being a ASP developer for a consultant company thinking of starting
developing with ASP.NET I have read literally hundreds of web pages and posts
in discussion forums on the Internet to get an idea of what we will need to
adapt to. I have read Microsoft’s “Team Development with Visual Studio .NET
and Visual SourceSafe†and tried to set up a development environment as
recommended using the “Isolated modelâ€. However, many questions regarding the
development environment as well as the technique itself still remain
unanswered. I’ll try to summarize some of them here and hopefully someone
will be able to give me the answers I can’t find myself.

1. Development
I simply cannot understand how the recommended model can be to develop an
application on Win XP with IIS 5 when the application is to be deployed on a
Win 2003 Server with IIS 6. To me this is bound to cause problems. In
addition - security settings, installed software etc. is likely to vary on
different developer workstations as well as on different servers.

2. Deploying
Microsoft proudly promotes the “x-copyâ€-deployment but they haven’t seemed
to consider that a new web application deployed with x-copy won’t run without
manually changing settings in the IIS.
The “Copy projectâ€-functionality seems mostly as a joke to me. Having read
about FPSE security issues I wouldn’t even consider installing it on a public
web server so that leaves the file share option which of course is nothing
else but x-copy with some file type exclusions. And how they decided not to
include FTP as an option is beyond my understanding.
So, I’m left with something called Web setup projects. But from what I
understand, they won’t install under anything else than localhost. In other
words I cannot use it on servers hosting multiple web sites.

3. Working with multiple web sites
We are a consultant company and we work with multiple web sites for many
different clients. Maybe I haven’t understood how we should set up the
environment but we are leaning towards having one solution for each one of
the web sites we work with.
After a web site is released the majority of our work consists of relatively
small changes and fixes. Having to quickly jump between the different
solutions and waiting seemingly endlessly for the solution to load every time
we need to make small changes feels as a terrible waste of valuable time and
money.

4. Testing and debugging
Having mentioned that we often make small changes – moving to ASP.NET feels
as the time for making and testing these changes will dramatically increase
the time needed. First of all the entire project will have to load into
VS.NET. Then I make some changes to a code behind file which will result in
the entire project will need recompiling. The compilation will need to occur
every time I test a never so small change and I will have to wait at least
15-20 seconds before I will be able to view the changes. When I’m satisfied
with the changes (tested on my local development workstation) I will have to
compile it on a testing server using our VSS database as source and if we
consider it to be functional I will somehow try to deploy it to a public web
server.

I seriously wonder if Microsoft really has considered VS.NET to be used for
developing and maintaining many small web projects.

 

[recoil]

#1. .NET Code far surpasses Java in the "build once run anywhere
department". Anybody that has ever tried to deploy JSP servlets knows
what I am talking about.
You build .NET code once and it runs anywhere. I think the only major
discrepancy I can think of is regarding Server.MapPath. On windows 2003
it does not append a / at the end so if you do not do a check for it to
exist with EndsWith and append it if it is not there your application
may fault.
Any other programming issues that come up very well could be related to
an initial flawed design. It really depends upon where you are going
but for the most part i can develop web applications on xp pro and
deploy to any of MS flagship server systems that support .net, 2k, xp
pro and 2k3 server

#2 X-copy works absolutely fine here. What x-copy DOES NOt do is it
does not "x-configure" notice the word copy and not configure in the
name of the x-copy utility. You must still setup and configure your IIS
application.
#3 - If your solution takes a long time to load I would recommend you
buy better hardware. I develop on an old AMD XP 1800 with 1.5GB of ram.
a 200+ file web project takes 20-30 seconds to load. Most other
projects are almost instantaneously. Enough time to alt tab to another
application, chit chat or queue up some music.
#4 - Testing and debuggin. Testing and debugging .net applications is a
charm compared to any other web platform I have debugged for.
Integration with Source Safe is buggy but imho all source safe
integration has its problems and you learn to work with the source safe
of your choice, and my choice is not really VSS. i prefer CVS over it,
but that is just my preference. Related to deploying and debugging I
love it. The only thing I would like to see is Remote debugging to be
more reliable, however I have so seldom ever had a need for remote
debugging as any problem that occurs usually happens on the dev
machine.


Not really sure what your experience is but I've been working with asp,
php, jsp and i've dabbled with CF. For me, Of all the languages and
frameworks available asp.net is by far the most feature rich both in
what it brings to the table and its development offerings. YMMV

I personally think that once you understand the fundemental concepts
behind OOP and the new .NET architecture you will thankfully cast aside
your PHP/ASP include file hacks and embrace the new reusability model
that .NET promotes.

 

[Hans Kesting]

Being a ASP developer for a consultant company thinking of starting
developing with ASP.NET I have read literally hundreds of web pages and posts
in discussion forums on the Internet to get an idea of what we will need to
adapt to. I have read Microsoft’s “Team Development with Visual Studio .NET
and Visual SourceSafe†and tried to set up a development environment as
recommended using the “Isolated modelâ€. However, many questions regarding the
development environment as well as the technique itself still remain
unanswered. I’ll try to summarize some of them here and hopefully someone
will be able to give me the answers I can’t find myself.

1. Development
I simply cannot understand how the recommended model can be to develop an
application on Win XP with IIS 5 when the application is to be deployed on a
Win 2003 Server with IIS 6. To me this is bound to cause problems. In
addition - security settings, installed software etc. is likely to vary on
different developer workstations as well as on different servers.

With .net you are one step removed from OS and webserver: IIS passes
a request for an aspx page to the aspnet process. As long as both
(W2k3 and XP) versions function the same, there should be no problem.

2. Deploying
Microsoft proudly promotes the “x-copyâ€-deployment but they haven’t seemed
to consider that a new web application deployed with x-copy won’t run without
manually changing settings in the IIS.
The “Copy projectâ€-functionality seems mostly as a joke to me. Having read
about FPSE security issues I wouldn’t even consider installing it on a public
web server so that leaves the file share option which of course is nothing
else but x-copy with some file type exclusions. And how they decided not to
include FTP as an option is beyond my understanding.
So, I’m left with something called Web setup projects. But from what I
understand, they won’t install under anything else than localhost. In other
words I cannot use it on servers hosting multiple web sites.

plain xcopy is a bit difficult for websites. What we do: first create
(in IIS) the site, then copy "everything" (using "copy project" from
development to test/staging, and then ftp for copying to an external
live server). Watch out for web.config, as that file probably contains
site specific info.

3. Working with multiple web sites
We are a consultant company and we work with multiple web sites for many
different clients. Maybe I haven’t understood how we should set up the
environment but we are leaning towards having one solution for each one of
the web sites we work with.
After a web site is released the majority of our work consists of relatively
small changes and fixes. Having to quickly jump between the different
solutions and waiting seemingly endlessly for the solution to load every time
we need to make small changes feels as a terrible waste of valuable time and
money.

One solution per site (plus maybe more solutions for framework code)
seems to be the way to go.

4. Testing and debugging
Having mentioned that we often make small changes – moving to ASP.NET feels
as the time for making and testing these changes will dramatically increase
the time needed. First of all the entire project will have to load into
VS.NET. Then I make some changes to a code behind file which will result in
the entire project will need recompiling. The compilation will need to occur
every time I test a never so small change and I will have to wait at least
15-20 seconds before I will be able to view the changes. When I’m satisfied
with the changes (tested on my local development workstation) I will have to
compile it on a testing server using our VSS database as source and if we
consider it to be functional I will somehow try to deploy it to a public web
server.

I seriously wonder if Microsoft really has considered VS.NET to be used for
developing and maintaining many small web projects.

asp.net works best for larger (complicated) sites. Then you *will* have
coding and maintainability benefits. For "many small" sites, maybe you
are better off to stick with asp (you can change things on the server
with Notepad and see the changes immediatly)

 

[Alvin Bruney [ASP.NET MVP]]

It seems to me that you are not sold on the ASP.NET idea at all. Your
questions seem to be thinly disguised rants about .NET. You may want to
exercise your choice of remaining with ASP, otherwise you may need to
embrace the paradigm shift and all the benefits it bring.

--
Regards,
Alvin Bruney

[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
------------------------------------------------------------

 

[Guest]

:

You build .NET code once and it runs anywhere.

Sounds good, but what about installed components, Active Directory, FS
Security etc.

notice the word copy and not configure in the name of the x-copy utility.

Naturally x-copy won't provide any configuration. What I can't understand is
why there aren't any reliable integrated deployment tools.

a 200+ file web project takes 20-30 seconds to load. Most other
projects are almost instantaneously. Enough time to alt tab to another
application, chit chat or queue up some music.

Well, many jumps between two large projects and the time adds upp. And chit
chating or listening to music is hardly what our clients pay us to do.

#4 - Testing and debuggin. Testing and debugging .net applications is a
charm compared to any other web platform I have debugged for.

Don't get me wrong. The debugging functionality seems extreemly useful.
What I'm trying to say is that compared to ASP - the time to make small
changes will increase dramatically because the entire project will have to
recompile every time I test a never so small change.

Integration with Source Safe is buggy but imho all source safe
integration has its problems and you learn to work with the source safe
of your choice, and my choice is not really VSS.

Yes, VSS is a chapter of it's own. Looks like something from Win 3.11. But
it is still the recommended software in MS Whitepapers.
Can CVS be integrated in VS.NET and does it work well?

I personally think that once you understand the fundemental concepts
behind OOP and the new .NET architecture you will thankfully cast aside
your PHP/ASP include file hacks and embrace the new reusability model
that .NET promotes.

I have every reason to belive that ASP.NET and the capabilities it gives me
as a developer truly are great but I will need to be comfortable with the
development environment before I embrace it.

 

[Kevin Spencer]

1. Development

I simply cannot understand how the recommended model can be to develop an
application on Win XP with IIS 5 when the application is to be deployed on
a
Win 2003 Server with IIS 6. To me this is bound to cause problems. In
addition - security settings, installed software etc. is likely to vary on
different developer workstations as well as on different servers.

IIS is IIS. Windows is Windows. Now, there are some security settings that
are different, but that is simply a matter of knowing what they are. And
nobody says you can't develop on a Windows Server OS. I've done it before,
many times.

2. Deploying
Microsoft proudly promotes the "x-copy"-deployment but they haven't seemed
to consider that a new web application deployed with x-copy won't run
without
manually changing settings in the IIS.

What settings? Other than creating an application, there's really nothing to
it.

3. Working with multiple web sites
We are a consultant company and we work with multiple web sites for many
different clients. Maybe I haven't understood how we should set up the
environment but we are leaning towards having one solution for each one of
the web sites we work with.
After a web site is released the majority of our work consists of
relatively
small changes and fixes. Having to quickly jump between the different
solutions and waiting seemingly endlessly for the solution to load every
time
we need to make small changes feels as a terrible waste of valuable time
and
money.

Assuming that you have to make a small change, there's no need to load the
entire solution every time. For example, let's say that you architected a
20-story building. A window on the 20th floor is broken. You don't need to
take the whole building back to the shop, just the window. If it's a change
in a Template file, make the change and deploy the Template file. If it's a
change in a DLL, make the change and deploy the DLL.

4. Testing and debugging
Having mentioned that we often make small changes - moving to ASP.NET
feels
as the time for making and testing these changes will dramatically
increase
the time needed. First of all the entire project will have to load into
VS.NET. Then I make some changes to a code behind file which will result
in
the entire project will need recompiling. The compilation will need to
occur
every time I test a never so small change and I will have to wait at least
15-20 seconds before I will be able to view the changes. When I'm
satisfied
with the changes (tested on my local development workstation) I will have
to
compile it on a testing server using our VSS database as source and if we
consider it to be functional I will somehow try to deploy it to a public
web
server.

See my response to number 4.

A lot of what you're complaining about is attenuated by good
architecture/design. If you design your app right, it's not hard to debug,
not hard to deploy, and most importantly, not hard to maintain and upgrade.

I seriously wonder if Microsoft really has considered VS.NET to be used
for
developing and maintaining many small web projects.

Hmm, considering how successful ASP.Net is, and that Visual Studio.Net is
nearly universally considered to be the best development platform
manufactured, it would seem more logical for you to question your own
understanding, rather than Microsoft's.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Ben Strackany]

I went through the same issues you are facing now. It seems like you are not
necessarily saying ASP is better but that you were expecting more than you
found.

My comments below

1. Development
I simply cannot understand how the recommended model can be to develop an
application on Win XP with IIS 5 when the application is to be deployed on a
Win 2003 Server with IIS 6. To me this is bound to cause problems. In
addition - security settings, installed software etc. is likely to vary on
different developer workstations as well as on different servers.

Developing on your own machine provides some big benefits -- easier
debugging, isolation from other changes/code (so they don't break you & you
don't break them), controlled environment. However, you are right in that
your workstation is not a "clone" of production, and so there may be issues
when migrating. That's why we, like most houses, have a dedicated
qa/testing/staging environment that is Win2003/IIS6, very similar to
production. Develop locally, integrate w/ other code, build, deploy to qa,
test, promote. That's oversimplifying it a bit, but anyhow. Plus, you will
find that most of the "bugs" found have nothing to do w/ the fact that your
local machine is XP running IIS5.

2. Deploying
Microsoft proudly promotes the "x-copy"-deployment but they haven't seemed
to consider that a new web application deployed with x-copy won't run without
manually changing settings in the IIS.
The "Copy project"-functionality seems mostly as a joke to me. Having read
about FPSE security issues I wouldn't even consider installing it on a public
web server so that leaves the file share option which of course is nothing
else but x-copy with some file type exclusions. And how they decided not to
include FTP as an option is beyond my understanding.
So, I'm left with something called Web setup projects. But from what I
understand, they won't install under anything else than localhost. In other
words I cannot use it on servers hosting multiple web sites.

I'm not sure what you're looking for. Some sort of wizard? We use robocopy
instead of xcopy, but I would rather copy files than log onto production
boxes to register COM DLLs. You can look into nant & other build tools. I
will admit that there are some loose ends that MS could take care of, like
an integrated ability to define environment-specific values or settings, so
that you truly can xcopy w/o having to change IIS settings, make vdirs, etc.
So there are some issues but I don't see them being worse than ASP.

3. Working with multiple web sites
We are a consultant company and we work with multiple web sites for many
different clients. Maybe I haven't understood how we should set up the
environment but we are leaning towards having one solution for each one of
the web sites we work with.
After a web site is released the majority of our work consists of relatively
small changes and fixes. Having to quickly jump between the different
solutions and waiting seemingly endlessly for the solution to load every time
we need to make small changes feels as a terrible waste of valuable time and
money.

I would go for larger solutions. Or, try to split the UI from the business
logic, & put the files you're changing a lot (i.e. HTML for headers,
footers, etc.) into their own projects/solutions. So if 90% of your change
requests a header/footer changes, split the headers & footers for all your
clients into their own project/solution/directory, & just have that thing
loaded all the time. Why unload the project...just keep it in VS.NET all the
time. Or run multiple VS.NET instances.

Also, be aware that VS.NET is a resource hog. You need a fast machine, much
faster than what you'd need w/ Interdev. I'd recommend 3ghz p4 w/ HT, 1gb
ram, fast HD. The upside is that VS.NET (plus the myriad of useful plugins)
will help your productivity if your machine can handle it.

4. Testing and debugging
Having mentioned that we often make small changes - moving to ASP.NET feels
as the time for making and testing these changes will dramatically increase
the time needed. First of all the entire project will have to load into
VS.NET. Then I make some changes to a code behind file which will result in
the entire project will need recompiling. The compilation will need to occur
every time I test a never so small change and I will have to wait at least
15-20 seconds before I will be able to view the changes. When I'm satisfied
with the changes (tested on my local development workstation) I will have to
compile it on a testing server using our VSS database as source and if we
consider it to be functional I will somehow try to deploy it to a public web
server.

You may want to restructure your process to not do build & deployments for
every single fix. I will admit that the build/deployment overhead will be
large if your average code change takes you 5 minutes & you build & deploy
for every change. You could look into in-line ASP.NET code instead of code
behind. Also, changes made to the HTML/ASPX/ASCX files (i.e. not the code
files) can be tested immediately -- you don't have to build the whole
project & dlls.

I seriously wonder if Microsoft really has considered VS.NET to be used for
developing and maintaining many small web projects.

It is possible that ASP.NET won't work for your situation, especially if you
are used to being able to make small changes to code files on a central
server & immediately testing them. You don't have to code & test ASP.NET on
local machines -- you can do it all on a central (fast) box. It just makes
certain things easier. But nothing (not even .net) is a panacea. And there's
nothing to say you can't stick with ASP. Even huge sections of microsoft.com
are still in ASP.

 

[Guest]

Let me begin to say that even though I didn't get the answers i hoped for
("It's simple just do it this way") - these answers seem to be very
insightful.

With .net you are one step removed from OS and webserver: IIS passes
a request for an aspx page to the aspnet process. As long as both
(W2k3 and XP) versions function the same, there should be no problem.

Ok, maybe my concerns are exaggerated but we've already experienced problems
with some third party components.

plain xcopy is a bit difficult for websites. What we do: first create
(in IIS) the site, then copy "everything" (using "copy project" from
development to test/staging, and then ftp for copying to an external
live server). Watch out for web.config, as that file probably contains
site specific info.

This work flow seems to be the one we're aiming for. Does "Copy project"
copy only changed files or does it replace every neccicary file? Can you
recommend any good FTP-client which has appropriate filters for neccicary
files?

asp.net works best for larger (complicated) sites. Then you *will* have
coding and maintainability benefits. For "many small" sites, maybe you
are better off to stick with asp (you can change things on the server
with Notepad and see the changes immediatly)

That's was what we were beginning to fear. Perhaps we we'll have to
reconsider which web sites to move to ASP.NET.

 

[Guest]

It seems to me that you are not sold on the ASP.NET idea at all. Your
questions seem to be thinly disguised rants about .NET. You may want to
exercise your choice of remaining with ASP, otherwise you may need to
embrace the paradigm shift and all the benefits it bring.

You've got me all wrong. I truly am interrested in the technique and
framework itself. I can really see the potential. What I need to get
comfortable with is the development environment.

 

[Guest]

IIS is IIS. Windows is Windows. Now, there are some security settings that

are different, but that is simply a matter of knowing what they are. And
nobody says you can't develop on a Windows Server OS. I've done it before,
many times.

I can't really se how it can be an option that every developer in a company
should have a server OS installed but prehaps I'm wrong.

What settings? Other than creating an application, there's really nothing to
it.

I any case the developer would need to administrative access to the testing
web server as well as the public server. I'm not saying that this was any
different in ASP I'm just saying that only using x-copy or simular won't be
enough to deploy a web project.

Assuming that you have to make a small change, there's no need to load the
entire solution every time. For example, let's say that you architected a
20-story building. A window on the 20th floor is broken. You don't need to
take the whole building back to the shop, just the window. If it's a change
in a Template file, make the change and deploy the Template file. If it's a
change in a DLL, make the change and deploy the DLL.

Is there a way to load a single file, change it and then recompile without
loading the project/solution?

Hmm, considering how successful ASP.Net is, and that Visual Studio.Net is
nearly universally considered to be the best development platform
manufactured, it would seem more logical for you to question your own
understanding, rather than Microsoft's.

Well, from what I've heard from Microsoft, ASP.NET isn't nearly as
successful as they had predicted and they have been wondering why. VS.NET
might the best development platform but perhaps not for small web projects
and my guess is that that's the unfortunate reason why many developers still
stick to classic ASP.

 

[Guest]

IIS is IIS. Windows is Windows. Now, there are some security settings that

are different, but that is simply a matter of knowing what they are. And
nobody says you can't develop on a Windows Server OS. I've done it before,
many times.

I can't really se how it can be an option that every developer in a company
should have a server OS installed but prehaps I'm wrong.

What settings? Other than creating an application, there's really nothing to
it.

I any case the developer would need to administrative access to the testing
web server as well as the public server. I'm not saying that this was any
different in ASP I'm just saying that only using x-copy or simular won't be
enough to deploy a web project.

Assuming that you have to make a small change, there's no need to load the
entire solution every time. For example, let's say that you architected a
20-story building. A window on the 20th floor is broken. You don't need to
take the whole building back to the shop, just the window. If it's a change
in a Template file, make the change and deploy the Template file. If it's a
change in a DLL, make the change and deploy the DLL.

Is there a way to load a single file, change it and then recompile without
loading the project/solution?

Hmm, considering how successful ASP.Net is, and that Visual Studio.Net is
nearly universally considered to be the best development platform
manufactured, it would seem more logical for you to question your own
understanding, rather than Microsoft's.

Well, from what I've heard from Microsoft, ASP.NET isn't nearly as
successful as they had predicted and they have been wondering why. VS.NET
might the best development platform but perhaps not for small web projects
and my guess is that that's the unfortunate reason why many developers still
stick to classic ASP.

 

[Guest]

I went through the same issues you are facing now. It seems like you are not

necessarily saying ASP is better but that you were expecting more than you
found.

You've understood me correct in the sense that I'm convinced that ASP.NET is
far more capable than ASP and I'm quite satisfied with what I've tested so
far. I'm not really saying that I expected more from ASP.NET but rather from
information on how to implement the development environment and work flow.

Developing on your own machine provides some big benefits -- easier
debugging, isolation from other changes/code (so they don't break you & you
don't break them), controlled environment. However, you are right in that
your workstation is not a "clone" of production, and so there may be issues
when migrating. That's why we, like most houses, have a dedicated
qa/testing/staging environment that is Win2003/IIS6, very similar to
production. Develop locally, integrate w/ other code, build, deploy to qa,
test, promote. That's oversimplifying it a bit, but anyhow.

That is exactly how we have set up our environment and work flow. But I
would actually preferr buildning the project onto the testing server from
source files in VSS rather than files on my local development machine. This
would ensure the that build has the latest versions of every part of the
project. Furthermore, I would like to be able to initialize that build from
my machine.

Plus, you will
find that most of the "bugs" found have nothing to do w/ the fact that your
local machine is XP running IIS5.

Ok, but what other problems may occur. We've had problems with third party
components but to be perfectly honest I can't say that it isn't due to lack
of understanding on how to implement them in a project/sollution in a correct
manner.

I'm not sure what you're looking for. Some sort of wizard? We use robocopy
instead of xcopy, but I would rather copy files than log onto production
boxes to register COM DLLs. You can look into nant & other build tools. I
will admit that there are some loose ends that MS could take care of, like
an integrated ability to define environment-specific values or settings, so
that you truly can xcopy w/o having to change IIS settings, make vdirs, etc.
So there are some issues but I don't see them being worse than ASP.

Something that combines my preferred work flow (described above) and that
adds and configures neccicary applications in IIS.

I would go for larger solutions. Or, try to split the UI from the business
logic, & put the files you're changing a lot (i.e. HTML for headers,
footers, etc.) into their own projects/solutions. So if 90% of your change
requests a header/footer changes, split the headers & footers for all your
clients into their own project/solution/directory, & just have that thing
loaded all the time. Why unload the project...just keep it in VS.NET all the
time. Or run multiple VS.NET instances.

Should I consider centeralizing more functionality from different web sites
into a common solution/project to keep the different web projects smaller?

Also, be aware that VS.NET is a resource hog. You need a fast machine, much
faster than what you'd need w/ Interdev. I'd recommend 3ghz p4 w/ HT, 1gb
ram, fast HD. The upside is that VS.NET (plus the myriad of useful plugins)
will help your productivity if your machine can handle it.

That contradicts what read earlier in this thread. But I must say that what
you write seems more like what I've experienced so far.

You may want to restructure your process to not do build & deployments for
every single fix. I will admit that the build/deployment overhead will be
large if your average code change takes you 5 minutes & you build & deploy
for every change.

Are you talking about accumulating fixes into fewer new releases?

You could look into in-line ASP.NET code instead of code
behind. Also, changes made to the HTML/ASPX/ASCX files (i.e. not the code
files) can be tested immediately -- you don't have to build the whole
project & dlls.

I'm not sure, but wouldn't I miss out on large parts of the coding aid
(IntelliSense) and Object oriented features when using in-line ASP.NET?

It is possible that ASP.NET won't work for your situation, especially if you
are used to being able to make small changes to code files on a central
server & immediately testing them.

Perhaps, but it is really tempting to start using the benefits of ASP.NET. I
realize that we need to make changes in how we work - I just want the changes
made the best way possible.

And there's
nothing to say you can't stick with ASP. Even huge sections of microsoft.com
are still in ASP.

Well, I think I've realized that many smaller projects will still benefit
from the simplicity of classic ASP.

 

[recoil]

It is probably by far, the most flexible web framework I have ever
seen. It allows developers to use both old and new practices,
simultaneously or separately.

 

[Kevin Spencer]

Hi Linus,

I can't really se how it can be an option that every developer in a
company
should have a server OS installed but prehaps I'm wrong.

I didn't recommend using Windows Server as a development platform. I only
mentioned that it is an option, one that I've used before, for the same
reasons. However, I was working on a porject using Direct3D and needed a
better video card. The driver for the card wouldn't run on Windows Server,
but on XP. So I slicked my machine and installed XP Pro, which I've been
using ever since without issue.

I any case the developer would need to administrative access to the
testing
web server as well as the public server. I'm not saying that this was any
different in ASP I'm just saying that only using x-copy or simular won't
be
enough to deploy a web project.

Well, darn. I've been doing it all wrong for years!

Is there a way to load a single file, change it and then recompile without
loading the project/solution?

A project represents a DLL. A solution is a collection of projects. So,
assuming that the "single file" you're referring to is all the code for an
assembly, yes. Otherwise, no.

Well, from what I've heard from Microsoft, ASP.NET isn't nearly as
successful as they had predicted and they have been wondering why. VS.NET
might the best development platform but perhaps not for small web projects
and my guess is that that's the unfortunate reason why many developers
still
stick to classic ASP.

I can tell you why. How may single-engine pilots are there in the world? How
many commercial pilots are there? In fact, there are many times more
single-engine pilots than commercial pilots. Why? Because commercial planes
are extremely powerful, and require more skill to pilot. ASP.Net is FAR more
powerful than ASP, and FAR more complex as a result. The advent of
server-side scripting technologies such as ASP and PHP enabled a whole bunch
of people to become "professional" programmers. As a result, there is a
whole nation of shade-tree programmers out there who are drowning in the
world of real programming now.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Guest]

So basically what you're saying is that if one started of with ASP and have
some issues on how to adapt to a new development environment and work flow,
one is not worthy of moving on to ASP.NET?

 

[Kevin Spencer]

No. Basically what I'm saying is that, if you can't parse what I'm saying
correctly, and make leaps of assumption on a regular basis, how can you be a
good programmer?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[bsarka]

I'm jumping in here because I have some questions similar to those
expressed by Linus. I've been working with and teaching a variety of
languages and Web development activites for quite some time, but all
related to open source or Java technologies. I'm making the shift to
C# and VS.NET and am having some of the same problems described in this
thread. I hope to get a pointer or two in the right direction. I've
been using AppDev, and Amit Kalani books for study and practicing
everything on a variety of application for use at the school. I really
(I mean *really*) like C# and VS.NET as long as the projects stay on my
development workstation and are viewed from that workstation. I can't
seem to find any configuration of IIS settings, application settings,
firewall client settings, or ISA 2003 configuration that will let
anybody else visit the applications hosted on my development computer.
Also, If I create a Web Setup project and install the finished ASP.NET
app on another server, It is accessable by no one.
I would really appreciate some direction (books, URL, words of wisdom,
etc) that will make actually using these fine solutions possible. It
just doesn't seem nearly as automatic and intuitive as any thing else
in VS.NET.

Being a ASP developer for a consultant company thinking of starting
developing with ASP.NET I have read literally hundreds of web pages and posts
in discussion forums on the Internet to get an idea of what we will need to
adapt to. I have read Microsoft's "Team Development with Visual Studio .NET
and Visual SourceSafe" and tried to set up a development environment as
recommended using the "Isolated model". However, many questions regarding the
development environment as well as the technique itself still remain
unanswered. I'll try to summarize some of them here and hopefully someone
will be able to give me the answers I can't find myself.

1. Development
I simply cannot understand how the recommended model can be to develop an
application on Win XP with IIS 5 when the application is to be deployed on a
Win 2003 Server with IIS 6. To me this is bound to cause problems. In