.Net implementations

Question

I've worked at two companies that implement ASP.Net two different ways. I tend to lean towards A, but my current job follows the B (more typical) approach. I'm wondering which is best, and also, are there formal names for these implementations?

A) No project or solution was built. We simply pointed Visual Studio to a directory and started building pages (We had a combination of in-line aspx pages and aspx/code-behind pages). We simply pushed the files up to a server and that was that. All classes and services sat in the App_Code directory or Bin if we needed any 3rd party functionality. We never used the "build" feature in .Net and everything was, for the most part, JIT compiled. Debugging was done the old-school Response.Write() way.

B) A project is created. There are Resx files, sln files and project files etc.. The project is compiled, built and debugged the way that I'm sure most .Net developers are used to. Everything is very tied to the VS IDE and trying to open the "project" in another copy of Visual Studio requires the same directories/localhost settings as whoever originated the project.

It would be interesting to hear from people who have worked in both implementations and the benefits they find on either side.

My reason for asking is that I'm thinking I'd like to steer my current dev team more towards the A implementation and cut out all of these peripheral files and configurations that lock you into VS, but I'm also open to hearing the benefits of drinking the Microsoft Kool-Aid as well.

Answer 1

See this question and answers from a couple of days ago...

Answer 2

I have used both approaches for good reasons but frankly B) is preferable to A).

If you are developing code that you are then to hand over to a customer with limited developement capability then A) (which we refer to as a Website project) may be the best way to go, along with keeping everything else as simple as possbile.

However if you are developing an application where only your company will be working on the code then you really want to learn to get along with the B) approach (which we refer to as a Web application probject).

A web application project provides greater control over what is in the project, what actually gets published and crucially can lead to better testing. Rather than trying to convince your collegues away from web apps I suggest you embrace the approach. Avoid releasing code in App_Code and code-behind file. Build and release assemblies, add to the solution library projects.

Answer 3

I would much rather be "locked into" Visual Studio than lose my debugger. How often do you guys need to develop outside of VS? I would guess never. You are already using MS products, use it the way they were intended to be used.

Answer 4

My preference is for method A. I like to keep things as simple as possible. With method A I know that everything within a directory is needed for a web site. With B it's possible to exclude files from a project but still have those files in the directory. I think this is confusing if you are looking at the site from Windows explorer.

With A it is easy to deploy a small fix to a page. With B you need to recompile the project and re-deploy. Related to this A allows you to make a change and deploy using any editor. B requires that you use VS.net.

B introduces more dependencies and complexity which can result in more issues that are not related to the site code.

A plays well with any source control. With B I've had issues with the project and solution files. B also adds files to the project that are not necessary for the web site.

With both A and B you can use VS.net for debugging. There's no need to use response.write with A.

Answer 5

I come from using both as well. option A is really the way to go if other people will be servicing the site once your done like anthony was saying. option b makes development so much easier and for me personally, I think you get more productivity out of option B.

Answer 6

If you are using ASP .NET then you are already 'drinking the Microsoft Kool-Aid', or at least sipping it quite a bit.

With A, you are primarily using Visual Studio as a glorified text editor, with all debugging, organization, and other work being done manually.

With B, you are able to use all the debugging and editing features in Visual Studio. The downside is that Visual Studio has it's own way of doing some things that is initially pushed upon you; though with some effort you can modify the project settings to act how you want.

In any situation you have to compare what you gain vs what you lose. In the case of going from A to B, you are losing a bit of flexibility, but gaining a ton of debugging capability.

Answer 7

You make a false assertion about the way B) works:

trying to open the "project" in another copy of Visual Studio requires the same directories/localhost settings as whoever originated the project.

That's not entirely true. The important settings should be included with the solution, and while you do need the same folder structure that's really part of the project and not the onerous burden you're hinting at. It's generally pretty easy to move projects around between developers. At least, no more difficult than it would be for a desktop application of similar scope.

This is especially true if you're using source control. Just check out the project and any folder structure you're worried about should come with it.

Answer 8

"Everything is very tied to the VS IDE and trying to open the "project" in another copy of Visual Studio requires the same directories/localhost settings as whoever originated the project"

Not from my experience. Directories need to be the same under a web project, but that's the case for any web application. If you are talking about 3rd party references (e.g. dlls), then you can just create a folder called "References" and drop them in there. That way, everyone will be pointing to the same folders (in respect to the local project... it won't matter if you store your project in a differently named directory as someone else).

As for localhost settings... I'm not sure what you're getting at. How does method A differ from method B in regard to the web server settings?