Where are web app references stored?

  • Thread starter Thread starter David Thielen
  • Start date Start date
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@[email protected]
Windward Reports --http://www.WindwardReports.com
me --http://dave.thielen.com

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

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
 
David Thielen said:
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.
Click to expand...

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.
 
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)
 
bruce barker said:
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).
Click to expand...

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?
 
Stan said:
Hi David

Beg to differ. It IS stored in web.config

Look in section:

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

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


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.
Click to expand...


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

Cubicle Wars - http://www.windwardreports.com/film.htm
 
David Thielen said:
Is there a good url that explains using the Web Application Project
approach?
Click to expand...

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.
 
David Thielen said:
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)?
Click to expand...


Find the dll and drop a copy of it in the bin folder. Job done.
 
David Thielen said:
Is there a good url that explains using the Web Application Project
approach?
Click to expand...


Don't. Its horrible. Its only there to support the porting of 2003
projects.
 
John Saunders said:
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.
Click to expand...

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 said:
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.
Click to expand...

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.
 
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\CONFIG\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/archive/2006/05/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/library/aa730880(VS.80).aspx#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 ([email protected], 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:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
 
The below was perfect - thank you!!!


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\CONFIG\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/archive/2006/05/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/library/aa730880(VS.80).aspx#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 ([email protected], 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:
(e-mail address removed).

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


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

Cubicle Wars - http://www.windwardreports.com/film.htm
 
John Saunders said:
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).
Click to expand...

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.
Click to expand...

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.
Click to expand...

I don't see how the project approach solves the issue any better than the
Website solution.
 
Anthony Jones said:
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.
Click to expand...

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 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.
Click to expand...

Yes, and I agree that if you need that feature, the only way to get it is
with a Web Site "project".
I don't see how the project approach solves the issue any better than the
Website solution.
Click to expand...

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