ASP.NET: web site vs. web application project

ASP.NET: web site vs. web application project - Part 2

Code
34 Comments

Stephen M. Redd
Thursday, June 05 2008

My previous article about web sites vs. web applications seems to be a popular article, generating about 1/2 of the total traffic for this site. Most of that traffic comes from searches. Unfortunately, I doubt the old post really contains what people are actually looking for. So I'd like to spend a little text describing these two project types and how they compare.

A little background:

Visual Studio 2005 introduced the asp.net "web site". Not only was this the only project type for asp.net when VS 2005 shipped, is was also major change from the old VS 2003 web project. In web sites the code is compiled on the fly by asp.net and there are no visual studio specific project files or auto-generated classes involved. This makes web sites simple and easy to deploy (just copy source to a web server and browse).

Not long after VS 2005 shipped, MS released the Web Application Project. This was an add-on initially, but has since been folded into VS 2005 with SP1 and shipped with VS 2008 out of the box.

The Web application project is an updated version of the old VS.NET 2003 project type. It organizes the project using the familiar VS project files and such. It requires you to compile the application before you can run it, but you gain more control over how the application is compiled.

I'll omit a detailed technical description of the differences between web sites and web applications. This territory has been better covered elsewhere on the web, and the MSDN documentation that ships with VS 2008 covers it in detail too.

What most people want to know is, which is better?

The answer does depend a little on personal preference and what kind of application you are building.

I write and maintain several web applications. Some are very small personal sites with mostly static content, while others are huge data entry applications. My largest solution includes about 22 different class library and database projects that support a single web site project.

The web site project has always disappointed me, even with my smaller applications. The Web Application project type has become my preferred approach for all new projects, and I've since converted most of my older web sites to web applications as well.

Web site projects:

Web sites are a little simpler if you are doing inline code instead of code behind. Web sites also reflect changes in code files without needing to be manually compiled. That means you can edit a file and just refresh the browser.

If you need to explicitly "build", so you can ensure your code doesn't have errors for example, you can still do so. However, the "build" command doesn't really compile the project... it just verifies it using the dynamic compiler. While 99% of the time this is fine, I have come across a couple of minor cases where the verification compiler didn't find an error, but attempting to run the site for real did.

Major advantages of web sites:

Everything in the project's folder is part of the project. This makes it easy to use other editors or tools with web sites. If you add files outside Visual Studio, they will still be part of the project. If you edit a file outside VS it will still be compiled and the changes visible when the site is viewed in a browser.
You can deploy without having to compile... just XCOPY and go. Web sites do support pre-compilation if you choose to use it.
Files don't have to be written in the same language. VS will support having a mix of VB and C# code on a file-by-file basis. Sounds good, but I've never found this useful personally. Maintaining a site is much easier if you stick with one language.
The add "item" dialogs in Visual Studio are more intuitive for web sites. I'm not sure why both projects don't use the same dialogs, but they certainly don't.
Profile's design time compilation is automatic. The ProfileCommon class is created dynamically making it easy to work with the profile provider in a strongly typed way.

The biggest annoyance for me with web sites are:

No way to really "exclude" a file without renaming it. Refactoring tools and the "compiler" have to crawl through every file in your application. This can get slow if you have a lot of files. For example, I often use FCKEditor, which has a dump-truck load of files. Most of them are not asp.net files. But just having to scan through them when I build or refactor can really slow things down. This has gotten a little better in VS 2008, but not fast enough for my tastes.
No control over your namespaces. Sure, you can manually add namespaces to pretty much anything, but visual studio will fight you every step of the way. With generated code such as ADO.NET DataSets and such, this gets very hard to control. Eventually you will give up and just let VS put everything in the default namespace. In large applications this gets very annoying, especially if you like a well structured application.
It is hard (read, nearly impossible) to reference pages, user controls, etc from custom classes in the app_code folder. This produces some interesting problems if you are doing anything fancy like dynamically loading pages or controls and such.
The application compiles to the asp.net temporary internet files folder. This is a drop location for all that dynamically compiled code that the asp.net compiler will produce. This is a fine mechanism until it breaks. When it breaks you can get really weird errors from the compiler that don't make obvious sense. These are pretty easy to cause by accident. For example, if you tell VS to "build" then refresh a browser pointed at the site at the same time.... the two compiles often conflict in some bizarre manner corrupting the temp asp.net files. When this happens, assuming you figure out that this is the cause of the problem, you have to shut down VS and the web server, manually remove the files from the temp folder, then restart everything.
No ability to product XML comment output files. I use the crap out of XML comments, so this is the big deal breaker for me.
Not much control over build outputs. In most projects you can set whether a file is compiled, copied to the output directory, and such. But not with web sites. If a file is in the project's folder structure, it is part of the project.
Team Build hates web sites. Lacking a project file, you can use the web deployment project add-on to help out, but even still I've found that trying to automate a build for any significantly complex web site is a disaster and time-sink.
Disconnected Source Control. VS supports working disconnected from source control these days, but I find that it often has problems keeping web sites in sync when you reconnect. This is a sporadic problem, and hard to reproduce, but seems to be more common with delete, rename, and add operations.

