Imagine if everyone in the world knew .NET programming. The world might be a bit strange, but at least these pickup lines might work.
If I were a generic collection, I'd be strongly typed for you.
You must be the latest version, because I've been checking you out.
I have a small problem. I put an object in a Dictionary
, but I lost the key! Can you come back to my place and help me look for it? A TypeConverter just returned my heart, and it's ready to assign to you.
Let's turn off option strict and do some late night binding.
So, what's your hash code?
It seems everybody loves the thread pool. The default scheduler in Windows Workflow uses the thread pool, as does ASP.NET and the BeginInvoke method of every delegate. There is only one pool per process, which seems a bit limiting with such a big party inside.
Joe Duffy says there is a lot of work going into improving the ThreadPool in future versions of the base class library, I wonder if future versions will allow for some partitioning of work. .
A couple people have asked me about custom thread pools. I do see the need in some scenarios, but writing a custom thread pool is hard. I generally point people to custom thread pools that smart people have already built:
Jon Skeet has a custom thread pool class on this page. The pool is configurable and allows you to separate your threads from the threads in the system pool.
Mike Woodring has a custom thread pool available on this page. The thread pool is configurable, instrumented, and has a great many features.
Information week has been covering the trial of a sysadmin accused of sabotaging 1,000 UBS Paine Webber servers. There is an abundance of circumstantial evidence in this case. Investigators found a printout of malicious code in the defendant’s bedroom, and the defendant bought an outstanding amount of stock puts that would benefit from a drop in UBS's price. Direct evidence, however, is from the ephemeral world of 1s and 0s: VPN logs, tape backups, and server audit trails. The defense called all these technologies into question.
Wolfe also used his closing arguments to attempt to rebut defense theories. Chris Adams, Duronio's attorney, has argued that hackers could have been responsible for the attack. He also argued that another systems administrator … did the attack, or that it was a penetration test gone awry by Cisco Systems. The attorney at different times went after the first forensics company to work on the case, @Stake Inc., saying that they couldn't be trusted because hackers worked for the company. Then he claimed the U.S. Secret Service, called in to investigate the case, did sloppy investigative work, as did the government's forensics expert. The defense's forensics expert … testified that he couldn't be sure that the logic bomb was responsible for the damage to the UBS system.
The defense went wild with conspiracy theories. When 40 people have the root password it’s easy to raise a shadow of a doubt. Even if the systems recorded biometric information, would you still trust an audit log? A rouge admin could alter any bit on a computer. The jury in this case found the defendant guily of securities and computer fraud on Wednesday. He'll face a maximum sentence of 6.5 to 8 years.
If you had to decide the fate of a person, what technologies would you trust as reliable sources of evidence?
A: If you are just rotating advertisements on a page, using LoadControl is simple.
If you have a complex control with ViewState and events firing during postback, then LoadControl is difficult. It's not just LoadControl either - newing up a server side control and adding it to a Controls collection is also tricky.
ASP.NET provides a thick layer of abstraction for building web applications, but dynamically loading controls requires intimate knowledge of what is happening underneath the covers. You'll need to know the page lifecycle inside and out. You'll need to know how ViewState works, and how the runtime raises postback events. It takes some time, experience, trail, and error.
Here is a tip: keep it simple. I've seen developers overly complicate pages with dynamically loaded controls. In some scenarios, we can get the same behavior by adding the controls in markup and toggling the Visible property. The page is easier to test and modify, and generally will have fewer bugs.
Also, this "feature" doesn't have a bad design, really. You have to realize before going down this path that you'll be shouldering many responsibilities for your control that ASP.NET would otherwise take care of. It would be difficult for Microsoft to provide a general-purpose solution to dynamically loaded controls (but they might be able to cover 60% of the use cases).
If you still need dynamic controls, then read everything Scott Mitchell writes:
Dynamic Controls in ASP.NET
Working With Dynamically Created Controls
Dynamic Web Controls, Postbacks, and View State
Control building and ViewState Redux
Tip: When Adding Dynamic Controls, Specify an ID
Q: Has Microsoft built and shipped any products with .NET?
A: A quick look around turns up the following frameworks, applications, and utilities with at least some managed code inside. I'm sure there are others I don't know about.
BizTalk Server, Team Foundation Server, SQL Server Reporting Services, SQL Server Integration Services , Microsoft Small Business Accouting, SharePoint Services, Content Management Server, MSDN Online, Media Center, Visual Studio 2005
What else?
Yesterday we looked at stopping ASP.NET worker processes using PowerShell. However, I don't always want to stop the process by exe name or process ID, but by the name of the IIS application pool that the process is hosting. One way to do the job is with the iisapp.vbs script that ships with Windows Server.
PS>iisapp.vbs W3WP.exe PID: 4420 AppPoolId: aspNet20 W3WP.exe PID: 2572 AppPoolId: DefaultAppPool
How does iisapp.vbs figure this out? The script uses WMI to look at the command line that started w3wp.exe. There is a parameter (-ap) that specifies the application pool by name.
I beat my head against the wall trying to figure out a nice way to do this in PowerShell. Finally, I came across a post by abhishek, who wrote some script to find the services living inside svchost.exe, and everything became clear.
This is a function named get-aspnetwp. I can put this in my home configuration so it's always available. The function first gets a list of all processes named w3wp. The System.Diagnostics.Process objects in the list do not expose a property to inspect the command line, but we can use a WMI query to fetch the command line. A regular expression (-match) can parse out the application pool name (which always follows the -ap switch).
The function dynamically adds a property with the add-member cmdlet. The new property (AppPoolName) holds the application pool name. Ah, the power of a dynamic language! The last step in the function is to filter the list of objects against the incoming name parameter.
Now we can party...
PS> get-aspnetwp Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName ------- ------ ----- ----- ----- ------ -- ----------- 419 30 31128 3924 144 2.09 2572 w3wp 387 14 24580 7232 157 1.00 4420 w3wp
and …
PS> get-aspnetwp | select Id, AppPoolName, StartTime | format-list Id : 4420 AppPoolName : aspNet20 StartTime : 7/10/2006 10:31:08 PM Id : 6064 AppPoolName : DefaultAppPool StartTime : 7/10/2006 11:56:57 PM
and …
PS> get-aspnetwp DefaultAppPool | kill
The little function gives us object we can pipe to other cmdlets, like measure-object, where-object, select-object, etc. Sweetness.
For more PowerShell goodness, check out the Powershell blog, the free IDE, and Scott Hanselman's podcast.
I've been learning PowerShell and alternating between frustration and fascination. PowerShell is potent but comes with a learning curve. ScottGu recently posted about using tasklist and taskkill to stop an ASP.NET worker process, and I thought it might be a good experience to give this a whirl at the PS prompt.
Cmdlets are the built-in commands of PowerShell. The get-process cmdlet is equivalent to tasklist, and can return all running processes:
PS> get-process | where { $_.Name -eq "w3wp" } Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName ------- ------ ----- ----- ----- ------ -- ----------- 480 14 26288 11552 159 1.52 2580 w3wp 351 21 12464 22360 111 0.45 4616 w3wp
Here we've filtered the process list by piping into the where-object cmdlet. The two worker processes pass the filter and appear in the output.
One of the significant concepts behind PS is that it doesn't pipe plain text - it passes objects in the pipeline. The get-process cmdlet returns a collection of System.Diagnostics.Process objects - the same Process class we know and love from the .NET base class library, and the same class that has a Kill method.
PS> get-process | where { $_.Name -eq "w3wp" } | foreach { $_.Kill() }
$_ represents the current pipeline object, so the above command will invoke the Kill method of each Process object that makes it's way through the filter. We can use some shortcuts for less typing.
PS> get-process w3wp | stop-process
This filters the process list using a parameter to get-process, and pipes the output into a stop-process cmdlet. If this still seems too wordy, we can take a couple more shortcuts and use the get-process alias of gps, and the stop-processes alias of kill:
PS> gps w3wp | kill
Tune in tomorrow when we find the application pool name and uptime of each worker process.
The problem is all inside your head
She said to me
The answer is easy if you
Take it logically
I’d like to help you in your struggle
To be free
There must be fifty ways
To kill a process
CHORUS:
You need a PowerShell hack, Jack
Do a task scan, Stan
You don’t need to destroy, Roy
Just get yourself free
Write in C++, Gus
You don’t need to discuss much
Just drop the PID, Lee
And get yourself free…
Apologies to Paul Simon.