Quick tip: you can put sections of your code inside #region blocks in order to collapse and expand them using .NET Studio's outlining feature. The text after the #region keyword is displayed next to the plus/minus sign, so keep it descriptive.

For example:

#region database code

public void DBFunc1() {
  // .. a bunch of database code
}

public void DBFunc2() {
  // .. a bunch of database code
}

#endregion

#region encryption code

public EncryptionFunc1() {
  // .. a bunch of encryption code
}

public EncryptionFunc2() {
  // .. a bunch of encryption code
}

#endregion

would give you two code regions named "database code" and "encryption code". You could then collapse the regions you're not interested so the code view is easier to manage.

You can also nest regions:

#region a big database function

public void BigDBFunction() {

#region some code
  // a bunch of code...
#endregion

#region some more code
  // a bunch of code...
#endregion

#region even more code
  // a bunch of code...
#endregion

}
#endregion

to gain finer control of what code is shown or hidden. In the above example, you could hide the entire function, or just hide sections of it.

Check out MSDN's page on outlining and hiding code to get more information on regions and what menu options are available. Happy outlining!

Sometimes the SMTP Virtual Server will disappear in the IIS Manager on Windows 2003, especially if you've done some installing/uninstalling/reinstalling of IIS, SMTP, etc.

Until it's fixed in Service Pack 1 (we hope), you can restore it by running this from the command prompt (in the Accessories program menu):

regsvr32 c:\windows\system32\inetsrv\smtpsnap.dll

Laszlo appears to be a free, open-source tool for quickly building rich web applications. It takes XML-based source files and generates Flash applications. Sounds very similar to Macromedia's own Flex, except that Laszlo is free and Flex is $10,000 per CPU, last time I checked. Hmm.

I've spoken with other developers about how to use the SMTP service built into Windows 2003 as an outbound SMTP relay. For example, say you have a small web site with an "Email this web page to a friend" feature. You want to be able to use Windows 2003 SMTP to send emails to anyone in the world, yet protect yourself from being used as an open relay by spammers. Normally you would make use of the authentication with Active Directory, but it becomes more problematic if you want to use the SMTP service from something like PHP or another machine.

Here's how to make Windows SMTP a protected open relay:

Open up IIS Manager and expand the nodes under your computer.

Right-click Default SMTP Virtual Server and choose Properties

Click the Access tab, click Authentication, and check Anonymous Access. Uncheck the other boxes. Click OK. This allows Windows SMTP to send emails without authentication.

Click the Relay button, click Add, and specify which machines shouuld be allowed to send emails. At least enter 127.0.0.1 (the local machine) but you can also enter a network subnet to allow other machines on your network to use it as an SMTP server. Click OK.

Click OK, and close IIS Manager.
That's it. You can now use that machine as a general purpose SMTP box.

link to this post    view/post comments (0)   

You can enable some basic CPU monitoring in IIS, but the downside is you have very few options if a given site takes up too much CPU. You can either a) record something in the event log, or b) have the site shut down. Step a) doesn't prevent the haywire site from continuing to hog the CPU, yet step b) is too drastic.

What we'd really like is a way to throttle a site based on CPU, similar to IIS bandwidth throttling. Thankfully, there's a general way to accomplish this:

1. Enable CPU monitoring for each app pool (go with 85% or less) and indicate that you want an event log message ("No action"), not a shutdown.
2. Enable bandwidth throttling for your sites and choose a high default value.
3. Write a script and schedule it to run every 5 minutes. This script should:
   • Scan the event log and look for messages indicating an app pool has surpassed its CPU limit. It should only consider messages that were recorded since the script was last run.
   • determine which sites correspond to that app pool.
   • lower the bandwidth throttle of each of those sites to some value, maybe 75% of its current throttle setting or 90% of its currently used bandwidth.
   • send an email notification.
   • repeat the above for any other offending app pools.
   • Record the time it started running so that next time it only looks for newer event log messages.
4. Write a second script that resets the bandwidth throttle values of all sites to their original high values. Run this script once a day during low traffic, e.g. 3am.

Now, any time a site starts taking up too much CPU, your script should automatically throttle its bandwidth down. If that site continues to consume CPU, the script will throttle its bandwidth down further. You could get fancy and keep track of which sites are behaving very badly (i.e. take up too much CPU regardless of bandwidth throttling) and perform some other action (send an email, restart that web site, etc.).