Where are web app references stored?

[David Thielen]

Hi;

When we add a reference to a web app, where is that information
stored? There is no project file, it's not in the web.config or
solution file.

??? - thanks - dave

david@at******@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com

Cubicle Wars - http://www.windwardreports.com/film.htm

[Stan]

On 6 Sep, 18:26, David Thielen <[e-mail]:

Hi;

When we add a reference to a web app, where is that information
stored? There is no project file, it's not in the web.config or
solution file.

??? - thanks - dave

david@[e-mail]
Windward Reports --http://www.WindwardReports.com
me --http://dave.thielen.com

Cubicle Wars -http://www.windwardreports.com/film.htm

Hi David

Beg to differ. It IS stored in web.config

Look in section:

<system.web>
<compilation>
<assemblies>
<add assembly=" ... (the reference goes here)

HTH

[John Saunders]

"David Thielen" <th*****@nospam.nospamwrote in message
news:59********************************@4ax.com...

Hi;

When we add a reference to a web app, where is that information
stored? There is no project file, it's not in the web.config or
solution file.

David, if you are using a Web Application Project (and you should be), then
your references are in the project file, just like any other project.

--
John Saunders | MVP - Connected System Developer

[bruce barker]

I've never seen a reason to use a web application. it just leads to bad
coding practices (pages calling global methods on other pages, etc).

-- bruce (sqlwork.com)

John Saunders wrote:

"David Thielen" <th*****@nospam.nospamwrote in message
news:59********************************@4ax.com...

>Hi;

When we add a reference to a web app, where is that information
stored? There is no project file, it's not in the web.config or
solution file.

David, if you are using a Web Application Project (and you should be),
then your references are in the project file, just like any other project.

[John Saunders]

"bruce barker" <no****@nospam.comwrote in message
news:uk**************@TK2MSFTNGP02.phx.gbl...

I've never seen a reason to use a web application. it just leads to bad
coding practices (pages calling global methods on other pages, etc).

Huh? That doesn't happen if you don't _permit_ it to happen! If you permit
bad coding practices, then that's what you'll get.

I just did the same thing in a web site project. It doesn't prevent bad
habits at all. What makes you think that a web site project prevents this?
--
John Saunders | MVP - Connected System Developer

[Anthony Jones]

"Stan" <go********@philhall.netwrote in message
news:95**********************************@l42g2000 hsc.googlegroups.com...

On 6 Sep, 18:26, David Thielen <[e-mail]:

>Hi;

When we add a reference to a web app, where is that information
stored? There is no project file, it's not in the web.config or
solution file.

??? - thanks - dave

david@[e-mail]
Windward Reports --http://www.WindwardReports.com
me --http://dave.thielen.com

Cubicle Wars -http://www.windwardreports.com/film.htm

Hi David

Beg to differ. It IS stored in web.config

Look in section:

<system.web>
<compilation>
<assemblies>
<add assembly=" ... (the reference goes here)

In addition the anything in the bin folder is assumed to be referenced and
the solution file will contain info related to other projects that are
referenced by the web site.

--
Anthony Jones - MVP ASP/ASP.NET

[David Thielen]

It must be the Bin rule as it's not in web.config. Is there anyway to
force it to be added there so I don't have to look up the full
assembly name (public key, etc)?

thanks - dave
On Sun, 7 Sep 2008 13:20:23 +0100, "Anthony Jones"
<An***********@yadayadayada.comwrote:

>"Stan" <go********@philhall.netwrote in message
news:95**********************************@l42g200 0hsc.googlegroups.com...

>On 6 Sep, 18:26, David Thielen <[e-mail]:

>>Hi;

When we add a reference to a web app, where is that information
stored? There is no project file, it's not in the web.config or
solution file.

??? - thanks - dave

david@[e-mail]
Windward Reports --http://www.WindwardReports.com
me --http://dave.thielen.com

Cubicle Wars -http://www.windwardreports.com/film.htm

Hi David

Beg to differ. It IS stored in web.config

Look in section:

<system.web>
<compilation>
<assemblies>
<add assembly=" ... (the reference goes here)

In addition the anything in the bin folder is assumed to be referenced and
the solution file will contain info related to other projects that are
referenced by the web site.

david@at******@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com

Cubicle Wars - http://www.windwardreports.com/film.htm

[David Thielen]

Is there a good url that explains using the Web Application Project
approach?

thanks - dave
On Sat, 6 Sep 2008 18:30:55 -0400, "John Saunders"
<[e-mail]:

