This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
ASP.NET: Web Site or Web Application?
I have noticed that there is clearly a difference in what you get when you fire up Visual Studio 2008 and choose 'New Project' -> 'ASP.NET Web Application' instead of 'New Web Site' -> 'ASP.NET Web Site'. For example if you choose 'Project', then you can compile to .dll and each page gets a *.aspx.designer.cs codebehind file.
1) Why do we have these two different project types?
2) Which do you prefer?
3) Why would I choose one over the other?
4) What's the deal with the *.aspx.designer.cs files?
They have different purposes.
A website is a site with content that is likely to change over time, that is the pages themselves will change. There is no actual project file and the site is deployed simply as a set of files.
An application is a site where the content is just the application, the dynamic part will mainly be in persistant store such as a database. It will have more complex logic since its likely to represent a set of forms for data entry as much as a means to examine content. It has a project file to more strictly control its configuration and its code deployed as a compiled dll.
1) The 'web site' model was introduced with ASP.NET 2.0, the 'web application' model was the project type of the original .net framework. They both have different uses (see below).
2) It depends on the context. A good example is if you are selling a software product, you may wish to use a 'web application' project because it naturally lends itself to cleanly compiled code.
3) See above, personal preference, maintenance characteristics. An interesting thing that a 'web site' allows you to do that can get you in a lot of trouble is making arbitrary changes to code-behind (typically a *.cs or *.vb) file in notepad while the website is running.
4) The designer.cs file is used to store the auto-generated code. "This code was generated by a tool."
MSDN Article describing the differences
Similar stackoverflow question
I won't duplicate the definition of the 2, since that just got answered.
So why use one over the other?
Web Site lets you treat it like a PHP or classic ASP site, where you can make inline changes that take effect immediately.
Pros
You can make tweaks to the site right on the web server
Deploying is as simple as copying the folder
Cons
If you are not making the changes right on the live site, you can get into change management problems, where you forget to keep all your files in sync
You can get runtime syntax errors displayed to your end users, since the only way to check is to manually run every page
Web Application lets you treat it more like how you would a desktop application - there is one deployable that is compiled on your machine.
Pros
Clear, structured change management. You cannot accidently mix code from two different versions. This can be important when there are 2 people involved - one writing the code, and one responsible for putting files on the server.
Because you compile it on your machine, everything gets syntax checked at that point*
Cons
Deployment is a little more involved then just copying the folder from your development machine. However the usage of the "Publish" command greatly simplifies the process of compiling and putting together what files should be copied to the web server.
Any changes need to be done on your machine, compiled, and a whole new version sent to the web server*
*The aspx/html files are only syntax checked if you turn this on in your build options though. It is also possible to edit these files on the server unless they are compiled into your project.
The simple answers are as follows:
New Web Site - creates code behind pages that are compiled at the server when page is requested.
New Web Project - creates pre-compiled pages into one or more assemblies (entire site even), and deployed on server.
Scenario #1 - If a hacker obtains your code-behind files, any database passwords are exposed. These pages are compiled at the time they are requested. You can choose to pre-compile everything into a large assembly. If not, there is more load on the server.
Scenario #2 - if a hacker obtains your assemblies, they will be obfuscated. Obfuscated assemblies are harder to crack. These assemblies are pre-compiled, thus reducing load on the server.
For more information:
Introduction to Web Application Projects
3) WebApplication projects are buildable by MSBuild. WebSites are not (without a lot of tweaking). If you use TeamSystem with automated builds then this is the way to go.
THe biggest difference that no one has really mentioned (except touched on by Annakata) is that with the model where everything is compiled into a single DLL, your have complete control over the classes that your application generates. You know where they are and can always reference them from anywhere else in the application.
With the single page model, you can't do this. You have to get around it by creating "stub" classes in the AppCode directory, and inheriting those in your pages, but even that isn't ideal, and add complexity.
You'll only really come up agaist this stuff if you're trying to develop an intricate dynamic site, where you dynamically load lots of user-controls at run-time based on content. Then, the differences are painfully clear - hence much of our development stalled on ASP 1.1 until we could go back to the same model later.
Nich
Speaking from experience with both: "Web Sites" are used where there is no testing methodology in place, no CI server, and a culture that encourages and promotes "hotfixes" to specific pages regularly. "Web Applications" are the de facto standard where proper software methodologies are followed and there is unit testing (if not full TDD) and a CI server with a focus on writing clean code and finding bugs before the need for a "hotfix" arises.
Sites are the 2003 original .NET way of doing web dev. In my experience they are extremely problematic since lacking a project definition they can't be reused and have issues with modular coding, have issues with TeamSystem integration and namespacing. The one-to-one bind with a domain and lack of real publishing abstraction creates maintenance problems down the line.
The ancient "classic" ASP way of !codebehind is a serious problem because it again impairs code reuse and testing, and the often cited benefits of allowing hot fixes - if ever called upon - is actually a massive signal that you have a failing development process. The ability to hot fix is of course better than not being able to, but it's something you never want to invoke.
You might say that the problems with the web site model were great enough that MS gave us web apps instead. Personally I would never use them for anything beyond demo code... no actually I wouldn't even do that.
At first there was a Web application project (it behaved similarly to the current Web site project). They changed it to reflect what some users requested. However people wanted the old functionality back so they re-introduced the Web site project which behaves like the original Web application project.
I -- and my workplace -- prefer the Web site project
We like that the files of the website are the files in the file system (no need to add them manually)
No idea
Here's two articles I found about both:
http://damieng.com/blog/2008/02/07/web-site-vs-web-application
http://www.dotnetspider.com/resources/1520-Difference-between-web-site-web-application.aspx
Note: A lot of the issues with Web sites have been resolved with the Web deployment project
Update: Fixed the point 1, Web application was there first
If your work needs to leverage oo language features (class hierarchies, namespaces) or if you need to reuse common code among projects (data access, class libs etc.) then the web application project is the only way to go.
The website project (the clue is in the name) is only really good for non-complex 'brochureware' sites (where the pages consist of static content) as opposed to web applications.
There is very little difference, and I would highly recommend using the Web Site model.
The main difference is for a website, some files need to be placed in certain directories (code files need to be placed in the 'App_Code' directory), besides that, it's pretty straight forward.
If having compiled code for deployment is important to you, and you want a single DLL (opposed to the several that are created when you do a normal publish for a web site), then you'll want to get this add-on: http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx
Related
Good day
I moved to another company from a previous one, they task me to modify a existing system with a horrific code, but with patience and dedication, I managed to update the system, but I was shocked that they told me to put the source code on the system and it will be the one that the app in IIS will read. It will read the debug folder of the project. On my previous employer what we do is to publish the file, and that be one to read, but on my current employer,they put the whole source code on the web server.
Is this okay? Or am I right it's a bad practice, well other frameworks put the whole file on the server, so it should be good? Is it?
Thanks and regards
As pointed out, this was a common set.
And after all, why bother to do some whole big publish when you JUST need to modify say a bit of markup in a web page.
So, for those who have the web server "on site", then often they would point VS to the site, and open it directly.
So, to manage/use/work with such a project?
You don't use from vs file->open project, but in fact use file->open web site. At this point, it is assumed you browse directly to the folder that holds the web site - often the live web site.
There are several significant issues to be aware of.
the app in IIS will read. It will read the debug folder of the project.
That is a not a correct assumption, or even correct view. There is no such thing as a "debug" folder. Then again, be it a console app, desktop, or whatever? Sure, when you COMPILE code, it goes to the bin/debug or bin/release folder.
But, you failing to grasp that by using the "web site" option, VS does NOT do the code compile!!! (IIS does!!!). While testing in vs, then vs will do the compile, but if you are modifying the web site directly, then all you have to do is open a web page, and when you hit ctrl-s, you are done - it is now live. And this ALSO applies to code behind.
So, you can open up say the code behind page. Modify one line of code and hit ctrl-s - you are done!!!
So, yes, as you note, a lot of web site(s) were managed this way.
So, the upside is no real deployment is required. And for a larger site, this actually can be a benefit.
However, the downsides are significant, and you VERY much need to be aware of these issues.
First up, careful if you adopt Rosyln extensions. That means your testing/debug/playing/developing code using and allowing VS to compile the code.
however, when you deploy (or edit "live"), then VS is NOT doing the code compile anymore. And this ALSO means then that the web site has both aspx pages, and ALSO the source code pages MUST ALSO exist!!! But often the web site and version of IIS will for example not know about Rosyln extensions etc., so you HAVE to be VERY careful, since it not VS that compiles the code, it is IIS that does this!!
In fact EVEN with a web site application, the "app_code" can and will be compiled by IIS. (I had simple code break when IIS re-compiles that code - it was not aware of say free form text strings that Rosylin allows). So, for a web site application, I actually create my own folder called MyCode and for each code module/class inside, then I right click and choose "compile" for the build options. That way IIS NEVER gets to compile my code!!!).
Now, of course the other option is what we call a "asp.net web application".
In that case, when you publish, then the code is compiled for you, the code behind pages is stripped out, and only the aspx pages remain (and are copied/deployed) to the web site. While this is more "pain" since even a tiny one-line change of code requires a WHOLE web site re-compile and re-deploy.
However, while there is this "increased" pain, there are also significant advantages.
You can have multiple projects in the one project.
you can add and reference other projects assemblies - not have to move/copy the assembles into the bin folder.
So, with better skills, then of course you often build code libraries and systems - systems that ALSO the web site requires. So, a asp.net "web site application" is a far better choice (compared to the "asp.net web site").
So, coming from a traditional software background, then hands down, I prefer the ability to have multiple projects in the one and same web project. And hands down I prefer the runtime compiling and management of external libraries of code and references being managed by the vs as opposed to "hoping" you setup and managed references correctly with a web site.
So, even those starting out say with PHP, or many other systems? Yes, they run a web server all the time, and then go edit the source files - and a simple "save" of the file you just edited means then a browser refresh, and you are done.
however, you lose a lot of control over referenced libraries, and KNOWING the build + compile is the same one you be running on the web site after a publish.
And note that a web site publish in effect will be just the SAME copy of the existing web site and files - there not really a "compile" process for publishing, and hence no "debug" folder really exists. It also means that each page launched on the site can out of the blue cause code to compile.
(Whereas with a asp.net web site application, there is a small startup delay the first time - probably due to JIT's running, but other than that, each additional pages and parts of the web site will not then have significant delays. With a web site re-publish, then huge delays can occur (but then again, often you never really have to re-publish do you - you are editing the live files!!). But, if you are working on a test copy, then yes, you are going to re-publish everything (actually copy the files - since nothing more is required). And as such then the web server really will be slow to start up, and slow to open pages that have not yet triggered compile of the code-behind pages (and you get a gazillion little .dll's as a result).
So, the only real issue here?
MAKE SURE you open the web site using file->open web site as opposed to file->open project. In theory and practice, such "web sites" thus don't have a .sln and project file. (it really is just a folder of files). As noted, many love this setup, especially for larger sites, since then little changes here and there are very easy. However, from an overall software management point of view, using git and source code, and things like writing unit test code, shared libraries, using multiple projects in one vs project file? You give up most of this with the web site option. So, yes, that setup is quick and dirty, but it not all that great if you more formalized in your software development approach.
I prefer strong references, and strong typing during the development process. I also prefer having VS manage my references. So, these abilities are worth more than a simple ctrl-s to update some code. However, if some bug crops up, while it can often be fixed by a simple edit of some code file and ctrl-s, and you are done? it will be harder to track down and find that bug in the first place!!!
To be fair, once a code project is created, then changes and fixes are often rather small - and this again actually favors that simple edit and ctrl-s deployment model.
it can often be painful to have to do a full re-publish of a whole big web application for JUST one little, tiny change of code, or even markup. And in most cases, when I deploy, I stop the web server services, publish, and then re-start the IIS web services.
So, it can "often" be hard to make a case that this deployment model (well, it doesn't really have a deployment model!!!) is bad, since it oh so easy to update bits and parts of an existing running site.
However, in the long run, I really can't endorse this way of development. I MUCH prefer using a web application. It is more git friendly, it allows things like testing code (unit testing), far better use of external class and library code, and you have a MUCH better control of compile and build of your code. Letting IIS compile the code base has increased risk, since you can't be sure during development that your final code and project will run the same when you deploy. (or least be far surer!).
It would be a history lesson.
More than two decades when Microsoft designed ASP.NET 1.0, the developers were using classic ASP which is simply Visual Basic code running on IIS. Thus, ASP.NET 1.0 has the mode of "ASP.NET Web Site" (used by your current employer) that you put source code on IIS and compile on the fly to mimic classic ASP.
It was after a few more years that Microsoft realized how bad that mode is, and introduced "ASP.NET Web Application" mode (used by your previous employer).
Microsoft has urged "ASP.NET Web Site" projects to be migrated to "ASP.NET Web Application" (or simply ASP.NET Core) for more than a decade, but unless IIS stops supporting those projects, many will not migrate at all.
"Is it okay" is impossible to be answered. Your current employer seems to enjoy that very well.
Reference
https://en.wikipedia.org/wiki/ASP.NET_Web_Forms
Is it good practice to have a production (live) asp.net website that is also a working copy to push updates?
In general this is considered bad practice primarily because the source control repository contains the source whereas the production application contains the result. The two are kept separate for a number of reasons:
Security. If your source is on your production server, it's at risk of being viewed. Maybe this is a problem, maybe it's not. The safe approach is to just not have the source on the production server.
Performance. The result of building the source can be optimized for performance in ways that the source itself generally isn't. In a .NET application, for example, the production deployment doesn't contain debugging symbols. This may not be an issue in your particular application, but it's something to consider.
Multiple Results. Is your source an actual application, or is it information used to build an application? Can multiple versions be built? For example, in a .NET web application, you might have Web.config transforms. These are used at deploy-time to adjust the result of building the source. If the source itself is being used as the live application, these deploy-time modifications aren't available.
Others may be able to articulate this much better than I can, but in general it is considered bad practice, yes. Your particular application may be an exception to any particular reason or may not be meaningfully affected by any particular reason, so I stress the "in general" part.
Depending on the layout of your project, there may be some security concerns. For instance, if you have a .txt file with some sensitive information, keep in mind that it will accessible in your site.
Anything in App_Code or any .cs, .vb, .config, etc files will not be served by ASP.NET, so you can put stuff you don't want people seeing there.
Also, for initial loading performance, you should precompile your site via the VS Publish command or the Web Deployment Project addin (assuming you're working with a web site project). You could create an svn branch for the precompiled, deployable code and use that branch on your server.
You can use services like http://springloops.io or http://deployhq.com to only push certain folders to a server. That gives you a lot of flexibility in pushing code to deployment.
This question already has answers here:
ASP.NET Web Site or ASP.NET Web Application?
(25 answers)
Closed 9 years ago.
I've read a lot of discussions about web site vs web applications in asp.net
The way we work in my team (10 programmers), we use the project type "web site", and for our dev environment, we just copy the source code (aspx + .cs) to the server. This way, all the programmers can be doing changes at the same time.. and the server does the build dynamically. .....(for the prod environment, they build the application)
Now, I'm starting a new project, and I decided to use web application (the main reason was the web config transform option).. I soon realized that (as far as I know) it forces you to do a build/publish of the web app to the server with every change... which is not a big problem if I'm the only one working on this project...
But, now I'm wondering, what's going to happen if more programmers needs to work on this new project at the same time?
Any advise or similar situation?
EDIT
we're using Visual Source Safe... but only for keeping track of the older versions (not for builds)... I'm familiar with Subversion... but.. unfortunately, I don't take the decision on what we should use.. and I don't think they're willing to change
Thanks everyone for your answers...
Anytime I hear the, this isn't a big problem as long as. . . . immediately tells me, that I should assume that it will be a problem. In short, go with what you know. If you are familiar with using the ASP.NET website, then I would use that. Your development practices are already focused around handling that.
This is the same model that I used when doing classic ASP when I first started programming at a company. This model works, although I would strongly suggest getting source control too. That being said, here is what I would do long term:
Source control
Develop locally
Get a continous build process going (cruise control is a free one).
Have one person push everyone's changes to the development server, once everyone agrees that all the changes are compatible with each other. (normally this is done by making sure the build server can compile everything).
If you choose to use web application and add more programmers on the project, I recommend using source control. Git and Subversion are very popular. In Git, for example, you can see who commits what.
Of course, I would use source control from the get-go, whether you're on your own or collaborating with a group.
As #edmastermind29 said source control is really the #1 thing to keep that straight if you are having more then 1 developer.
It really depends on your development process. Most shops do some type of continuous integration and have unit tests running and have some sort of automated build process.
I have found that using a web application project is really the best for all the "best practice" types of things.
Check out this link for some guidance.
It really depends on how your team works, and how your environment is configured. Regardless though, you need to have some sort of source control system in place to ensure that your not overwriting each other's changes. If you don't already have a source control system in place, stop now and get one immediately.
Depending on which source control system you choose, you will at least have the basic checkin/checkout features that serve as a library for your code base; meaning if I have a file checked out you can't touch it until I've checked it back in.
If you choose a more feature-rich source control system, you should be able to take advantage of features like branching and shelving, which will allow your team to work on the same files simultaneously, and merge the changes when the files are checked in.
While your question is about web sites vs. web applications, the answer is source control. With a good source control system in place, your question becomes more or less irrelevant, aside from needing to coordinate builds with a web application.
Our product is an ASP.Net web application. Currently, we use Web Site Projects in Visual Studio, but have been looking into using Web Application Projects for quite some time. I am currently researching them so that we can hopefully improve our deployment process.
We have a base web site that is shared and common between different clients, and then we extend that with client-specific functionality in client Web Site Projects. The client projects extend base, and therefore rely on its contents. To build the full product, we first deploy the base web site, and then overlay it with the content from the client project.
In looking at converting to Web Application Projects in Visual Studio, we were hoping to be able to create the base project, then create client projects and set up references to base. This structure seems to work OK, but when we are attempting to deploy the application from the client project using MSDeploy, only the dll from the base web site is being published. This is fine for some things, referencing the compiled code is useful, but there are other items like images, js pages, htm, etc that is still source that is required for the client application to function. We need more than the compiled code from our base web site.
That all being said, I can think of a few options here:
Continue to deploy in 2 steps. First the base web site, then the client web site to build the full product.
Modify the deployment process to copy the required source files from the base project
Re-architect our model to support this base-client relationship in a different manner. Not quite sure how this would work, and would be the least-viable option.
??
Is there a different option that I am missing? Am I doing something wrong with the way I am setting up my projects? Is there more to making a Web Application reference another Web Application beyond sharing compiled code? If that's the case, why wouldn't you just use a shared class library? Or maybe I am missing something with the MS Deploy process?
I am open to suggestions here as I feel like I am missing something. I don't think our model for our web applications is too unique.
Update: The dual-deploy process does work, but feels a little kludgey. Any other input?
By using assembly WebResource you can Add CSS/JS/Some other File as Reference along with the Code i.e, your Base Project DLL.
If am right you can Add this WebResource in your base project then go through the below link.
http://support.microsoft.com/kb/910442
Like this way, most of the third party tools will access their CSS and JS files.
Try this. Hope it will help.
How is the site "shared" between clients? Does each client ultimately get a different site (ip address, etc) or are they logging into the same site but getting different functionality? You may want to looking into adding ALL the functionality into a single project and then enabling/disabling feature via settings.
If i have correctly understood your question, you'd like to publish also items which aren't compiled (htm, JS, images, etc..).
So, each file in your Solution Explorer tab has its own properties (accessed by F4 key) which let you choose the build action (eg. compile -> will inject the item in the DLL if applicable, content -> will copy the file "as is" to output directory).
I think the build action "content", with the option "copy to output directory" set to "copy if newer", may be the solution you're looking for.
I would carefully analyze what you are sharing between projects and how you share them.
If it is compiled code, the correct way is to extract those classes out into their own namespace and assembly and share the DLL across projects. Ensure you follow OO and SOLID principles while refactoring.
If it is content (js, htm, images, css) that you share, you have a few options here. You can create a separate virtual directory for the content and reference your content with an absolute URL. This helps because later down the line if you ever want to separate out a project into its own website in IIS, you don't have to change the content URLs. You can also have all the content in your so-called base website and then reference the content in the other projects using a relative path relative to the base website.
On the other hand, if it is ASP.NET user controls or ASP.NET MVC views that you would like to share, it is best to create an individual item in each project. This does not necessarily mean there is a separate physical file in that path - you can also add items in a .NET project in Visual Studio that are only reference links.
Regarding the deployment process, I don't think there is anything wrong with the web site projects per se. Web site projects have a purpose that is different than Web application projects, the main being that you do not have to compile your classes every time you deploy code (provided they are in the correct application folders).
I would suggest sticking to the 2 step deployment process with Web site projects.
I would also review the web sites (virtual directories) created in IIS and consider nesting them if it makes sense. And a review of the application pools (whether separate or shared) would not harm either.
Lastly, this is an old question. Please share if you have already implemented a successful strategy.
I've been working on a legacy ASP.NET Web Site (versus a Web Application) project at a client for some time now, and its slow compile time has me wondering:
Are web site projects known to be slow(er) at compiling (than Web Application projects)?
It's a pretty small website, but the entire solution has tons of functionality -- 19 projects worth of it, 18 of which compile really quickly (the non-web projects). The website project itself has ~100 pages and ~15 user controls (these actually take about half of the compile time) and normally compiles within 30 to 60 seconds. A complete re-build takes closer to the latter.
So, some things I believe could be slowing it down (you debunk them):
(X)HTML validation issues (the code we inherited has thousands of compiler warnings about validation issues).
High levels of abstraction -- since the code for the website pages is compiled at run-time, I'm guessing that whatever it's doing for user controls up-front is a lengthy process so that the binding at compile-time can happen.
The mere size of the web site? I know these are not very efficient projects, and believe me, I've spent hours trying to get it converted to a web application, but Visual Studio was unable to parse a single ASPX file into its .aspx/.designer.xx components because of the validation problems I mentioned earlier.
Assuming my client won't approve more than a few hours to fix this up, is there any quick fixes, changes, or optimizations known that could help me out?
I do not have a puny computer, so its processing power is not an issue. I've also worked on Web Application projects equivalent in size and complexity that compile in just a few seconds.
I'm open to pretty much anything, so I'd love to hear your thoughts! Also, if you think this should be a wiki, let me know.
My observations have been the same: web site projects take awhile to build, longer then web app projects. I think I found some information on why, check this out: http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx
Search for "Iterative development". It says this about web site projects, when compared to web application projects:
By default, Visual Studio completely
compiles Web site projects whenever
you run or debug any page. This is
done to identify compile-time errors
anywhere in the site. However, a
complete site build can significantly
slow down the iterative development
process, so it is generally
recommended that you change the build
project option to compile only the
current page on run or debug.
First read this blog post Tips to optimize design-time build performance for Web Sites in Visual Studio 2005
Main points made:
Do not disable batch compilation
Leverage Server-side Compilation
Move App_Code files into a separate class library project
Check for conflicting dependencies
Turn off AutoToolboxPopulate in the Windows Forms Designer options.
Disable validation for HTML editing
Another option that could help you is switching to a RAM disk: Running development from a RAM disk – options and products
If that doesn't help maybe splitting your large WAP into multiple ones could improve compile time. Unfortunatelly that strategy requires you to drop developing on Cassini. Instead you will have to use IIS as host: Using multiple Web Application Projects (WAP) in one Solution
One fact most developers overlook in an ASP.NET Web Project is the amount of classes in the App_Code folder.
The more classes you put in it, the longer it will be the compilation time.
From the ASP.NET Compilation Overview on MSDN:
ASP.NET creates an assembly for each
application directory (such as
App_Code) and one for the main
directory. (If files in a directory
are in different programming
languages, then separate assemblies
will be created for each language.)
So, if you can basically minimize the Folder Hierarchy and reduce the amount of classes in it, it will probably reduce the compilation time.
Another thing I noticed from your post is that, you have 18 non-website projects.
I think it is a bit too excessive because think of it this way.
When the Web Project compilation starts, the ASP.NET Compiler needs to link the 18 separate DLL files.
If those projects can be combined to reduce the number of DLLs, it might help also.
From maintainability viewpoint, having 18 projects is a bit excessive unless there are REAL strong reasons to do so.
I would suggest reviewing the projects and combine them.
I hope it helps.
This may not be ideal, but you can split your projects into multiple solutions. For example you can take the user controls and put them in Solution A and the rest of projects into Solution B. Then compile the controls in Solution A and file reference to them from Solution B which should help cut down the compile time
Website or web project, the performance should be similar after compilation phase. If the issue is poor performance immediately after deploying a new set of codes, a quick way I can think of is to pre-publish the site. (see reference http://msdn.microsoft.com/en-us/library/1y1404zt(VS.80).aspx)
Depending on the options you choose during the publishing, you may lack flexibility to make changes on the fly (which you shouldn't anyway).