Loren Halvorson's Blog

If your only tool is a hammer...
Subversion 1.5.1 Windows install is available

I've been working on a presentation for our next User Group meeting on Continuous Integration, and wanted to set up a local Subversion server.  Of course I wanted to use the latest and greatest versions of everything. So I've been checking back daily for the appearance of the installer for Subversion 1.5.1 for Windows.  Setup-Subversion-1.5.1.en-us.msi showed up on August 15, 2008.

You can find it on the Subversion download site  When you couple this with the latest TortoiseSVN you are cookin' with gas!

I found this CoDe Magazine article by Rick Strahl very helpful for setting things up initially. Setting Up and Running Subversion and Tortoise SVN with Visual Studio and .NET

Automatic Properties Work in .NET 2.0

This was sort of an accidental discovery, I'm not the first to stumble on it, but it doesn't seem to be widely known. A colleague of mine asked me about an interesting behavior he noticed after switching to Visual Studio 2008.  He was still targeting the .NET 2.0 framework, but noticed the automatic property feature worked.

Automatic properties are where you can just say

public string SomeProperty { get; set; }

The compiler provides the backing field and implements the get and set for you. It's a very nice shorthand syntax for a common pattern. We were all under the impression that it was a new C# 3.0 language feature and could only be used if you targeted version 3.5 of the .NET Framework. After searching around for why it was still working on a .NET 2.0 app, I found many who verified what we were seeing. Indeed it does work, because it's a compiler feature, and 2008 uses the latest compiler even if you are targeting 2.0. Cool.

IE 7 and Firefox browsing tip...open links in new tab by clicking your mouse scroll wheel

This is widely known, but I still run across people who use IE 7, and/or Firefox but don't use this little trick. On most mice, the scroll wheel is a button as well as a wheel. Click on links using the scroll wheel, and the browser will open that page in a new tab in the background without taking focus away from the current page.

I find this extremely handy when browsing results from a search engine. As you visually scan through the search results, click the links that look promising using the scroll wheel. The browser will set to work to load those pages in the background as you continue to scan.  After you've got a good batch of pages loaded in your tabs, you can skip through the tabs quickly.

Posted: May 23 2008, 11:58 AM by lorenh | with 9 comment(s)
Filed under:
We're starting a .NET user group in south-central Minnesota

We are starting a .NET user group in Mankato, which is in south-central Minnesota. Hopefully we can attract developers in the area that (like me) sometimes find it hard to make the 1-1/2 hour drive to the nearest .NET user group in Minneapolis. They're doing a great job up there in the Twin Cities, and I'll still try to make it to some of their meetings, but I just have a feeling there is a community of developers here that don't get much of a chance to hang out with geeks and talk shop.

So we have set up a web site, and set the date and time for our kickoff meeting.

Mankato .NET User Group Kickoff Meeting

When: Tuesday, June 10, 7:00 - 9:00

Where: Bethany College, 700 Luther Dr, Mankato, Minnesota We'll be meeting in Meyer Hall room 130. If you park in the Meyer Hall lot, room 130 is the first door on the right when entering from the lower level entrance. Map can be found here, http://www.blc.edu/facilities/map/.

Agenda:

  • Introductions
  • Discuss regular meeting times & format
  • Discuss how to spread the word
  • Brainstorm topics and presenters
  • Presentation on new features in Visual Studio 2008 that make it a compelling upgrade

Web site: http://www.mankatodotnet.com

If you are a developer in south-central Minnesota, consider joining us. If you know a developer in our area, we'd much appreciate if you pass this on to them.

Posted: May 22 2008, 09:23 AM by lorenh | with 3 comment(s)
Filed under:
Evoluent Vertical Mouse now available in wireless model

I've praised this mouse before, but just discovered that the wireless model of the Evoluent Vertical Mouse is now available. I have the wired version, and it is without a doubt the most comfortable mouse I've ever used. I throw it in my bag and drag it back and forth between the office and home. (I wonder how long before the cord gets a short?).

The only modification I made was to physically disable the large bottom button closest to the desk by inserting a small rolled up piece of paper behind it because I kept hitting it inadvertently while just moving the mouse.

The wireless one would be nice if anyone wants to buy it for me, my birthday is coming up.  Anybody have one yet?  How does it work?  How is the battery life?

Visual Studio Industry Partners (VSIP) program not needed to build a Domain Specific Languages (DSL)