>"David Thielen" <th*****@nospam.nospamwrote in message
news:59********************************@4ax.com.. .

>Hi;

When we add a reference to a web app, where is that information
stored? There is no project file, it's not in the web.config or
solution file.

David, if you are using a Web Application Project (and you should be), then
your references are in the project file, just like any other project.

david@at******@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com

Cubicle Wars - http://www.windwardreports.com/film.htm

[John Saunders]

"David Thielen" <th*****@nospam.nospamwrote in message
news:0t********************************@4ax.com...

Is there a good url that explains using the Web Application Project
approach?

David, I don't know of any such URL, and I wish I did. It would be much
easier to explain that way.

Just consider a couple of things:

1) Web Application Projects is what everyone successfully used in .NET 1.0
and 1.1
2) Everything else you create in Visual Studio is a project. Web Sites are
the only exception
3) Microsoft thought Web Sites were so great that the got rid of Web
Application Projects in Visual Studio 2005
4) They reacted quickly to the outrage and restored them in Visual Studio
2005 SP1 - a very quick service pack

In my opinion, if you are creating an application that happens to be
web-based, then you should use a Web _Application_ Project. If you are
creating a web site, for instance, your company's web site, then go ahead
and use a Web Site (though maybe you should consider using Expression Web or
something instead).

There is no excuse for using the "Web Site" technique for web services, BTW.
The "Web Site" paradigm is that whatever you happen to have in the folder
you designated as a web site is part of the web site, whether you have
pages, images, or whatever. That kind of looseness should not apply to a web
service.
--
John Saunders | MVP - Connected System Developer

[Anthony Jones]

"David Thielen" <th*****@nospam.nospamwrote in message
news:uq********************************@4ax.com...

It must be the Bin rule as it's not in web.config. Is there anyway to
force it to be added there so I don't have to look up the full
assembly name (public key, etc)?

Find the dll and drop a copy of it in the bin folder. Job done.

--
Anthony Jones - MVP ASP/ASP.NET

[Anthony Jones]

"David Thielen" <th*****@nospam.nospamwrote in message
news:0t********************************@4ax.com...

Is there a good url that explains using the Web Application Project
approach?

Don't. Its horrible. Its only there to support the porting of 2003
projects.

--
Anthony Jones - MVP ASP/ASP.NET

[Anthony Jones]

"John Saunders" <[e-mail] in message
news:Ox**************@TK2MSFTNGP04.phx.gbl...

"David Thielen" <th*****@nospam.nospamwrote in message
news:0t********************************@4ax.com...

>Is there a good url that explains using the Web Application Project
approach?

David, I don't know of any such URL, and I wish I did. It would be much
easier to explain that way.

Just consider a couple of things:

1) Web Application Projects is what everyone successfully used in .NET 1.0
and 1.1
2) Everything else you create in Visual Studio is a project. Web Sites are
the only exception
3) Microsoft thought Web Sites were so great that the got rid of Web
Application Projects in Visual Studio 2005
4) They reacted quickly to the outrage and restored them in Visual Studio
2005 SP1 - a very quick service pack

In my opinion, if you are creating an application that happens to be
web-based, then you should use a Web _Application_ Project. If you are
creating a web site, for instance, your company's web site, then go ahead
and use a Web Site (though maybe you should consider using Expression Web
or something instead).

There is no excuse for using the "Web Site" technique for web services,
BTW. The "Web Site" paradigm is that whatever you happen to have in the
folder you designated as a web site is part of the web site, whether you
have pages, images, or whatever. That kind of looseness should not apply
to a web service.

What you are your reasons for so strongly advocating the _Application_ over
the Web Site?
What is your definition of 'application' the text above seems to have it
synonymous with 'service', is that intended or am I just reading the text
wrong?

I for one was really glad to see the back the project based web site it was
a real pain in the proverbial.

--
Anthony Jones - MVP ASP/ASP.NET

[David Thielen]

The problem is whenever anyone else checks it out - they have the same
issue because we build & copy what goes in Bin and don't check in
those files. I'll add it to web.config.

thanks - dave
On Sun, 7 Sep 2008 21:29:24 +0100, "Anthony Jones"
<An***********@yadayadayada.comwrote:

>"David Thielen" <th*****@nospam.nospamwrote in message
news:uq********************************@4ax.com.. .

>It must be the Bin rule as it's not in web.config. Is there anyway to
force it to be added there so I don't have to look up the full
assembly name (public key, etc)?

Find the dll and drop a copy of it in the bin folder. Job done.

