Where are web app references stored?

"David Thielen" <thielen@nospam.nospam> wrote in message
news:0tc8c4176qn0t4i5v96rdh3ec7f0dstgbo@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

"John Saunders" <no@dont.do.that.com> wrote in message
news:OxZiJgSEJHA.5732@TK2MSFTNGP04.phx.gbl...
> "David Thielen" <thielen@nospam.nospam> wrote in message
> news:0tc8c4176qn0t4i5v96rdh3ec7f0dstgbo@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

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"
<AnthonyWJones@yadayadayada.com> wrote:

>"David Thielen" <thielen@nospam.nospam> wrote in message
>news:uqc8c4h1grolv1gl33hlkk1mikk9efugth@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-at-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" <AnthonyWJones@yadayadayada.com> wrote in message
news:ujGSlmSEJHA.3288@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

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 (hongyes@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:
msdnmg@microsoft.com.

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

The below was perfect - thank you!!!


On Mon, 08 Sep 2008 11:55:14 GMT, hongyes@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 (hongyes@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:
>msdnmg@microsoft.com.
>
>This posting is provided "AS IS" with no warranties, and confers no rights.


david@at-at-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" <no@dont.do.that.com> wrote in message
news:%23S9mpJWEJHA.4040@TK2MSFTNGP02.phx.gbl...
>
> "Anthony Jones" <AnthonyWJones@yadayadayada.com> wrote in message
> news:ujGSlmSEJHA.3288@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

"Anthony Jones" <AnthonyWJones@yadayadayada.com> wrote in message
news:OH#CkBnEJHA.4040@TK2MSFTNGP02.phx.gbl...
>
> "John Saunders" <no@dont.do.that.com> wrote in message
> news:%23S9mpJWEJHA.4040@TK2MSFTNGP02.phx.gbl...
>>
>> "Anthony Jones" <AnthonyWJones@yadayadayada.com> wrote in message
>> news:ujGSlmSEJHA.3288@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

"John Saunders" <no@dont.do.that.com> wrote in message
news:OZmlMCpEJHA.5104@TK2MSFTNGP02.phx.gbl...
> "Anthony Jones" <AnthonyWJones@yadayadayada.com> wrote in message
> news:OH#CkBnEJHA.4040@TK2MSFTNGP02.phx.gbl...
>>
>> "John Saunders" <no@dont.do.that.com> wrote in message
>> news:%23S9mpJWEJHA.4040@TK2MSFTNGP02.phx.gbl...
>>>
>>> "Anthony Jones" <AnthonyWJones@yadayadayada.com> wrote in message
>>> news:ujGSlmSEJHA.3288@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

"Anthony Jones" <AnthonyWJones@yadayadayada.com> wrote in message
news:#L3$$8BFJHA.5224@TK2MSFTNGP03.phx.gbl...
> "John Saunders" <no@dont.do.that.com> wrote 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