After listening to a DotNetRocks podcast that interviewed Kevin McNeish on DSLs and Software Factories, I was curious to check out the DSL toolkit for internal use by our developers. After installing the Visual Studio 2008 SDK, I started seeing a “VSIP License Required” in the Visual Studio 2005 splash screen, and “A VSIP license is required to use this version of Microsoft Visual Studio” in the about box of Visual Studio 2005.  However, within Visual Studio 2008’s about box I see “Visual Studio SDK License”.  I was confused and wondered exactly when a VSIP license is required. I contacted someone at Microsoft and received clarification on this.

The Microsoft person verified that it is not necessary to join the VSIP program in order to build and use your own DSL implementation, internally or externally.  Apparently when Visual Studio 2005 was first released, extending Visual Studio was only allowed by licensed partners, but this restriction was later lifted, and licenses aren't necessary anymore. Unfortunately the messages in the splash screen and about box were not updated. Good to know.

Posted: May 15 2008, 09:44 AM by lorenh | with 4 comment(s)
Filed under: ,
MSBuild 3.5 just made my day

While doing some troubleshooting on a project I needed to manually copy some debug assemblies around after every build. But there were a lot of them, and whenever I need to do something repeatedly I try automate it with a script of some sort...because I'm lazy of course. There are a lot of choices today for a little quick and dirty script like this, Batch files, VBScript, Powershell, NAnt, but I thought I'd give MSBuild a try because I figured it would be the least amount of hassle, since moving files around is one of it's main duties during a build. The script was simple to write, but I hit a snag...the destination files were read only, and the copy errored out. MSBuild 2.0's copy task doesn't have an option to overwrite read only files. But MSBuild 3.5 does, so I learned a couple of tricks.

1. Run MSBuild.exe from C:\Windows\Microsoft.NET\Framework\v3.5 (instead of C:\Windows\Microsoft.NET\Framework\v2.0.50727). I have an external tool macro set up in my text editor (Textpad) to run the script currently being edited with a shortcut key, so this was simple to re-point.

2. Tell MSBuild you are using 3.5 features by adding ToolsVersion="3.5" to the Project element.

<Project DefaultTargets="Copy"
        xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
        ToolsVersion="3.5">

  <ItemGroup>
    <Assembly Include="Project1\bin\Debug\Project1.*"/>
    <Assembly Include="Project2\bin\Debug\Project2.*"/>
    <!-- etc... -->
  </ItemGroup>

  <Target Name="Copy">
    <Copy SourceFiles="@(Assembly)"
            DestinationFolder="Destination\bin"
            OverwriteReadOnlyFiles="True"/>
  </Target>

</Project>

 

Two things I learned tonight moving an ASP.NET site from IIS6 to IIS7

Tonight I moved moved an ASP.NET site from IIS6 to IIS7. Things seemed broken pretty badly at first, and I wondered if I was making a mistake to leave the comfort of IIS6. However, it turned out to be minor changes to the web.config. I'm sure they're already well known and well documented, but I figured I would scribble them down in case I ever need to do it again.

1. Remove the built-in Membership, Role and Profile providers

If you are configuring your own Membership, Role or Profile providers with your own database connection string, make sure you remove the built-in ones.or you may get an exception about not being able to connect to "LocalSqlServer".  Which is the connection string used in machine.config for the stock providers. This did not happen under IIS6. So it turns out the bolded lines become very important under IIS7.

<membership defaultProvider="MembershipSqlProvider"...>
  <providers>
    <remove name="AspNetSqlMembershipProvider"/>
    <add name="MembershipSqlProvider"
           :
           connectionStringName="MyDatabaseConnection"/>
  </providers>
</membership>

<roleManager defaultProvider="RoleManagerSqlProvider"...>
  <providers>
    <remove name="AspNetSqlRoleProvider"/>
    <add name="RoleManagerSqlProvider"
           :
           connectionStringName="MyDatabaseConnection"/>
  </providers>
</roleManager>

<profile defaultProvider="SqlProfileProvider">
  <providers>
    <remove name="AspNetSqlProfileProvider"/>
    <add name="SqlProfileProvider"
           :
           connectionStringName="MyDatabaseConnection"/>
  </providers>
</profile>

2. Move your Modules and Handlers to the <system.webServer> section

This one took me a while to figure out, but it shouldn't have. I had a custom module that was redirecting to secure pages when necessary, and it was not firing under IIS7. So I instrumented it up with log statements, and still nothing. Hmm. A quick search turned up Rick Strahl's post on this.

<configuration>
 
  <system.web>
    <httpModules>
      MODULES DON'T GO HERE ANYMORE
    </httpModules>
    <httpHandlers>
      HANDLERS DON'T GO HERE ANYMORE
    </httpHandlers>
  </system.web>

  <system.webServer>
    <modules>
       FOR IIS7, MODULES GO HERE NOW
    </modules>
    <handlers>
       FOR IIS7 HANDLERS GO HERE NOW
    </handlers>
  </system.webServer>
 
