Archives
-
ASP.NET 2.0 Course Samples
I taught the ASP.NET 2.0 Programming course at Interface Technical Training this week and wanted to post some of the samples we went through this week. For those that are interested you can find the samples here.
-
New Wrox Silverlight 1.0 Book
Interested in learning more about developing Silverlight 1.0 applications? There's a lot of great info on the http://www.silverlight.net Website, but Wrox is also releasing a new book titled Silverlight 1.0 that will be out in October. -
JavaScript Beautifier Tool
I was working on a new article on Silverlight tonight and needed to "beautify" the Silverlight.js code so that I could read through it more easily. I came across a nice JavaScript beautifier tool that did a great job converting the unformatted file into an easy to read format. I'm sure there are several of these tools out there on the Web, but this was the first one that popped up while searching and it worked quite well in case anyone needs that type of functionality.
-
Managing ASP.NET Development, Staging and Production Connection Strings (without pulling your hair out)
If you work with a large number of applications then you know what a pain it can be to manage multiple web.config files and multiple connection strings for development, staging/test, and production databases. Because developers typically have development, staging, and production connection strings to manage (depending upon the environment they are working in), many different strategies have been created to handle switching from development to staging/test to production. One way to manage this task is to have multiple web.config files and simply name them differently. For example, while in development the staging web.config file may be named web.stage.config. When code has been tested in development and needs to be deployed to staging/test, the staging web.config file can be renamed to "web.config" and then moved over to the staging Web Server(s). While this works well it involves an unnecessary step that should be more automated to avoid human error and involves keeping data in-sync between two or more web.config files.
VS.NET build events are another popular way to handle this problem. Scott Guthrie posted about this topic and links to a post that provides great details if you'd like to go this route.
When large numbers of developers are involved in creating different applications that have separate web.config files for each application that may hit the same databases, a management issue comes into play. If the database connection strings change at all (for instance moving from passing username/password credentials to integrated security or database name changes due to upgrades) then all web.config files with the appropriate connection strings in them must be updated. If you manage a large number of applications (an Intranet environment for example) then you now have to open many web.config files to modify the connection strings and hope that your search and replace routine catches everything. A more centralized way to store connection strings needs to be available in this case so that you can go to one place to make changes and be done with it!
The example code that follows demonstrates how to avoid renaming web.config files when applications are moved between environments while also providing a centralized storage location for database connection strings as well as other server information such as proxy servers and mail servers. The code relies upon XML serialization to load data from an XML file named ServerConfig.config into an object-model, detect the environment automatically based upon data in the ServerConfig.config file, and return the appropriate connection string for the environment (development, staging, production, etc.). It also allows primary and secondary connection strings to be accessed in cases where a secondary production database server is available to use when the primary is too busy or down. An example of the Server.Config file used in the downloadable sample code is shown below. Each server defines the environment it supports as well as the domains that can run on it. The domains are used to dynamically lookup the proper environment (dev, staging, prod, etc.) at runtime.
<?xml version="1.0" encoding="utf-8" ?> <ServerConfig> <Servers> <Server Name="DevelopmentServerName" Type="Web" Environment="Development" UserName="" Password="" Domain="" IP=""> <Domains> <Domain>localhost</Domain> </Domains> </Server> <Server Name="StagingServerName" Type="Web" Environment="Staging" UserName="" Password="" Domain="" IP=""> <Domains> <Domain>staging.xmlforasp.net</Domain> </Domains> </Server> <Server Name="ProductionServerName" Type="Web" Environment="Production" UserName="" Password="" Domain="" IP=""> <Domains> <Domain>www.xmlforasp.net</Domain> <Domain>xmlforasp.net</Domain> </Domains> </Server> <Server Name="ProxyServerName" Type="Proxy" Environment="Production" UserName="" Password="" Domain="" IP=""> <Domains> <Domain>your.proxy.server</Domain> </Domains> </Server> <Server Name="MailServerName" Type="Mail" Environment="Production" UserName="" Password="" Domain="" IP=""> <Domains> <Domain>your.smtp.server</Domain> </Domains> </Server> </Servers> <ConnectionStrings> <ConnectionString Database="Northwind"> <Primary>server=prodServerName;Integrated Security=SSPI;database=Northwind</Primary> <Secondary>server=secondaryProdServerName;Integrated Security=SSPI;database=Northwind</Secondary> <Staging>server=stagingServerName;Integrated Security=SSPI;database=Northwind</Staging> <Development>server=devServerName;Integrated Security=SSPI;database=Northwind</Development> </ConnectionString> <ConnectionString Database="Pubs"> <Primary>server=prodServerName;Integrated Security=SSPI;database=Pubs</Primary> <Secondary>server=secondaryProdServerName;Integrated Security=SSPI;database=Pubs</Secondary> <Staging>server=stagingServerName;Integrated Security=SSPI;database=Pubs</Staging> <Development>server=devServerName;Integrated Security=SSPI;database=Pubs</Development> </ConnectionString> </ConnectionStrings> </ServerConfig>
Once the ServerConfig.config file is created you can reference it in web.config (or better yet, in a higher level config file that is global to the server) by adding the following:<configuration> <appSettings> <!-- Suggest placing this in a more global location rather than in multiple web.config files --> <add key="ServerConfigPath" value="~/ServerConfig.config"/> </appSettings> </configuration>
The "ServerConfigPath" key is a fixed name in this case since the object model looks specifically for that key. Where you put the ServerConfig.config file is up to you of course, but putting it in a place that multiple Web applications can access is recommended.
A sample of accessing the Northwind database connection string from a data layer class is shown below. A class named ServerConfigManager does all the work of looking up the proper connection string to use based upon the domain that the application is currently running within. If no matching domain is found, it defaults to the development environment (that behavior can certainly be changed) and returns the development connection string. -
Using ADO.NET in an N-Layer Application Architecture
I'm teaching a C# programming course this week at Interface Technical Training and promised that I'd post some demo code that demonstrates how to segregate code into multiple layers (presentation, business, and data) while using ADO.NET. The code can be downloaded here.
-
My Latest ASP.NET AJAX Articles
Over the past few months I've been writing articles for the .NET Insight insight newsletter covering various ASP.NET AJAX concepts. The articles are designed to be focused and concise and get straight to the topic without a lot of fluff. Everything written to this point is listed below:
-
Slides and Code for my Silverlight and ASP.NET AJAX Integration Talk
-
Speaking on Silverlight and ASP.NET AJAX Integration at Desert Code Camp
-
ASP.NET AJAX Script Library Patch for iPhone 1.01 Software Update
Matt Gibbs recently posted about an update to the ASP.NET AJAX Script library that fixes functionality broken when trying to run ASP.NET AJAX-enabled pages in the iPhone's Safari browser when the 1.01 software update has been applied to a phone. He posts a step-by-step guide to using the scripts and explains what was changed in case you're interested.
-
C# 3.0 Features: Object Initializers
C# 3.0 is just around the corner so I thought I'd start writing about a few of the features that it exposes and provide quick and concise examples of how they can be used. Many of the new features rely on the compiler to generate code that you would have had to write in the past. This can result in significantly less code compared to C# 2.0 syntax in many cases. Here's a list of some of the key features available in C# 3.0:
-
Silverlight 1.0 Goes Gold!
Silverlight 1.0 is now gold and being used on several sites such as Halo 3 and Major League Baseball. Check out Scott Guthrie's blog for additional details on it as well as announcements about Silverlight running on Linux in the future.
