Archives

Archives / 2011 / July

  • ASP.NET Web Application Project (WAP) vs Website

    2 Comments

    Recently, we moved a fairly large web application to Website project. This is a very old decision point that we have moved back and forth a few times. A Bing search shows 2 well written entries early in the list:

    Here is how we reach the current decision:

    • Back to VS2002/VS2003, it was WAP. No choice.
    • In VS2005, it was website. No choice initially until WAP was added back to VS2005.
    • In VS2008, we moved to WAP. The main reason was that website projects does not have a project file to store assembly and project references. The project reference is stored in the solution file. The reference to GAC assembly was stored in the web.config and the non-GAC DLL reference is through a bunch .refresh files that points to the location of DLL files (library). This makes checking in solution file into version control important.This system is fragile and breaks easily.
    • Now we are moving back to Website. We understand website reference mechanism better now so it is less frustrating. In WAP, the entire code-behind is compiled into a single DLL. In website, it can be much granular so it works better in industries (such as financial) that requires clean audit-trail of artifacts. We have several thousands of web pages. WAP will requires us to compile the entire application before debugging while we can compile just a single page with Website. In general, with the adoption of MVVM, most of the business logic now resides in separate library DLLs so we do not have much code other than the data-binding code left in the code-behind. This allows us to have a fine control on the granularity of compilation and deployment units.

  • Moving DLLs from bin to GAC in asp.net

    No Comments

    This must be a decade-old question, but surely come up to bite us again during the refactoring today. We decided to moved several shared DLLs from bin to GAC in several of our ASP.NET web sites. Here is what we found out:

    1. The code-behind files and the code in app_code directory failed to compile. The way to fix is add referenced assemblies to the compilation/assemblies section under system.web in web.config file. ASP.NET compiler will pickup DLLs in bin automatically but will not do so in GAC. We have to explicitly instruct it.
    2. If we update any DLL in GAC, we need to restart the application (e.g., using IISRESET) for APP.NET applications to pick up new versions of the DLL. ASP.NET shadows a copy of GAC DLLs in temp ASP.NET directory. While ASP.NET can detect DLL changes in the bin folder, it will not detect DLL changes in GAC until the application is restarted.
    3. Don’t even think of putting DLLs in both bin and GAC. There are well defined rules are which ones get actually used but doing so will only cause confusion. For more information, see http://stackoverflow.com/questions/981142/dll-in-both-the-bin-and-the-gac-which-one-gets-used.