What options are there to deploy .NET applications to a server farm? Unless you're at a small web shop, you've likely never had to encounter this question. But this last month, it was this very question that I began to ponder as I began a rotation to a different group whose responsibilities include managing builds for the weekly release and the deployment to a web farm.
So what options are there? At my previous job, the code deployments were a manual process where the IT group would run an MSI file we generated during the build and use this to deploy to the .NET code to the web and application servers. As the code was being deployed, SQL scripts would be executed via a custom tool designed to execute the scripts on multiple databases at once to ease in this step of the deployment and to better record the errors.
But is a manual process the only way to go? Certainly not. One option is to utilize Windows Group Policy to remotely install an MSI containing the updated code. While developers may not be familiar with this functionality, IT staff members will likely have used this before to manage the software on desktops or servers remotely.
Another option is to utilize Microsoft's Web Deploy Tool to create deployment packages to push out to code to other servers. This tool can take a snapshot of a website on one server and replicate it to another, or identify changes to a server and replicate them to another server. Deploying these changes is still a manual process, but the Web Deploy tool is a powerful tool that can make the deployment process easier.
Perhaps the most intriguing option out there is Microsoft's Web Farm Framework. This tool can work with the Web Deploy tool or an MSI to automatically handle the deployment to a farm of servers. According to Scott Gu's article on the tool, the Web Farm Framework is an IIS extension that is installed on each server in the farm. One server is identified as the 'Primary' server. Any changes made to this server will be replicated to the other servers in the farm, one at a time in order to keep the entire farm operational.
The Web Farm Framework makes deployments easy, but as with many tools, there are tradeoffs. Deployments will take longer as only one server is pulled from the farm at a time. Because of this strategy, all but one server can respond to requests during the deployment, yet the servers will be on different versions of the code. And what if there is a central database that the web farm utilizes that must be updated? When should the database be updated?
What's the best option for deploying .NET code to a Server Farm? It depends on your situation.
If you have a strong IT staff, perhaps they can administer the Web Farm using Windows Group Policy and MSI's that are created during the build process.
If the IT staff is not familiar with Windows Group Policy, perhaps Web Farm Framework is worthwhile option, especially if the system cannot be taken down during an upgrade.
If you have the spare development staff, your best option might be to build your own tools. This requires a group of developers with an understanding of how the system works as a whole, but with the effort, you can build yourself a tool-set geared directly towards your server farm.
Tuesday, September 6, 2011
Saturday, July 9, 2011
Inspecting the Memory dump of a .NET Application
There are times when a .NET application crashes and what logging is in place is not enough. In this case, if you happen to have a memory dump of the application in a .dmp file, then the application's memory and stack trace of the application's threads can be investigated, with the right tools.
The Windows Debugger is the tool for investigating Windows memory dump files. Microsoft provides this tool to query the memory dump files, files with the .dmp extension. On its own, this tool cannot show the stack trace for .NET 2.0 applications, but with the extension PSSCore2, .NET stack traces can be viewed and a great level of detail gleamed from the stack trace. PSSCore2 replaces an older tool SOS. Most of the resources I've found refer to SOS instead of PSSCore2, though the commands for the most part are the same between the two systems.
Once both of these tools have been installed, open the memory dump file with Windows Debugger. After the memory dump file has been loaded, issue the command:
.load clr10\psscore2
You may have to replace clr10 with the folder that you placed psscore2. If you place the psscore2 dll in the same folder as the Windows Debugger, then the command would simply be:
.load psscore2
But how do you use the Windows Debugger once its been installed? This article details the basic steps for loading the old extensions, but it still contains some good references (just replace references to 'sos' with 'psscore2'). This blog post from MSDN outlines some of the most useful commands and how to use them. Also, this blog post provides a real world use case for the Windbg tool. Finally, this blog post contains numerous links and a few random tidbits about the tool.
This outlines most of the useful pages I've found on the web for loading the memory dump of a .NET application. The command “!help” will return the name of the various commands available for the psscore2 extension. In general, commands that start with “!” refer to the commands available in the loaded extension, while those starting with “.” are those available natively in the Windows debugger.
The Windows Debugger is the tool for investigating Windows memory dump files. Microsoft provides this tool to query the memory dump files, files with the .dmp extension. On its own, this tool cannot show the stack trace for .NET 2.0 applications, but with the extension PSSCore2, .NET stack traces can be viewed and a great level of detail gleamed from the stack trace. PSSCore2 replaces an older tool SOS. Most of the resources I've found refer to SOS instead of PSSCore2, though the commands for the most part are the same between the two systems.
Once both of these tools have been installed, open the memory dump file with Windows Debugger. After the memory dump file has been loaded, issue the command:
.load clr10\psscore2
You may have to replace clr10 with the folder that you placed psscore2. If you place the psscore2 dll in the same folder as the Windows Debugger, then the command would simply be:
.load psscore2
But how do you use the Windows Debugger once its been installed? This article details the basic steps for loading the old extensions, but it still contains some good references (just replace references to 'sos' with 'psscore2'). This blog post from MSDN outlines some of the most useful commands and how to use them. Also, this blog post provides a real world use case for the Windbg tool. Finally, this blog post contains numerous links and a few random tidbits about the tool.
This outlines most of the useful pages I've found on the web for loading the memory dump of a .NET application. The command “!help” will return the name of the various commands available for the psscore2 extension. In general, commands that start with “!” refer to the commands available in the loaded extension, while those starting with “.” are those available natively in the Windows debugger.
Wednesday, June 8, 2011
Is the Dream of Courier about to be fulfilled?
A couple weeks ago, a new project appeared on Kickstarter that got a bit of attention. Kickstarter is a site that allows anyone to fund projects that they like in hopes that the project will become a reality. In many cases, those who donate to a project will receive things in return, such as a copy of the application (if its software).
This project, which is named Taposé, provides a few interesting videos on the planned design of the application. Watching these videos is a bit of deja vu, with a journal like application on half of the screen and various other applications in the other side. In fact, the title of the project says it all: Bringing the Courier to the iPad.
Despite the fact that the Microsoft announced the Courier's demise over a year ago, the device's possibility always stuck with me. And obviously, I was not the only one taken in by the device's promise. The Kickstarter project had a goal of $10,000, but surpassed it with $26,561.
My initial reaction to this was obvious excitement, with a bit of scorn, since I'd rather not pony up the money for an iPad. I'm no fan of Apple products (I don't own a single one), but if the only way to get Courier like functionality is to buy an iPad, well, I might have to give in to the dark side.
(Its funny. Back in the mid 90's, when my parents bought a Pentium 1 PC with Windows 95, my 5th grade teacher claimed I was going to the dark side (he was a big Mac guy). But I stand by my statement. Apple seems as dark today as Microsoft did back then. Oh the irony of Apple's '1984' commercial when viewed today).
But, given the amount of money the Tapose team raised, they areconsidering a Droid application. Being a happy Droid phone owner, a Droid tablet is one device I can see myself owning without switching allegiances. I hope these guys the best of luck. Perhaps there will be a Droid tablet on store shelves in a few months promising Courier like functionality right out of the box.
Subscribe to:
Posts (Atom)