<configuration>

Posted: Mar 11 2008, 11:07 PM by lorenh | with no comments
Filed under:
Just for fun, controlling a Lego Mindstorms NXT robot with Windows Workflow Foundation

Recently I was asked to give a presentation on Windows Workflow Foundation to some developers. Unfortunately I had never worked with it. So last week while I was reading an article about workflow, it occurred to me that the designer seemed very similar to the NXT-G programming environment my kids use to program their Lego (R) Mindstorms (R) NXT robot. There's no better way to learn something than to actually try to do something real with it, so I decided to try to write my own custom activities to control a robot through Bluetooth connection.

Now this is a silly little app that doesn't do anything useful, but I thought it was too interesting to let the code just languish on my hard-drive only to be cleaned up someday when I'm low on space. It served it's purpose for me to learn Workflow Foundation better. I just posted the code to the MSDN Code Gallery here: http://code.msdn.microsoft.com/NXTWorkflow. There's plenty of room for improvement, but it was sure fun to write.

It includes a console driver program, as well as a Winforms based application that hosts the Workflow designer. The designer hosted version is based on the excellent MSDN hosting example by Vihang Dalal found at http://msdn2.microsoft.com/en-us/library/aa480213.aspx. The bluetooth communication uses a wrapper called NXT# written by Bram Fokke at http://nxtsharp.fokke.net.

 The robot I used to develop the application:

Posted: Mar 06 2008, 03:09 PM by lorenh | with 1 comment(s)
Filed under: , , ,
Speed up load time of AJAX Control Toolkit controls while debugging

This is probably already well known and well documented, but I still occasionally see people bemoaning the slow load time of some of the controls in the AJAX Control Toolkit. The slow loading problem is particularly noticable when you are debugging pages that have many calendar controls, at least that's where I first noticed it.

In a post from Scott Guthrie, he explains why you should ..."never run production ASP.NET Applications with debug=true enabled". In this article, reason #4 states that "Scripts and images downloaded from the WebResources.axd handler are not cached". My theory is that this is the reason for the slow loading of the calendar control-laden pages when debugging your application. And sure enough when you set debug=false, the page loads faster thanks to the caching, but then you give up the ability to debug through your code. What should you do?

Well, there's a middle-ground that worked nicely for me. You can set the ScriptManager on pages with lots of AJAX Control Toolkit controls to run in release mode like this:

  <asp:ScriptManager ID="ScriptManager" runat="Server" ScriptMode="Release"/>

Then you can leave Debug="true" in your web.config while you are developing without suffering the slow load time.

Another thing you should consider doing is utilize the script combining feature introduced in build 10618 of the AJAX control toolkit, which is documented here. This can reduce the number of requests your page needs to make for all of the individual scripts. It's been a while since I set this up, but I think this was all that was necessary:

 Add this file to your web site:

 - - CombineScriptsHandler.ashx - -

<%@ WebHandler Language="C#" Class="CombineScriptsHandler" %>

using System;
using System.Web;
using AjaxControlToolkit;

public class CombineScriptsHandler : IHttpHandler
{
    /// <summary>
    /// ProcessRequest implementation outputs the combined script file
    /// </summary>
    /// <param name="context"></param>
    public void ProcessRequest(HttpContext context)
    {
        if (!ToolkitScriptManager.OutputCombinedScriptFile(context))
        {
            throw new InvalidOperationException("Combined script file output failed unexpectedly.");
        }
    }

    /// <summary>
    /// IsReusable implementation returns true since this class is stateless
    /// </summary>
    public bool IsReusable
    {
        get { return true; }
    }
}

- - -

Then use the ToolkitScriptManager instead of the straight ScriptManager in your pages, specifying the CombineScriptsHandlerUrl to point to the handler you just added, similar to this (note: the ScriptMode="Release" trick works here too).

- - MyPage.aspx - -

<%@ Page ..%> 
<%@ Register Assembly="AjaxControlToolkit" Namespace="AjaxControlToolkit" TagPrefix="ajaxToolkit" %>

:
<ajaxToolkit:ToolkitScriptManager ID="ScriptManager" runat="Server" EnablePartialRendering="true" ScriptMode="Release" CombineScriptsHandlerUrl="~/CombineScriptsHandler.ashx"/>
:

- - -

Posted: Feb 15 2008, 02:05 PM by lorenh | with 2 comment(s)
Filed under: ,
More Posts « Previous page - Next page »