The web application project:

The web application project is a little more formal than web sites. You get an actual project file by which Visual Studio tracks the files that are in your project. Web applications do generate "designer" files for your pages that link the code-behind to the controls you've put in the markup, but unlike old VS 2003 projects these are much simpler and leverage partial classes and such.

The drawbacks are:

The site has to be compiled/built before it will run.
Your project is specific to only one language.
No automatic support for a Profile class. You have to use a separate tool to generate ProfileCommon or write one manually.

The major advantages are:

Compile and refactoring is much faster since VS has a way to track what is in the project and doesn't have to scan everything in every folder. Also, you can have stuff in the folders that aren't part of the project (I find this useful sometimes).
You can control namespaces, assembly names, and build behavior for various files in the project. Namespaces are also automatically managed by VS based on the application's folder structure. This includes a real "project properties" editor too with all those familiar things like build options, references, settings, etc.
You can generate XML comment output files.
You can exclude files from the project without having to rename them.
MSBuild and Team Build work much smoother with web application projects.
Custom code files don't have to be in a specific folder, you can put them anywhere and organize them however you see fit.
Classes can refernce pages and controls.
You can split the site into multiple projects.
Include pre and post build steps to compilation.
Disconnected source control seems to work more consistently with web application projects.

The bottom line:

Web applications scale better and are just plain smoother than web sites assuming you plan to do most of your development directly in Visual Studio. The only major difference is that you have to build manually... so get used to CTRL + SHIFT + B. At least it's pretty fast in VS 2008 and it won't blow up the temporary internet files folder like web site projects can.

I can't say that web sites are inferior to web applications overall. There are cases where web sites do work very well, especially with smaller and simpler projects. I just personally don't find that having on-the-fly compilation is really much extra value, while more control over the application's compilation is always a good thing.

Stephen M. Redd
Thursday, June 05 2008
Filed under: Code
Tagged as: aspnet, web, visual-studio
34 Comments

» Similar Posts

» Trackbacks & Pingbacks

Web Application Project vs Web Site Project in Visual Studio

Web Application Project vs Web Site Project in Visual Studio — October 1, 2008 6:41 PM

Trackback link for this post:
http://reddnet.net/trackback.ashx?id=210

» Comments

Cool post, so much in detail about 'proper' use and comparison among those two web project type. Thank you.

DItyo Nurasto — June 22, 2008 5:57 AM
Enlightning!

I think I will convert my site into an application project.

Thanks

Daniel — July 9, 2008 4:49 AM
I have discovered another problem with a "Web Site" project. I have written a HttpModule that sets the culture/uiculture on the CurrentThread during the "BeginRequest" or the "PreRequestHandlerExecute" event. However this does not work well in a "Web Site" project. In a "Web Site" the culture on the CurrentThread is set to the browser setting after the "BeginRequest" and "PreRequestHandlerExecute" events have occured. In a "Web Application" the module works as expected.

Marcel de Koster — September 1, 2008 6:32 AM
My first thought is... why are you changing the culture explicitly for the entire request?

But then I realized that I really don't want to know... I really hate localization :P

I'm sure you have a good reason for overriding the browser's culture explicitly. It is an interesting difference between them. You may find similar differences based on IIS version or even framework version too though... especially when you try to set it that early in the pipeline. There is no easy way to predict when/if asp.net will dispatch your request to another thread, so this technique could behave erratically for a lot of reasons.

