John Luif

Just saw that Visual Studio SP1 is out there.  It can be downloaded here.

I can see!  After all this time my sight has improved greatly and I can read and see afar just fine. 

As far for my problems with swelling and pain after the surgery my mother had no such problems, so it must just mean I’m a wuss.  The healing process is very slow and is by far the hardest thing mentally to put up with.  Once you are through it you will be happy with the results.

This is great, now if there is split teams (some on VPC and some on VMWare) the disks can just be converted, instead of just being able to convert vhd’s to vmdk’s it can go both ways.

Via Virtual PC Guy:

“As covered by Andrew Dugdell (aka Dugie) there is now a tool available to convert VMware virtual hard disks (VMDK) to Virtual PC / Virtual Server virtual hard disks (VHD).

To find out more go here.”

I just have not had time lately to upgrade DasBlog until now.  There are many updates including more configurability and some new themes.  Sooner or later I will get around to building my own theme because there are things I like about each out of the box theme but there is not one that I really like.

A coworker pointed me to PA Server Monitor the other day.  I’m very impressed with what it can do.  For me it monitors everything I need and more.  It can monitor:

- Event logs
- CPU usage
- Memory usage
- Free disk space
- Changed files and directories
- Running services
- Server temperature
- Directory quotas
- NIC usage
- Performance counter values
- POP, IMAP and SMTP mail servers
- Web page content and load times
- Ping response times
- TCP port response

There is a free version that works quite well.  With two licensing options (server based or monitor based) it is a very affordable tool (especially since the free version does everything I need).  I use it currently to monitor event logs and disk space on different servers.  You can attach a sound to the event log action; I recommend the Homer Simpson sound “Sweat merciful crap!” for when an exception is logged.

I went to download Virtual Server R2 and saw the Virtual Server 2005 Migration Toolkit.  The Virtual Server 2005 Migration Toolkit is:

“A free, downloadable tool for Virtual Server 2005, Virtual Server Migration Toolkit (VSMT) simplifies the migration of an operating system and installed applications from a physical server to a server running within a virtual machine that is provided and managed by Virtual Server 2005. With Virtual Server 2005, you can set up multiple virtual machines running different operating systems and applications on the same physical computer.”

This is very cool, I will have to check it out.

For a while now I was wondering why I could not Remote Desktop into my Vista box running Windows Live OneCare.  My windows firewall was off but then I noticed OneCare also has a firewall that automatically changes it settings based on the network you are connected to (usually changes to Restricted setting).  I put OneCare’s firewall setting to “Automatic (recommended)” and also unchecked “Automatically change my firewall protection level when I connect to an unsecured network” and that did it.

Using EntLib Logging and ExceptionHandling and trying to write both logging statements and exception information to a single log file can cause a <guid><filename>.log to be created.  The exception handling block, more specifically the  LoggingExceptionHandlerAssembler creates another LogWriter which if you are using a flat file tries to get a lock on the file and when it can’t it creates the <guid><filename>.log.  I solved this by changing the EntLib source so it checks if there is a LogWriter already created that is used by the tracer.  In the LoggingExceptionHandlerData.cs file the class LoggingExceptionHandlerAssembler has a method “Assemble”.  I changed this to read like the below:

public IExceptionHandler Assemble(IBuilderContext context, ExceptionHandlerData objectConfiguration, IConfigurationSource configurationSource, ConfigurationReflectionCache reflectionCache)
  {
   LoggingExceptionHandlerData castedObjectConfiguration = (LoggingExceptionHandlerData)objectConfiguration;

   LogWriter writer = Logger.Writer;
   if (writer == null)
    writer = (LogWriter)context.HeadOfChain.BuildUp(context, typeof(LogWriter), null, null);

   LoggingExceptionHandler createdObject = new LoggingExceptionHandler(
     castedObjectConfiguration.LogCategory,
     castedObjectConfiguration.EventId,
     castedObjectConfiguration.Severity,
     castedObjectConfiguration.Title,
     castedObjectConfiguration.Priority,
     castedObjectConfiguration.FormatterType,
     writer);

   return createdObject;
  }

Notice the null check on the writer, this fixed the issue with the guid files being created.

My two previous posts talked about using MSBuild tasks to move ClickOnce deployments and Reporting Services reports.  In this post I wanted to show how to use MSBuild, PSExec and Linkd to set up deployments from a QA environment to a staging and finally a production environment.

PSExec allows users to execute process remotely on another box.  Using PSExec you can execute Linkd on another box to create or remove junctions.  A junctions is basically a pointer from one folder to another kind of  like a symlink (unix).  The one difference to note between junctions and symlinks is if you delete the folder that has a junction to another folder the other folder also gets deleted.  In IIS you can set up a website or virtual directory to point to any folder.  The folder that IIS is looking at can have a junction on it pointing to another folder.

Add in MSBuild and you get a targets like this:

<Target Name="RemoveStagedJunctions">
  <Exec
   Timeout="15000"
   ContinueOnError="true"
   Command='$(MSBuildProjectDirectory)\bin\psexec.exe \\$(WebServer) -n 15 "c:\program files\junction\linkd.exe" $(StagedLocation) /D'>
  </Exec>
 </Target>

 <Target Name="CreateStagedJunctions">
  <Exec
   Timeout="15000"
   ContinueOnError="true"
   Command='$(MSBuildProjectDirectory)\bin\psexec.exe \\$(WebServer) -n 15 "c:\program files\junction\linkd.exe" $(StagedLocation) $(VersionsLocation)\WebSite_$(Version)'>
  </Exec>
 </Target>

The next questions is why?  By having a directory that contains different versions of the application and using junctions you can simply change the junction to go between versions.  If there is a problem with a release after it goes into production you can revert back to the previous version by simply changing the junction.  Also by using junctions it makes moving a release to production very clean and fast.  The important thing I protect against when moving from QA to a staging environment is if the application version (folder name) already exist then do not proceed with the deployment/move.  Both production and QA use a specific version of the application out of a “versions” folder.  The last thing I want to happen is to have the staged and production environments pointed at the same version since then staged or production would be pointed at the wrong database.