How do I create a Web Application Project in VS 2008? How is it different from a "WebSite" project?
File--New--Project
instead of File--New--Web Site
It acts as a different container all together and the compile model is different.
ScottGu provided some details when they were first launched: http://weblogs.asp.net/scottgu/archive/2006/05/08/445742.aspx
The main difference is that Web application uses .csproj file which holds the information about all the files in the project. What difference does it make? Using web site model you can add new files without visual studio, since adding new files doesn't require csproj file modifications, but using Web application model you can not.
I personally prefer Web application type.
People have adequately identified many differences, but let me add this broader stroke:
Web Application Projects are architecturally consistant with the other project types in .Net, whereas WebSites deviate and really seem like a throwback to the VS 2003 days.
For this reason, my opinion is that WAP's are more elegant (especially when you have more than one project in a solution).
Related
I read from MSDN that solutions "contain items that you need to create your application". What exactly does that mean? Does that mean it contains all the code that I need to create my application? If that's the case, why not just call it the application?
why not just call it the application?
Because a solution can contain many applications, many supporting libraries used by those applications, various artifacts used for building and testing those applications. A solution may even contain no application at all, just class library projects.
Think of a solution as a container for projects which are logically grouped in some way, as well as various artifacts which may be used by those projects. A project in this case may be an application, a class library, a set of database scripts, etc.
Solution is just container for projects, the idea is that different projects can share code thus be accessible easier than including outside libraries.
I have 5 basic projects that need to be part of multiple applications. WinForms, ASP.NET, WPF depending on the needs we have.
These Projects are:
Company.Business - Business Logic DLL
Company.Business.Model - Business Models
Company.Business.DAL - Various DALs
Company.Configuration.Classes - Classes that are used to initialize BOs
Company.Utilities - General Utilities
Now i am trying to decide how i should go about when i create new UI solutions?
1) Include the projects by Add->Existing project ?
2) Copy the compiled .dlls to each solution manually?
In case of option 2 where i should do the basic development for all the above? Probably a separate solution that includes them all? and in there i should start unit testing?
My take on this is that it depends on your needs and how mature the "basic" projects are.
Your needs
If you need to look at into the code of the "basic" projects while working on the using-projects, then I'd add them to the current solution with the add-existing project method. In situations with multiple added existing projects I make a solution folder called "referenced projects" and add them in this folder.
Maturity
If your "basic" projects are still being developed (perhaps side-by-side) with the using-projects I'd also would add them in the solution as described above.
But if you have no need to look at the code then you might as well include the compiled dll in your client-projects.
Harry
We are working on an ASP.NET MVC 3 project and taking advantage of Razor syntax to resolve paths and what not.
We are also employing a UI design team who is responsible for maintaining the design of our pages through the use of CSS and modifying the HTML in the cshtml pages.
The problem is, they work exclusively on Mac laptops without access to a web server or a .NET IDE.
Initially, they were just providing us a straight .html file along with a .css file and we were manually merging in their work into our ASP.NET solution (e.g., replacing paths with Razor markup, etc), but as the project grows and we become more involved, we are looking for a solution that will save us from these manual merges.
I was thinking I could create some kind include script that would rewrite the paths depending on whether the UI designers were editing the file, or the .NET devs, but this seems archaic.
Anyone out there been in this situation before?
Razor is a templating language, and a pretty small one at that. Could your UI team familiarize themselves with enough of it to deal with their own links? I'm sure they are familar with your view hierarchy since they are going to be building it, so it shouldn't be much of a leap to explain how controller and action paths work.
Razor files can be edited outside of a .NET IDE just fine...any old text editor will work since it's not like there's anything you have to compile. You could provide them with an instance that they could copy their files to via a shared drive (cifs) to test them on. I don't see any reason for your UI team to be required to use Visual Studio.
You could just rename your .cshtml file to .aspx and reload it in VS and design away. when you are done, rename it to .cshtml
I am curious what the preferred way to structure an application with an executable client program, an executable server program and a shared model in solutions and projects (using Visual Studio and C#). Being used to Java development I initially regarded projects as packages and defined a project for each package I designed.
This resulted in a six-project solution (one for the model, one for the server and four for the client) which in turn resulted in some silly dependencies causing me to reconsider if this is the best approach.
Now, I am planning to restructure the solution to three projects total: a client project, a sever project and a model project. Both the client and the server will be dependent on the model project (in which I will also add the shared interface between client and sever).
Is this the best way to structure such an application?
Also, what is the best way to reflect namespaces within the tree structure of Visual Studio? (Just creating a similar folder structure for instance?).
A 3-project solution (client / server / model) is indeed the norm for your scenario.
Regarding namespaces: Yes, your folder structure should reflect the namespaces you are using. The default namespace can be set in the project properties, folder names are added to that namespace.
I've seen a lot of different takes on this subject so I figured if there's a preferred way on this.
Is there any best practices on how to setup Visual Studio Projects and Solutions in regards to multiple solutions for the same solutions?
For example:
Let's say I have a task that calls for a web app, a console application, and a shared business logic library.
I have seen this situation in a 1, 2, and 3 solutions at some time in my career. This is a simple example; however, what if number of projects grows? Is there a line when to keep it in one or break it apart?
Indeed, there are some guidelines for this sort of setup on MSDN. I wrote a short summary in my answer to a similar question on StackOverflow.
I blogged about this back in 2007. The advice still holds:
http://mikehadlow.blogspot.com/2007/07/how-to-structure-visual-studio.html
The bottom line is that I should be able to get your code out of source control, open it in Visual Studio, hit F5 and everything should work.
Solutions are for the developer, in a particular situation. Projects (.CSPROJ for C-Sharp) are where the real compilation takes place.
Theoretically if there are 4 different projects, there could be 24 different combinations of those projects a developer may want to combine into solutions.
If you keep everything at a project level, you won't need to worry about how a developer has arranged their .SLN files
You can have multipe solutions, and each one can reference the projects that it cares about. Extending your example, your shared business logic library may have a corresponding unit test library. These two projects can be contained in one solution. At the same time, you may have another solution that contains the three projects that you mention, but in this case the unit test library isn't included.
My solutions typically consist of:
Web Application project
'Common' folder for base & common helper classes
'Include' folder
'Styles' folder
'Scripts' folder
'Images' folder
'UserControls' folder
Web Services project
Web Framework project
Business Tier project
Business Framework project
Data Access project
I like to include all projects for a certain task, in a solution. So based on the example you mention, I would have a solution containing the three projects that belong to the solution I was asked to do. That keeps all elements to complete a task together, I find this simplifies the inclusion of other elements required to solve the task at hand.