ASPNET
There are 4 entries for the tag ASPNET
Wednesday, February 17, 2010 3:13 PM | Comments

On the surface, I suppose this is YAMVCVWFC (Yet Another MVC vs. WebForms Comparison). If this topic doesn’t appeal to you, or you’re sick and tired of this discussion then I encourage you to move on. I won’t be offended, promise. This post is here to serve as my living, breathing arguments for fighting for MVC and it will serve to highlight my major gripes with Web Forms. The motivation for this post came from an all-too-familiar IRC chat in #asp.net – for those of you unfamiliar with IRC, it’s a lot like the Twitter of the 90s. Fallacy: Web Forms does everything I need it to (01:29p) <webformsdev> 99.9999999999% of client requests, project requirements, etc etc, can easily and equally be done using webforms or mvc (01:30p) <webformsdev> webforms + jquery = does everything I need (01:30p) <@mattman> getting something...

Sunday, November 9, 2008 6:45 AM | Comments

This weekend I started playing with Automated Builds in TFS 2008. Over the next few weeks I am going to setup automated builds for my various projects so I can start running automated integration testing and automated staging releases at certain intervals (nightly, weekly, etc). Unfortunately I hit a snag when I tried building one of my solutions that contained a Web Application Project. After some digging around, I eventually opened up the “Release.txt” log file which can be found in the deployment directory, I found the following error: error MSB4019: The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. Now I am no where near an expert on MSBuild or the delicacies of .csproj files, so I did my best to poke around...

Monday, February 25, 2008 5:52 AM | Comments

Today I just stumbled onto some interesting information regarding placements of script blocks and CSS links. According to some extensive testing performed at Yahoo!, they have published a list of Best Practices for Speeding Up Your Web Site. Many of these rules came as no surprise, for example: While researching performance at Yahoo!, we discovered that moving stylesheets to the document HEAD makes pages load faster. This is because putting stylesheets in the HEAD allows the page to render progressively. However, one rule caught my attention: Rule 5 described how stylesheets near the bottom of the page prohibit progressive rendering, and how moving them to the document HEAD eliminates the problem. Scripts (external JavaScript files) pose a similar problem, but the solution is just the opposite: it's better to move scripts from the top to as low in the page as possible. One reason is to enable progressive rendering, but another is...

Monday, February 25, 2008 5:38 AM | Comments

Honestly, I'm not sure if this setting is new to Visual Studio 2008 or not, but I just stumbled onto it. Typically when I'm debugging an ASP.NET application I test one page at a time, by right-clicking on the aspx and selecting View in Browser.   I prefer this method because I can keep the browser open at all times during development and not have to compile the whole site to quickly test something simple like markup changes. The caveat to this however, is that the Visual Studio debugger is not attached to the cassini process, so I cannot hit any break points I have set. For scenarios when I need to debug and step through code, I press the Debug button, wait for the site to compile and spawn a new browser window, and then I manually navigate to the page I want to debug....