March 2008 - Posts

• 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>   Posted Mar 27 2008, 01:57 PM by lorenh with 5 comment(s) Filed under: General Software Development, MSBuild

• 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: ASP.NET IIS7

• 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 no comments Filed under: Robotics, Workflow, WWF, C#