david@at******@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com

Cubicle Wars - http://www.windwardreports.com/film.htm

[John Saunders]

"Anthony Jones" <An***********@yadayadayada.comwrote in message
news:uj**************@TK2MSFTNGP03.phx.gbl...

>
What you are your reasons for so strongly advocating the _Application_
over the Web Site?
What is your definition of 'application' the text above seems to have it
synonymous with 'service', is that intended or am I just reading the text
wrong?

I for one was really glad to see the back the project based web site it
was a real pain in the proverbial.

Anthony, first may I ask you, did you ever develop ASP.NET applications in
..NET 1.0 or .NET 1.1? Those were Web Application projects. Did you have a
problem with them? I didn't (much).

Note that my emphasis would be on "Project" and somewhat less on
"Application". Web sites are not projects. Note the lack of a .csproj file
or anything like it. They're just a bunch of files in a folder tree.

My definition of an application is the same as the normal definition of an
application. What is Excel? What is Word? What is any other _application_? A
"Web Application" is an application that happens to be accessed through a
browser instead of by running a program on the users desktop computer.

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.
--
John Saunders | MVP - Connected System Developer

[Hongye Sun [MSFT]]

Hello Dave,

Thanks for your post.

In website project of VS 2008, there are 4 types of references. Visual
Studio treats them differently and put them in different places.
1. GAC assembly reference
As Stan said, those DLLs are stored in web.config file:
"<system.web>.<compilation>.<assemblies>". In this way, we just need to
specify its strong name.
For those basic assemblies in GAC, such as mscorlib, System.Web, etc, they
are specified in file:
"C:\Windows\Microsoft.NET\Framework\v2.0.50727\CON FIG\web.config".
2. Projects within same solution
As Anthony said, those project references will be stored in solution file.
When open it by notepad, you will see "ProjectReferences" under section
"ProjectSection(WebsiteProperties)". ASP.NET uses this value to store
project references.
3. External DLL but not in GAC
Whenever add an external DLL in VS 2008, it will auto-generate a refresh
text file. Inside the refresh file, it just keeps the DLL file path (VS
will determine it is absolute or relative path). The purpose of the refresh
file is for source control. People can change or update the DLL outside of
the bin folder, and Visual Studio will copy it from its file path in every
build.
4. COM DLL
Those DLLs cannot be used in website project directly. Visual Studio will
generate an Interop assembly for it, and the assembly will be directly
stored in bin folder. There is no other place that will store information
of the Interop assembly reference.

I noticed that you want a good place to learn how to use web application. I
will provide some resources for you:
Web Application Project Introduction by Scott Gu:
http://weblogs.asp.net/scottgu/archi...08/445742.aspx
Visual Studio 2005 Web Application Project Tutorials:
http://webproject.scottgu.com/Default.aspx
Comparing Web Site Projects and Web Application Projects:
http://msdn.microsoft.com/en-us/libr...px#wapp_topic5

Please feel free to let me know if you have any question regarding to the
information above. It is always our pleasure to help you.

Have a nice day!

