Adding references - WebSite versus WebApplication
On my current project I’m creating an ASP.NET site in Visual Studio 2005 SP1.
NOTE: By default, Visual Studio 2005 only allows you to create ASP.NET sites by using the WebSite template but after installing SP1, you can also use the WebApplication template.
For this project we are using the WebSite template since this is the customer’s standard. While developing the application, I noticed that when using the WebSite template, the Add Reference works differently then when using the WebApplication template.
When adding a reference to dll A using the WebSite template, Visual Studio automatically adds a reference to all dll’s that dll A references. This is done to ease the deployment but it can give some unwanted side effects.
To make this clearer, I’ve created a simple solution structure that shows this issue. In the image on the left, you can see 4 projects:
DalLib
BllLib: contains a link to DalLib
WebSite: project using the WebSite template; contains a link to BllLib
WebApplication: project using the WebApplication template; contains a link to BllLib
When you compile this solution, you will notice that the Visual Studio will add the DalLib to the bin folder of the WebSite project. Because of this, you gain access to all the public classes within DalLib from the WebSite. Since I want to avoid direct access from UI to Dal, this is not what I want. When using the WebApplication template, you don’t have this problem.
A possible solution is to make the classes within the DalLib internal and set an InternalsVisible attribute in the AssemblyInfo.cs file of the DalLib (thanks Gert for the tip).
InternalsVisible is a new attribute from.NET 2.0 and is defined in the System.Runtime.CompilerServices namespace.
4 comments:
On Scott Guthrie's blog, you can find another side effect of the behaviour of the website template which he calls “Dueling Assembly References”.
Website are really painful to use in an enterprise environment. They are only convenient for small site or prove of concept.
Another annoying problem is related to the way files belong to a project. In fact, there is no project definition, all files which are in the folder are projects files. Normally you shouldn't put the bin directory under source control but if you don't do it others developers won't get your project references.
Maybe it's time to discuss with your customer ;-) InternalToVisible is a poor design choice to address this issue imho.
++ :-)
I don't like the WebSite template either. Besides the issue I have here, I already had others in the past.
We need to use the WebSite template to avoid having different project types at the customer. Apparently they had issues with the deployment of WebApplications. Therefore we need to stick with the WebSite.
Deployment of WebApplications is done using a 'Web Setup Project', which is probably more complicated than just copying the directory containing the application's files, but is usually worth it.
As Stéphane said, WebSite project is nice for ... web sites, not for enterprise web applications (that's why Microsoft reintroduced WebApplications in an emergency patch, even before the SP1 of VS2005). ;o)
Mastering your deployment phase is as important as mastering your development phase. That's why in Agile development, you release early & often. This will help ensure that you deployment process is fine tuned ... and you don't have bad surprises at the last minute.
Post a Comment