Re: Where are web app references stored?
- From: "John Saunders" <no@xxxxxxxxxxxxxxxx>
- Date: Thu, 11 Sep 2008 11:33:16 -0400
"Anthony Jones" <AnthonyWJones@xxxxxxxxxxxxxxxx> wrote in message news:#L3$$8BFJHA.5224@xxxxxxxxxxxxxxxxxxxxxxx
"John Saunders" <no@xxxxxxxxxxxxxxxx> wrote in messageOk, I guess your source control system didn't allow multiple people to have the project file checked out, or didn't do merges? I'm using TFS, and it doesn't have that problem, even with many developers working on the projects at the same time. I've also used SourceGear Vault and CVS, and neither has that problem. Were you using SourceSafe? SourceSafe is the reason I moved to Vault. ;-)
Yes its SourceSafe. Yes its naff. It does what it needs to do. I don't trust merging I've found it prone to error.
Anthony, I'll just mention that you are correct: SourceSafe merge does have problems. I have not found that to be the case with most other source control systems. If the files being merged haven't changed arbitrarily (like an SSIS package file does), then most good diff/merge utilities work well. Even files like SSIS packages that change for no good reason can be merged with some massaging first.
The main distinction to me is that, like any other application that gets sold to customers who expect it to work, the things I call Web Applications need features like continuous integration, unit testing, code analysis, and other features that improve the quality of every other kind of application. They need to be able to be checked into source control, in a way that permits an earlier version to be built, and to be just like the earlier version. The issue that David Thielen raises of having to check in the bin folder is not an issue with any kind of project - but it _is_ an issue with a web site, which is, again, just a collection of files.
I don't see how the project approach solves the issue any better than the Website solution.
Maybe it's just a question of which source control system you were using. Note that a project file in VS2005 and later, isn't just a list of the files in the project - it also details how to build them, and the dependencies between them. This makes it possible for a CI solution to only build the code that needs to be built, and to run the unit tests, possibly even after deploying the web application to a test server.
Now I'm not sure I know what you are talking about. Our site contains aspx, ashx, legacy asp, static content and just a smattering of .cs in the App_Code. What extra info is needed? I wouldn't know where to begin to create a Unit Test for an ASPX page? I'm not sure I'd want to either.
Two things: is the site you're referring to part of a product, or is it a single site within your company? That's the main distinction I mentioned earlier. If you are developing a site, then I have little problem with using a Web Site "project". But if it's an application that happens to be web-based, then a more thorough software development process will have higher demands on VS.
How do you even do source control with a Web Site "project"?
Just hope that everyone always remembers to check in all the new files they add?
More confusion, how does having a project file solve a developers memory lapse?
When the file is added, the project file will be modified. The source control system can presumably show you modified files. It might even check the file out first. That makes it harder to ignore.
How do you ensure that a developer doesn't happen to have extraneous files in the directory tree?
Again how does a project file solve this? As I recall in 2003 you could simply ask the IDE to display file that weren't part of the project.
You can display it, but it won't be checked in or build for no better reason than because it was present.
....
Do you wait until deployment before you find out you've got code that doesn't compile?
No. Why would not having a project file indicate that, that would be the case?
This was a comment about Continuous Integration, which is greatly aided by having a project file that says what is and is not part of the project, and what the dependencies are.
....
If my guess on that is wrong, then please tell me how you do unit testing. I don't see how you would do it with a Web Site "project". Do you put the unit tests into the site somewhere?
Like I said I don't do unit testing on the web site. I can see the value in test driven development which I have found to be fastest way to deliver a working class. I'm very skeptical of its application in a UI especially a Web UI. Especially, especially one that relies heavily on Javascript/XML techniques.
Ok, I see. But do you run your unit tests on every check-in? And, do you build the whole site on every check-in? Or, did you mean that your business logic, etc., is in another project, that you use CI on that project, and that it is then referenced from the web site?
I hope this doesn't seem contentious. I was just astounded that people were using Web Site "projects" for serious work.
--
John Saunders | MVP - Connected System Developer
.
- Follow-Ups:
- Re: Where are web app references stored?
- From: Anthony Jones
- Re: Where are web app references stored?
- References:
- Where are web app references stored?
- From: David Thielen
- Re: Where are web app references stored?
- From: John Saunders
- Re: Where are web app references stored?
- From: David Thielen
- Re: Where are web app references stored?
- From: John Saunders
- Re: Where are web app references stored?
- From: Anthony Jones
- Re: Where are web app references stored?
- From: John Saunders
- Re: Where are web app references stored?
- From: Anthony Jones
- Re: Where are web app references stored?
- From: John Saunders
- Re: Where are web app references stored?
- From: Anthony Jones
- Where are web app references stored?
- Prev by Date: Re: Response.Redirect Custom Protocol, not http
- Next by Date: Re: problem in using asp.net stream graphic and image
- Previous by thread: Re: Where are web app references stored?
- Next by thread: Re: Where are web app references stored?
- Index(es):
Relevant Pages
|