The best technique I have seen for explicit localization was one where an HttpModule simply pushed information about which culture to use into the HttpContext.Current.Items collection. aspx pages would then override the InitializeCulture() method to set the culture for the pages (usually this is done by having a custom basepage for your app from which all your pages inherit).

Code outside a page can still get to the culture info from HttpContext.Current and explicitly control which culture is supplied to culture sensitive operations like string formatting and such-like.

This way you aren't manipulating the entire thread's culture settings, instead you are taking an "as-needed" approach to culture variations.

Stephen M. Redd — September 1, 2008 3:55 PM
Thank you for posting this, Stephen. This is exactly the kind of summary I was looking for, and you helped me make up my mind to try out the web application project model.

Keith Garrett — September 5, 2008 6:51 AM
Thanks , very goood post!! updated my blog on this topic with this post link.

Vijay — October 1, 2008 6:42 PM
Thanks, and as Keith Garrett said "This is exactly the kind of summary I was looking for"

Thanks

Wael Muhammad — October 9, 2008 12:49 AM
Thx..

MSDN doesn't compare WAP&website as comprehensive as this article. You help me so much =)

Levi — December 5, 2008 11:31 AM
Awesome post, thanks! Scratches all the right WAP/WS itches.

Ehcor — December 8, 2008 1:23 AM
Yet another post indicating that this is a very good article describing the differences between a 'web application' and a 'web site.'

I am a relative (that means beginner) 'newbie' in the handling of ASP.NET. I am using VS 2008 Professional and am looking at tutorials.

I know from my other programming experience at the 'enterprise' level that 'control' of a project is a "good thing."

Yet, the 'web site' choice does make for a seemingly 'easier' life in the beginning. But, as the complexity of the programs grows (they almost always do), using the more 'formal' tools at one's disposal will pay dividends in the future.

Web applications it is---even for me -- an ASP.NET beginner.

John Spencer — January 6, 2009 10:59 PM
What a great post! Most of my work is on company-internal business applications, as opposed to public web sites, and I think moving to web apps makes good sense. I used VS2003, and wondered where all that stuff went, and why. I especially missed the ability to get the XML comment files. I'm going to try migrating a web site to an app. Thank you!

Ken Messner — February 6, 2009 7:48 PM
Very very useful article.

We need to go web application project model if the application is complex and not a simeple web site application.

Also web applicaiton deployment becomes very simple in VS.NET 2010.

Muhilan — March 26, 2009 12:55 AM
Great article.

This was VERY helpful, as I've been spending the past week or so figuring this out for myself - and the MSDN documentation leaves very much to be desired.

I wonder why, then, because of the major differences in the CodeFile (WebSite) & the CodeBehind (WAP) attributes in the @Page declaration, Visual Studio (both 2005 and 2008,) fails to address this very important detail when you select "Convert to Web Application" on ASPX files. It only does half the job by creating designer files! W

Again, great article.

Ben Doherty — April 30, 2009 7:46 PM
I did not find a create deal of help but UrlScan seemed like a good place to start. After a download, install and uninstall, I noticed UrlFilter in Add/Remove Program. Once UrlFilter was uninstalled the debugging started with no problems.

ZK@Web Marketing Blog — June 30, 2009 12:08 PM
Thanks for your kind suggestions and this is exactly the kind of summary I was looking for, and you helped me make up my mind to try out the web application project model.

migliori giochi dei casinò virtuali — October 14, 2009 12:26 AM
Tanx

This was very usfull.

Ramin — November 7, 2009 4:02 PM
Thanks for sharing this article.That's very helpful and interesting.

ditte traslochi milano — December 9, 2009 11:41 PM
Nice Post Redd. Please do extend this post, if you come across major improvements related to this topic in new versions of VS(like VS 2010 and later).

Rajesh Kolla — December 11, 2009 9:28 PM
There seem to be no changes in this area at all in VS 2010... except that the convert web site to web application option appears to be absent in the Beta 2 release.

