Epic Blog of Awesome

code.tech.sci.math.art.write

Install ASP.NET 4.0 / Silverlight 4 w/ SQL Merge Replication

There were some challenges in this 4-hour install that I wanted to get down while it was still fresh in my mind.

Database for the application is SQL 2008 R2 is distributed among three servers, one in the States, one in Asia and one in Europe. Merge Replication is used to synchronize the databases.

There were two DB schema changes required for the application upgrade. Merge replication handles some schema changes automatically without disruption to publisher or subscriber servers. One of my schema changes was a length change to a varchar column and I was able to do that on the publisher without a problem. Merge replication handled pushing the change to my subscribers.

The other schema change, however, was adding an identity property to a column, which requires dropping and re-adding the table. This can’t be done while the table is an active article in the replication setup. These are the steps I took to make that change:

  1. Remove the table from the publication articles.
  2. Create a new subscription snapshot
  3. Drop tables on subscriber databases
  4. Make schema changes on the table on the publisher database
  5. Add table back into the publisher articles
  6. Create a new subscription snapshot
  7. Use the replication monitor to ensure synchronization is successful.

The web application was compiled in Visual Studio and Published to a local directory. Remoted to each web server and deleted application all application except for Web.config. Mapped to local box, pulled in the published files.

The web site wouldn’t load. It was giving me 401 errors, which of course actually had nothing to do authentication problems. The web app did come up  on the two other web servers, so after some comparing and troubleshooting I fixed the IIS configuration on the server. It turned out that the application pool was possessed. Seriously, this was strange. As long as the web application was assigned to this application pool, I’d get 401s. When I changed the application pool to a different one of the same type (ASP.NET 4.0 Classic Mode), the app worked fine. Change it back, 401s. Change it back, works.

There were a couple of other details. Forgot to add a couple new rows of data to a configuration table. But no other big problems.

Use ViewData and Implement ViewModel Classes: The Official Microsoft ASP.NET Site

Using a ViewModel Pattern

The ViewData dictionary approach has the benefit of being fairly fast and easy to implement. Some developers don’t like using string-based dictionaries, though, since typos can lead to errors that will not be caught at compile-time. The un-typed ViewData dictionary also requires using the "as" operator or casting when using a strongly-typed language like C# in a view template.

An alternative approach that we could use is one often referred to as the "ViewModel" pattern. When using this pattern we create strongly-typed classes that are optimized for our specific view scenarios, and which expose properties for the dynamic values/content needed by our view templates. Our controller classes can then populate and pass these view-optimized classes to our view template to use. This enables type-safety, compile-time checking, and editor intellisense within view templates.

via Use ViewData and Implement ViewModel Classes: The Official Microsoft ASP.NET Site.

Experience ASP.NET MVC 3 Beta – the Razor View Engine


Razor is designed to be an alternate view engine for ASP.NET MVC. Initially introduced in WebMatrix and now shipped as part of ASP.NET MVC 3 Beta, Razor allows developers to replace the clunky <% %> syntax with a much cleaner coding model mainly around the sign @. Moreover, it provides some excellent features for Master Page scenarios, while at the same time you won’t lose access to any features you are already familiar with, such as HTML helper methods.

via Experience ASP.NET MVC 3 Beta – the Razor View Engine.

ASP.NET MVC View Model Patterns

Since MVC has been released I have observed much confusion about how best to construct view models. Sometimes this confusion is not without good reason since there does not seem to be a ton of information out there on best practice recommendations.  Additionally, there is not a “one size fits all” solution that acts as the silver bullet. In this post, I’ll describe a few of the main patterns that have emerged and the pros/cons of each. It is important to note that many of these patterns have emerged from people solving real-world issues.

via ASP.NET MVC View Model Patterns.

Microsoft Ajax Content Delivery Network – ASP.NET Ajax Library

The Microsoft Ajax Content Delivery Network (CDN) hosts popular third party JavaScript libraries such as jQuery and enables you to easily add them to your Web applications. For example, you can start using jQuery which is hosted on this CDN simply by adding a <script> tag to your page that points to ajax.aspnetcdn.com.

By taking advantage of the CDN, you can significantly improve the performance of your Ajax applications. The contents of the CDN are cached on servers located around the world. In addition, the CDN enables browsers to reuse cached third party JavaScript files for web sites that are located in different domains.

via Microsoft Ajax Content Delivery Network – ASP.NET Ajax Library.