IIS looses changes after restart

Mike Phelps sent this tip around to our team a couple weeks ago. I've experienced this problem and never put all the pieces before. Not it makes perfect sense. Now if I coule get him to start his own blog ;)

IIS runs strictly from memory (i.e, the IIS metabase is loaded to RAM). If you make changes to IIS, they are only made in memory. The changes don't actually stick until IIS writes to disk. This can occur with safely shutting down windows, or restarting IIS without a timeout/clicking End Now.

Want to see for yourself?

• 1) Go to properties of the DataPortal web site, and change the anonymous credentials to be your user.
  2) Close the IIS control panel.
  3) Start/Run iisreset /timeout:0

  • A)This forces IIS to shut down, without saving to disk. The wait time is used to persist to disk.

  4) Check the user you changed in #1. It will be back to the original user.

The point: Be wary of using the timeout option when you've made metabase changes.

Agile Pep Talk

I had the opportunity to spend lunch with Matt Ring last week. He contacted me via my blog (Someone reads it!). He needed an "agile pep talk". He's on the right track and hopefully I gave him a couple practical tips he could use as soon as he got back to the office.

If you need an "agile pep talk" or have some general questions on how to implement agile practices on your projects, feel free to contact me and we can grab some lunch and chat. Or for those of you don't eat, you can find me at every Agile Iowa and Iowa .NET User Group meeting.

Tracking Manual Tests with FitNesse

Our team has been working with FitNesse for a couple months and I believe we are getting over the learning "hump". A question came up today and I think we came up with a good solution and I wanted to share it with others who may be in transition period with FitNesse.

We aren't able to create FitNesse tests for all the functionality within the system so we do have some manual tests we need to verify are working. We need to track the manual tests within FitNesse so naturally we created a fixture!

Our "manual test" fixture contains 2 columns: Description and Passed. Description contains the manual test case and Passed contains the DATE the test passed. Entering the date allows us to track the last time the test passed. The fixture also takes a parameter for the number of days between manual tests.

!|Run Manual Tests Every|90|Days|
|Description|Passed|
|Do some manual test|5/18/2006|

When the fixture runs, it checks if the manual tests have passed within the configured time period. If not it will throw an error and provide visibly to aging manual test results.

Manual tests are not the ideal solution, however, by tracking the manual tests and their age we can provide a stop gap solution while teams are working to automate their user acceptance tests. It also gets the non-technical team members familiar with FitNesse syntax and hopefully prepare them to speak in the language of "FitNesse".

Have you or your team created a custom fixture to solve a problem? Please leave a comment and let me know.

NOTE: My blog is junk! If the human interface proof image doesn't show up, remove "#feedback" from the URL.

 

Rocky's comments on Test Driven Development

There is fued of sorts between the TDD crowd and Rocky Lhotka. I guess someone forgot to warn Rocky about the TDD crowd. This is the same community that got Microsoft to remove an article about TDD and VS 2005 that was on MDSN...briefly.

Rocky made some comments during a recent episode of DotNetRocks and Jeffery Palermo had some comments to which Rocky responded.

This is very interesting to me because we are using Rocky's .NET Business framework and trying to apply TDD practices with limited success. I would post about them, but I'm afraid I'll get flamed by the TDD crew (kidding, will kinda).

Great .NET Rocks Episodes

I just spent most of today working on my Microsoft SBA Add-in and listening/watching the latest couple episodes of .NET Rocks TV.

In these episodes Jean-Paul Boodhoo explains the Model-view-presenter (MVP) patterns, demonstrates NMock v2 framework, and builds a simple application using Test Driven Development/Design process. He does a great job explaining these concepts while developing a simple web form application. This is well worth your time if you have a couple hours to spare.

COM+/Enterprise Services Configuration

COM+ application components can be configured two ways. They can be configured to run as library applications (in-process) or as a Server application (out of process). Having a library component isn’t a problem since it is running with the application domain as the calling application. However, getting configuration settings into a Server application can be a challenge. So much so, that I typically recommend running a COM+ applications as a library application.

So why is configuration so difficult for server application? Well I’m glad you asked. It’s because the server application is running in a process called dllhost.exe. This process lives in the {Windows}\System32\ directory. The .NET framework “automagically” loads the configuration file named dllhost.exe.config to get the configuration settings as long as it is in the System32 directory. This works great until you have 2 Server components that need different configuration settings. Do you see the problem? 2 Processes – 1 Configuration file. Plus most IT departments freak out (with good reason) when you need to deploy a file to the System32 directory.

If you’ve read this far you’ll find the purpose for this post. I had a colleague send me a link that documents how to use the new options in COM+ 1.5 to use the application directory. This is the only time I’ve heard about using the application.manifest and the application.config files.

http://staff.newtelligence.net/clemensv/PermaLink.aspx?guid=0615b3cc-0fbf-4cf5-9d49-ae95b50f7e8d

 

Database Triggers Rant

The reasons I don't like database triggers:

1.) They are very difficult to debug
2.) They are a type of "magic" within a system. "Magic" is when something happens when I run code that I don't see in the code.
3.) They are not intuitive.

I find that database triggers get used in an organization when one or more of these things happen:
1.) A DBA has been tasked with writing application code
2.) The code is more difficult to change than it is to debug a database trigger
3.) The deployment process for code is significantly longer than the deployment process for SQL changes