Stephen M. Redd — December 11, 2009 11:04 PM
Thank you for the objective, and thorough breakdown. I am a firm believer in Web Applications myself, and find that experienced Visual Studio Developers new to Web based programming tend to begin a Web based project with the "Web Site" simply because the option is much more accessible to them via the Visual Studio 2008 IDE. I would like Microsoft to remove the Web Site capabilities altogether. When working with a group of other developers, it's nice to have a standard like, "Always create a Web Application." The problem is that the standard doesn't really make sense to someone who has never gone through the pain of converting a large "Web Site" to multiple "Web Application" projects (IE Web with Web Serice), or the pain of scaling a System without namespaces to differentiate the class libraries. Therefore, Microsoft should remove the Web Site capabilities all together (Leave that up to the Expression products) and give us an accessible "New Web Application" option in it's place, along with it's consistent project and solution structure.

Tyler J Plog — December 23, 2009 11:53 AM
Thanks for the detailled info, it is very helpful to a .NET newbie.

I developed many years using VB with a SQL backends and I am finding that .NET is a totally new world...big learning curve.

dd

DeeDee — January 26, 2010 4:59 PM
Asp.net has matured a lot. If you are coming back to the .net stack, be sure to check out the LINQ stuff and the asp.net MVC framework. LINQ is just all around amazing, and MVC is the "fast mover" in asp.net web dev now days.

Might wanna try C# this time though. VB has improved equally as much as C#, but with asp.net devs in particular C# is hands down the more popular language now. You'll find that most code examples these days are C# only; fewer and fewer examples present versions in both languages and a VB only example has become quite rare.

Stephen M. Redd — January 26, 2010 6:34 PM
I found this post very interesting a few months ago.

So i started rebuilding my web site from scratch, turning it into a web application.

Yesterday decided to test the new web application on the server. I publish the site to a local folder and it worked.

I also was happy to have choosen different names folders in the new project so no conflict with the the old ones. So i just uploaded the new webapplication files over the old website.

Ok the story is coming to an end.

The new web application is working (with its own web.config) but not enough to keep it online so i deleted all the new folders , and the web.config. I deleted the referenced dlls. The old website is working (restored its web.config) except for classes in the app_folder.

Excuse my poor english i guess this is a place where somebody might have a solution.

Daniele

danceoften — January 29, 2010 4:28 PM
I forgot to say that of course i'd like the old site to work again , including the pages that use classes in the app_folder, before i'm finished with the new web app. I guess somewhere the site can remember he's been a web app for a while, so it does not use the dynamic generation from the app_code. If you think this can be the case, what should i check-change ?

Thanx for reading this long question, and thanx to Stephen for the perfect article.

danceoften — January 29, 2010 4:50 PM
Well... in theory if you mix pages from a web site and pages from a web application you should probably be fine. If you look at the @Page directive in web site pages vs. ones in web application projects you'll note that they use different attributes to wire themselves to the code-behind. As long as you don't duplicate namespace+class names and you still have the app_code folder for the legacy pages in place it should work fine.

You might need to merge the two web.config files though, but you might just be able to get away with the newer one from the web app project.

I'd have to know what specific errors you got to tell you more though... but there is nothing by design incompatible between web sites and web apps on the same server that I know of.

Stephen M. Redd — January 29, 2010 5:36 PM
In reference to Tyler's comment from a while back regaring eliminating web sites from the IDE... VS 2010 deemphasizes the web site project in the UI. It doesn't appear in the "new project" dialogs at all. You can create web sites under the project menu and solution explorer.

They are still fully supported in the IDE for backwards compatibility and for the 5 or 6 guys that really do prefer sites to projects; but clearly this is not the default way of doing things anymore.

Stephen M. Redd — January 29, 2010 5:42 PM
thank you very much for your quick response Stephen.

I really would like to migrate my site from wsp to wap.

In the meanwhile i'd like to be able to put the old one (wsp) on line in any moment.

So here come the question : 1) to put the old site (wsp) should i just delete files on the web space and upload the old working ones ? where does the server reads if the site has to be compiled on the fly or if it is precompiled ?

2) Once i have a working wap it on my develop machine what are the steps i should do ?

what i did is : publish it on a local folder; delete all files on my remote server; upload everythig from the local publishing directory to the remote server.

Am I missing anything ? if not i will come with further questions.

Thanx again and sorry for those newbie questions.

danceoften — January 30, 2010 7:42 AM
Q: 1a) "to put the old site (wsp) should i just delete files on the web space and upload the old working ones"