Regards,
Hongye Sun (ho*****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.

[David Thielen]

The below was perfect - thank you!!!
On Mon, 08 Sep 2008 11:55:14 GMT, ho*****@online.microsoft.com
("Hongye Sun [MSFT]") wrote:

>Hello Dave,

Thanks for your post.

In website project of VS 2008, there are 4 types of references. Visual
Studio treats them differently and put them in different places.
1. GAC assembly reference
As Stan said, those DLLs are stored in web.config file:
"<system.web>.<compilation>.<assemblies>". In this way, we just need to
specify its strong name.
For those basic assemblies in GAC, such as mscorlib, System.Web, etc, they
are specified in file:
"C:\Windows\Microsoft.NET\Framework\v2.0.50727\CO NFIG\web.config".
2. Projects within same solution
As Anthony said, those project references will be stored in solution file.
When open it by notepad, you will see "ProjectReferences" under section
"ProjectSection(WebsiteProperties)". ASP.NET uses this value to store
project references.
3. External DLL but not in GAC
Whenever add an external DLL in VS 2008, it will auto-generate a refresh
text file. Inside the refresh file, it just keeps the DLL file path (VS
will determine it is absolute or relative path). The purpose of the refresh
file is for source control. People can change or update the DLL outside of
the bin folder, and Visual Studio will copy it from its file path in every
build.
4. COM DLL
Those DLLs cannot be used in website project directly. Visual Studio will
generate an Interop assembly for it, and the assembly will be directly
stored in bin folder. There is no other place that will store information
of the Interop assembly reference.

I noticed that you want a good place to learn how to use web application. I
will provide some resources for you:
Web Application Project Introduction by Scott Gu:
http://weblogs.asp.net/scottgu/archi...08/445742.aspx
Visual Studio 2005 Web Application Project Tutorials:
http://webproject.scottgu.com/Default.aspx
Comparing Web Site Projects and Web Application Projects:
http://msdn.microsoft.com/en-us/libr...px#wapp_topic5

Please feel free to let me know if you have any question regarding to the
information above. It is always our pleasure to help you.

Have a nice day!

Regards,
Hongye Sun (ho*****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.

david@at******@windward.dot.dot.net
Windward Reports -- http://www.WindwardReports.com
me -- http://dave.thielen.com

Cubicle Wars - http://www.windwardreports.com/film.htm

[Anthony Jones]

"John Saunders" <[e-mail] in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

>
"Anthony Jones" <An***********@yadayadayada.comwrote in message
news:uj**************@TK2MSFTNGP03.phx.gbl...

>>
What you are your reasons for so strongly advocating the _Application_
over the Web Site?
What is your definition of 'application' the text above seems to have it
synonymous with 'service', is that intended or am I just reading the text
wrong?

I for one was really glad to see the back the project based web site it
was a real pain in the proverbial.

Anthony, first may I ask you, did you ever develop ASP.NET applications in
.NET 1.0 or .NET 1.1? Those were Web Application projects. Did you have a
problem with them? I didn't (much).

Yes serious limitations. When you have a team of web developers you need
source control. The problem is that the creation of new files (which is
more frequent than in other types of project) required the project file be
checked out. This creates a bottleneck.

Our solution was to simply hold the project file writable though not checked
out. But this means the project file is useless as a list of files in the
project. When doing a Get Latest version in VS it only gets latest versions
of the files it knows about from the project file. Hence any new files
checked in by other developers are missed. You had to go into the source
control application independantly and do it there.

Note that my emphasis would be on "Project" and somewhat less on
"Application". Web sites are not projects. Note the lack of a .csproj file
or anything like it. They're just a bunch of files in a folder tree.

Yes much simpler and more in sync with what a web site is. After all when
you point a new web site at physical folder then all the files therein are
part of the web site.

>
My definition of an application is the same as the normal definition of an
application. What is Excel? What is Word? What is any other _application_?
A "Web Application" is an application that happens to be accessed through
a browser instead of by running a program on the users desktop computer.

Agreed.

>
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.
--
Anthony Jones - MVP ASP/ASP.NET

[John Saunders]

"Anthony Jones" <An***********@yadayadayada.comwrote in message
news:OH**************@TK2MSFTNGP02.phx.gbl...

>
"John Saunders" <[e-mail] in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

>>
"Anthony Jones" <An***********@yadayadayada.comwrote in message
news:uj**************@TK2MSFTNGP03.phx.gbl...

>>>
What you are your reasons for so strongly advocating the _Application_
over the Web Site?
What is your definition of 'application' the text above seems to have it
synonymous with 'service', is that intended or am I just reading the
text wrong?

I for one was really glad to see the back the project based web site it
was a real pain in the proverbial.

Anthony, first may I ask you, did you ever develop ASP.NET applications
in .NET 1.0 or .NET 1.1? Those were Web Application projects. Did you
have a problem with them? I didn't (much).

Yes serious limitations. When you have a team of web developers you need
source control. The problem is that the creation of new files (which is
more frequent than in other types of project) required the project file be
checked out. This creates a bottleneck.

Our solution was to simply hold the project file writable though not
checked out. But this means the project file is useless as a list of
files in the project. When doing a Get Latest version in VS it only gets
latest versions of the files it knows about from the project file. Hence
any new files checked in by other developers are missed. You had to go
into the source control application independantly and do it there.

Ok, 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. ;-)

>Note that my emphasis would be on "Project" and somewhat less on
"Application". Web sites are not projects. Note the lack of a .csproj
file or anything like it. They're just a bunch of files in a folder tree.

Yes much simpler and more in sync with what a web site is. After all when
you point a new web site at physical folder then all the files therein are
part of the web site.

Yes, and I agree that if you need that feature, the only way to get it is
with a Web Site "project".

>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.

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? How do you
ensure that a developer doesn't happen to have extraneous files in the
directory tree? They wouldn't be built or otherwise processed until there
was an attempt to reference them (though I understand that a Web Deployment
Project can pre-compile).

Do you wait until deployment before you find out you've got code that
doesn't compile? And, I take it you haven't been using Web Site "projects"
with continuous integration? 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?

--
John Saunders | MVP - Connected System Developer

[Anthony Jones]

"John Saunders" <[e-mail] in message
news:OZ**************@TK2MSFTNGP02.phx.gbl...

"Anthony Jones" <An***********@yadayadayada.comwrote in message
news:OH**************@TK2MSFTNGP02.phx.gbl...

>>
"John Saunders" <[e-mail] in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

>>>
"Anthony Jones" <An***********@yadayadayada.comwrote in message
news:uj**************@TK2MSFTNGP03.phx.gbl...

What you are your reasons for so strongly advocating the _Application_
over the Web Site?
What is your definition of 'application' the text above seems to have
it synonymous with 'service', is that intended or am I just reading the
text wrong?

I for one was really glad to see the back the project based web site it
was a real pain in the proverbial.

Anthony, first may I ask you, did you ever develop ASP.NET applications
in .NET 1.0 or .NET 1.1? Those were Web Application projects. Did you
have a problem with them? I didn't (much).

Yes serious limitations. When you have a team of web developers you need
source control. The problem is that the creation of new files (which is
more frequent than in other types of project) required the project file
be checked out. This creates a bottleneck.

Our solution was to simply hold the project file writable though not
checked out. But this means the project file is useless as a list of
files in the project. When doing a Get Latest version in VS it only gets
latest versions of the files it knows about from the project file. Hence
any new files checked in by other developers are missed. You had to go
into the source control application independantly and do it there.

Ok, 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.

>

>>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.

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?

>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.

>They wouldn't be built or otherwise processed until there was an attempt to
reference them (though I understand that a Web Deployment Project can
pre-compile).

When I want to check that compilable content of the website builds I can
build the whole site. I don't see what the problem is. I don't see how the
presence of a project file helps.

>
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?

>And, I take it you haven't been using Web Site "projects" with continuous
integration?

We do and why not? Again how does not having a project prevent that?

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.

--
Anthony Jones - MVP ASP/ASP.NET

[John Saunders]

"Anthony Jones" <An***********@yadayadayada.comwrote in message
news:#L**************@TK2MSFTNGP03.phx.gbl...

"John Saunders" <[e-mail] in message

>Ok, 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

[Anthony Jones]

"John Saunders" <[e-mail] in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

"Anthony Jones" <An***********@yadayadayada.comwrote in message
news:#L**************@TK2MSFTNGP03.phx.gbl...

>"John Saunders" <[e-mail] in message

>>Ok, 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.

I agree the VSS merge is particularly bad but I don't think automatic
merging is a good idea anyway and I think even with a developer confiming
merges the process is prone to error.

>>>
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.

Its a product. We have something approaching 100 customers all running
instances of this application. VS isn't the last stop for code. We have
behind that our own in-house release manager that controls configurations
released to QA etc.

>

>>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.

You seem to feel that the project file is linked to the source control I'm
not sure why. This isn't the case in my experience. VS communicates with
SCC on a per file basis it doesn't need the project file to determine what
hasn't been added to the SCC yet, what's currently checked out locally or
checked out by another user. VS manages to do all that without a project
file.

>>>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.

Yes that was the annoying behaviour of 2003, 2005/8 is much better, if its
present it will build and everything is considered subject to source
control. If you select Check in on a folder anything in that folder that is
either checked out or not present in SCC is by default selected for check
in.

...

>>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.
...

The dependencies are managed by various means already described at the top
of this thread. There is no need for a project file to do this. The source
code control defines what is in the project.

>

>>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?

I'm confused by the question. As stated we don't do unit tests. I'd be
interested to get even vague idea how that can really be done in practice.

>And, do you build the whole site on every check-in?

No. I'm not sure that building the whole site reveals anything useful when
checking in a ASPX page for example.
We use monthly cycle of QA and Release. Hence every month new features are
released, whilst another version moves into QA, whilst further development
continues.

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?

Business classes, Web Controls and infrastructure are compilied into other
assemblies.

>
I hope this doesn't seem contentious. I was just astounded that people
were using Web Site "projects" for serious work.

The medium of text and the fact that we're busy people can make these
exchanges seem terse but its not meant that way. I think this shows that
people successfully use very different approaches.

For me project files we're a pain, we have a successful and managable engine
for creating and releasing code without them.

--
Anthony Jones - MVP ASP/ASP.NET