Re: Visual Studio "New Project" or "New Website"

On Jul 20, 9:36 am, "John Saunders" <n...@xxxxxxxxxxxxxxxx> wrote:
John,

I appreciate that input, since I'm pretty much a newbie at this. But
I have a couple questions:

1) Why do you say that a "WebSite" is not suitable if you have
significant server-side code? What can you do with a Web-Application
that you can't do with a WebSite (providing you use "Publish WebSite,
which actually generates the DLL - I agree, I don't want my C# code
out there on the site being built at execution time.)? Please
understand, that is a serious information-seeking question, not an
argumentative one.

Let me answer this question with a question. Do you have a background in
software engineering? Are you familiar with the Software Development Life
Cycle (SDLC)? Unit testing, QA testing, nightly builds, source control?
These are all things that are available to all other kinds of application.
They're not available for web sites, because they're not applications.

For instance, you correctly raise the fact that the Publish command can
cause your code to be compiled first, and can even compile or partially
compile your pages. That's great, but what next? Do you publish to your live
site, or should your QA organization test it first, possibly on several
different machines at the same time? In that case, which code are they
testing? Did you publish it once, then copy to the different QA machines, or
do you (manually) publish to each QA system, recompiling the code each time
(producing slightly different code each time you publish)?

Another thing is automated unit tests, or anything else that requires the
code to be compiled first.

I guess my overall thought is that this "Web Site" paradigm started off
being for developers of their company web site, then anything else was added
on top of that to handle situations that weren't that simple. But we already
had a paradigm that worked for all other kinds of application, and was
working well for web applications before VS2005, and works well for web
applications since VS2005 SP1. What was the point of the change? It didn't
solve any problems I had, and I had been developing ASP.NET Web Applications
since 2002. This led me to conclude that the problems solved by Web Sites
must have been problems I had not encountered since 2002 - the solutions
must have been for people doing a different kind of development. Since I've
always built applications, this must have been for people who were not
creating applications.

I think they named the paradigm for the problems they intended it to solve.
It's for web sites, not for web applications. It may work for your web
application, but you'll eventually hit issues where the answer is, "but if
you knew you were creating an application, then why did you start by
creating a web site?"

2) What about all the features/tools that just don't seem to work for
Web Applications? I had a dickens of a time trying to get things to
build when I was doing it as a Web Application, to the point that I
scrapped the whole project and started it over as a WebSite. Is there
a way around it to make those features work right?

I don't know what features or tools you're referring to. Any such tools
would have been those that were introduced with Visual Studio 2005. Since
web applications were created quite successfully before VS2005, at the very
least you have workarounds available - just do what we were doing before
VS2005.

However, I have found several cases where the tool that didn't work was a
"Web Site" tool. The confusion was that when VS2005 came out, the intention
was for web sites to replace web applications. This implies that the web
site documentation replaced the web application documentation. This has not
entirely been corrected, as the materials for new developers talk about web
sites. You may have learned to do use a web site tool that does not work on
web applications, and may now be unaware of how to do the same thing with
web applications.

If Microsoft had originally intended to have web sites and web applications
coexist, this would not have been a problem. They would have had the same
set of commands work with both. Instead, they get a mess.

--
John Saunders | MVP - Connected System Developer

Thanks, John. I pretty much agree with you. Yes, I AM developing an
application, that just happens to run on a web site. And like I said,
the first time I started it, I selected "ASP.NET Web Application".
And I particularly DONT like having my code in Inetpub\wwwroot instead
of in my project directory.

You said
I don't know what features or tools you're referring to.

The main thing was that I was trying to follow Scott Mitchell's Data
Access Tutorials, and he'd say something like "Create a DAL folder and
a BLL folder in the App_Code directory. Then right click the BLL
folder and Add A New Item, and select a class". (to create a new
class of business logic layer access to a table, for example). And I
would do that, right the code, but then I simply could NOT get it
included in the build. I would select Build, and it would go through
and say Build succeeded, but the classes that I had added were nowhere
to be found. I even deliberately introduced syntax errors into the
code to try determine if the Build process was even looking at it, and
it wasn't. I went through hours of agony with that on several
different files. Sometimes if I moved the files up to the top level,
it would see them, sometimes it wouldn't. When I recreated it as a
Website, it didn't have any problem with any of that. It instantly new
about everything I put anywhere in the App_Code tree.

The other thing that was very helpful, though maybe not worth all the
agravation, is the Website Administration tool that configures your
web.config and your user/roles database for security. If you know
what you're doing, you can probably just as well do that by hand, but
it's nice to have when you're trying to figure out the ropes. It's an
item on the "Website" menu, which, guess what, isn't there if you're
not doing a Website.

And, finally, the "trace" web.config element simply did not seem to
work when was running a web application. But I may not have known
what I was doing, either. That was when I was very very new at
ASP.NET, and I haven't really used it since except to see that it
worked.
.