A: 1a) Yes absolutely. The best thing you can do to ensure you don't break the production site is remove everything and push an old working backup copy. I also suggest you create a testing/staging site on your production web server. Leave this site off most of the time, but when you are ready to push to production, first push the new version out to this temp/stage location and test it out. This allows you to catch any problems specific to the production environment that may not exist in your development and/or testing environments.

Q: 1b) "where does the server reads if the site has to be compiled on the fly or if it is precompiled ?"

A: 1b) Let me come back to this in a separate comment in a bit... it's a longer answer.

Q: 2) "Once i have a working wap it on my develop machine what are the steps i should do ?"

A: 2) This applies to WSP and WAP both, but the simplest way to do this is to avoid doing any special "pre-compilation" or the "publish wizard". Do what I call a "poor-man's publish":

- Build (compile) the project within VS using "release" mode

- Change the web.config compilation setting to debug="false"

- Copy the entire project folder (as it is) from the dev system to the production web server

This eliminates all the special problems that the publish wizard and pre-compilation can cause you. A lot of the files from the project will not be used by the production web server, but having them there is not going to break anything either... and the built-in asp.net security is VERY good at preventing unwanted access to the source files even when you do put them on the public site for a while.

As long as you build in release mode and turn off the debug flag in web.config, the site will perform very well in production too.

Once you are confident the app works and everything is kosher, then go back to trying the publish wizard and perhaps using pre-compilation.

Q: 3) "what i did is : publish it on a local folder; delete all files on my remote server; upload everything from the local publishing directory to the remote server."

A: 3) That's exactly the procedure you should aim for. As I mentioned in answer 2 though, I advise skipping the publish wizard stuff for a while until you make sure to get everything else worked out.

The only advantage pre-compilation really gives you is that the web server doesn't have to compile the pages when they are initially requested for the first time by a user. This is sometimes called "first-hit lag". Pre-compilation does that initial page compile ahead of time (and permanently) so there is never any first-hit lag. Otherwise, precompilation doesn't buy you that much.

In addition to pre-compilation, the only other value to the publish wizard is to remove files that just aren't needed for the site to actually run. This confers no real runtime advantage, but does make the security paranoid a little happier since the source code files aren't out there where a hacker can scoop them. In my practical experience, this is NOT an actual security problem as long as you don't have retarded security on the server itself. If a hacker does manage to get enough access to your web server to scoop your source code, he probably isn't going to bother. There are far more interesting things he can do with your server, and your source is probably not high on his list anyway.

For a lot of my apps, I will deliberately push a copy of the entire VS project source to the production server. It never hurts to have another backup copy of the source, and in real emergencies it can be far faster to pull a copy of the entire published project off the production server and be able to open
Stephen M. Redd — January 30, 2010 6:22 PM
Q: 1b) "where does the server reads if the site has to be compiled on the fly or if it is precompiled ?"

A: 1b) It doesn't do this at all really. Also, there is a difference between "compiled" as in how a WAP is compiled and "pre-compiled" which can be done for both WSP and WAP.

Ok... here is the short-ish version of how this works:

First - Web Site Projects (I'll post WAP info in the next comment):

There is no design time compile normally. When a user requests a page (the first time), asp.net finds the aspx file. The page directive has a CodeFile attribute that tells the compiler that it needs to merging a code-behind and a code-in-front file. To do this: First generate code from the markup within the aspx file. Generated aspx code and code-behind are partials of the same class. Next it compiles that class into an assembly (each page is a seperate DLL). Assembly is placed in a temp folder. This temp folder is treated as if it were a "bin" folder (more or less). Finally it runs the code to answer the user's request. Until the app restarts, or one of the files change, additional requests use the already compiled assembly.

If you pre-compile a WSP, it tells Visual Studio to do exactly what I described above. Visual Studio drops a copy of the generated DLLs into the bin folder and replaces the content of the aspx files with marker text. When the site starts, asp.net scans the bin folder and learns about the pre-compiled classes automatically. There is a slight difference for "editable" pre-compile mode. The aspx files contain their normal content, and the runtime compiler can recompile the page's assembly if/when the aspx file changes (at which point that page is no longer pre-compiled).

Stephen M. Redd — January 30, 2010 7:06 PM
Pages in a WAP are different. They contain an aspx markup file, a designer code file, and a code-behind file. The designer file is mostly metadata needed by visual studio to support intellisense and visual editors. The code-behind file and the designer file are partials of each other. When you build a WAP in Visual Studio, the code files (designer and code-behind files) are all compiled and placed into a single assembly within the bin folder (any other pages and code are all in this one DLL too). The aspx pages are NOT compiled in any way at this point.

At runtime, when the page is first requested by a user (the first time), asp.net finds the aspx file. The page directive does NOT have a codefile attribute, so all the runtime compiler cares about is the "inherits" attribute (it ignores the CodeBehind attribute, that's only used by VS). It will generate code for a class from the markup within the aspx page, but it does not need to merge this with any partial classes or code-behind files. Instead the generated code is a class that inherits from the class that visual studio has already compiled. The generated code is compiled the same as with a WSP, then the code is run to handle the user's request.

Pre-compilation in a WAP is funcationally the same as it is in a WSP. The aspx pages are compiled same as they would be at runtime, and placed in the bin folder. Editable pre-compile works the same too... the files are editable, at which point it stops using the pre-compiled version in bin.

Stephen M. Redd — January 30, 2010 7:18 PM
Once again, i found in your post more than what i used to imagine, and in a complete form. So it's fine to have things so well organized in mind now, thx so much

Let's come to my little problem..

I decided to upload a working backup copy of my site (wsp) in the root space, and to test the new vesion (wap) on production server as per your suggestion.

i'll make a folder today for this purpose, where i'll upload the wap.

At the moment each folder in my web space is serving a different domain:

i.e : http://shejradio.org served by shejradio folder, immobiliaresanpetronio.com served by ISP folder , http://sassocamper.com served by SCV, http://danceoften.org served by org folder, http://danceoften.com served by danceoften folder Etc.

all the sites (wsp) use more or less the same classes / methods to accomplish page, menus and data fetch from a sql database. Those classes are phisically stored in the app_folder.

One of this classes is called StatHelper, self explainatory. All aspx pages use a StatHelper.WriteStat(type fake) to record page visiting in Database.

The thing still happening after a full clean and upload of the old wsp on the server is the following:

Every site (domain) is working fine (shared master page calling stathelper.writestat ) except danceoften.com. the compiler says there is no class named StatHelper in the current namespace. Danceoften.com used to be served by the danceoften folder (no routing no rewriting etc just a PHISICAL folder!!!!)

This is not happening in all other domain using exactly the same mechanism (SAME MASTER PAGE, calling exactly StatHelper.WriteStat(type fake))

Desperate at the end i tried this :

1- rename the danceoften folder to dan

2- update references to danceoften folder to new name in both resources and Database

3- refreshed the page

IT WORKS!! [ i will be missing my old bookmarkers :-( ]

I don't guess any possible solution for this behaviour.

Danceoften — January 31, 2010 6:57 AM
The most likely reason for the problem is a glitch in how asp.net stores dynamic compilations in the asp.net temporary folder. I mentioned in my original post that often the way WSPs use this folder can result in strange compilation problems that seem to make almost no sense at all.

The easy solution for this would be to kill ALL the sub-folders within your server's asp.net temp folder (it will rebuild these automatically). This folder is typically located at C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files

You may need to stop IIS first (it often locks these files). Then delete everything within that folder. Restart IIS again.

On a related note: Going forward with your WSP to WAP transition I suggest the you consider taking all of these helper classes out of the core web project and put them in a class library project.

create a class library project and set the properties (specifically the default namespace)

add references to System.Web and any similar

Create class files for each helper class formerly in app_code

Copy the code for each helper from the WSP into the appropriate class in the class lib.

Exclude or delete the helper classes that you've moved from app_code folder in the WSP.

Add a reference to the WSP pointing at the new class library project.

Update references in your WSP pages to use the new helper classes. The VS build will point most of these out for you so no worries about having to manually find them all :)

Once you've done this, you will also have created a class library project that your WAP can use, and also eliminated the helper classes from being subjected to dynamic compilation (and the associated temp folder annoyances). Plus these classes will now all have proper namespaces and such too even in the WSP project.

This should make upgrading the WSP to a WAP a much simpler task.

Stephen M. Redd — January 31, 2010 5:22 PM
I've already done exactly this :-)

Since yesterday night, both the systems are working side by side.

The old one looses power; the new one assumes new refactored functionality.

Thanx for your precious help & encouragement.

danceoften — February 1, 2010 1:28 PM

Reddnet Scribbles