in

CodePrairie .NET

South Dakota .NET User Group

chrisortman

June 2006 - Posts

  • Resharper vs RefactorPro

    Doug Rohm mentioned today on his preference of RefactorPro (DevExpress) vs Resharper (JetBrains). I've also used both but I found that I liked the Resharper functionality much better. One of my favorites is alt+insert to generate getters / setters and constructors, something I never found in RefactorPro. I totally feel his performance pains with Resharper, although I also had poor performance using Refactor. I do want to point out that much of my performance problems were alleviated thanks to this post http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=144370&SiteID=1 which another developer I work with found. I checked out some of the new features coming in Refactor 2.0 though and they do look very promising (especially the extensibility), guess I'll have to wait for it to come out and reevaluate.
    Posted Jun 14 2006, 06:39 PM by chrisortman with 1 comment(s)
    Filed under:
  • Dreams really can come true

  • Here's a great forum post about msbuild!

    Posted Jun 09 2006, 12:42 PM by chrisortman with no comments
    Filed under:
  • Told ya so

    Most people I talk to know of my disdain for myspace, here's just another reason I don't like it http://www.newscientist.com/article/mg19025556.200?DCMP=NLC-nletter&nsref=mg19025556.200

  • a note on comments

    For some reason there are no links to add comments on the aggregate view, if you'd like to comment on something you need to goto http://www.codeprairie.net/blogs/chrisortman
  • Another MSBuild gotcha

    I came across an oddity last night when trying to setup a build….

     

    I’m going to go into a little more detail than is maybe necessary incase someone sees it and can say whoa back up your going about this all wrong

     

    I have the following root directory structure

     

    DependentFiles

    Source

    Vendor

    VendorLibs

    Vendor.proj

    Myproject.targets

     

    I use several open source projects which I need to build myself because they rely on each other but the distributed binaries don’t all have strong names or necessarily reference the correct version of some other tool, so in my Vendor folder I have put the source for these projects.  I don’t want to have to ProjectReference to these guys from my own code since I typically don’t want to have them all loaded in my solution and I wanted to make minimal changes to the Vendor code so I can take updates with less hassle. So I created a vendor.proj build file that basically will build all the code in \Vendor and copy the resulting dll’s and pdb’s to VendorLibs, my projects then reference these dll’s. One thing I found with this approach is that doing master-child builds sucks when it comes to path resolution if the child projects don’t reference paths using $(MSBuildProjectDirectory)\<some relative path>. After some toiling I did get vendor.proj to build correctly when executing from the root directory alo (msbuild vendor.proj /t:Build

     

    Here’s a typical target in my vendor.proj file:

      <ItemGroup>

        <DependentFiles Include="$(MSBuildProjectDirectory)\DependentFiles\**\*.dll" />

     

        <CastleDynProxyProjFiles Include="$(MSBuildProjectDirectory)\Vendor\Castle\Tools\DynamicProxy\Castle.DynamicProxy\Castle.DynamicProxy-2.0.csproj" />

       

        <CastleIOCProjFiles Include="$(MSBuildProjectDirectory)\Vendor\Castle\InversionOfControl\**\*-2-0.csproj" />

      </ItemGroup>

    <Target Name="build-castle-ioc" DependsOnTargets="build-dynamic-proxy">      

        <MSBuild Projects="@(CastleIOCProjFiles)" Properties="Configuration=$(Configuration)"

                 Targets="$(vstargets)">

          <Output TaskParameter="TargetOutputs" ItemName="CastleIOCOut"/>

        </MSBuild>

        <CreateItem Include="@(CastleIOCOut)" AdditionalMetadata="Project=CastleIOC">

          <Output TaskParameter="Include" ItemName="BuiltAssemblies"/>

        </CreateItem>

      </Target>

     

    Now onto my code under Source I have:

    Project1

    Project2

    Project3

    …etc….

    MyProject.sln

     

    Now when I build my code I want to ensure that the VendorLibs are up-to-date (I haven’t done up to date yet, I just make sure the files are there) and if not I need to rebuild the vendor code. I accomplish this in my MyProject.targets file using something like this:

     

      <PropertyGroup>

        <ResolveReferencesDependsOn>

          EnsureVendorLibs;

          $(ResolveReferencesDependsOn);

        </ResolveReferencesDependsOn>

      </PropertyGroup>

     

    <Target Name="EnsureVendorLibs">

           

        <MSBuild Projects="..\..\vendor.proj" Targets="Build"

                 Properties="Configuration=$(Configuration) "

                 Condition="!Exists('$(MSBuildProjectDirectory)\..\..\VendorLibs')"

                 />

      </Target>

     

    Now here’s what I ran into say from my Source folder I do

    Msbuild MyProject.sln /t:Build

    And it needs to build the VendorLibs ....

    Some of the projects under Vendor use project to project references which when called via msbuild vendor.proj /t:Build and being passed using an ItemGroup of the project files to an msbuild task will happily resolve….however when my build using MyProject.sln and call to EnsureVendorLibs the project references fail to resolve. Here’s why, in the Microsoft.common.targets file we have this task

     

    <Target

            Name="SplitProjectReferencesByType"

            Condition="'@(ProjectReference)'!=''">

     

            <!-- Assign a project configuration to each project reference if we're building a solution file. -->

            <AssignProjectConfiguration

                ProjectReferences="@(ProjectReference)"

                SolutionConfigurationContents="$(CurrentSolutionConfigurationContents)"

                Condition="'$(BuildingSolutionFile)'=='true'">

     

                <Output TaskParameter="AssignedProjects" ItemName="_ProjectReferenceWithConfiguration"/>

     

            </AssignProjectConfiguration>

     

    <!—rest of target ommitted for brevity sake -- >

        </Target>

     

    Well since I initially invoked MSBuild using msbuild MyProject.sln /t:Build the $(BuildingSolutionFile) property will evaluate to true which causes resolution to fail because the ProjectReferences are not defined in my solution (or any projects built by my solution)

    The workaround I used was to change my EnsureVendorLibs target like so

    <Target Name="EnsureVendorLibs">

           

        <MSBuild Projects="..\..\vendor.proj" Targets="Build"

                 Properties="Configuration=$(Configuration);BuildingSolutionFile=false"

                 Condition="!Exists('$(MSBuildProjectDirectory)\..\..\VendorLibs')"

                 />

     

        <Message Text="$(BuildingSolutionFile)" />

      </Target>

     

    Which now when I execute will build correctly and after the task completes the $(BuildingSolutionFile) will contain it’s original value.

     

     I posted this to the msdn forums also http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=464794&SiteID=1&mode=1

    Posted Jun 09 2006, 09:48 AM by chrisortman with no comments
    Filed under:
  • MSBuild Gotchas

    Here's a couple of MSBuild gotchas...

    When specifying paths to your Include / Exclude ItemGroups make sure to use backslashes (\) I've found that forward slashes (/) seem to make the exclusion not work...my guess is that they compare it against the current search using back slashes on the search item, but not on my include item....haven't dug into the code....just a guess.

    Second be careful that when you are overriding default MSFT targets using PropertyGroups as shown http://blogs.msdn.com/msbuild/archive/2006/02/10/528822.aspx that you do it at the bottom of your project file after the default imports. I was overriding the behavior in my common targets file, but had my import statment before the microsoft one...so of course it didn't work.

    Posted Jun 08 2006, 11:47 PM by chrisortman with no comments
    Filed under: ,
  • Dynamic languages on the CLR

    As I find myself cranking out a lot of code lately I am really yearning for a more wrist friendly way of doing things. I also think I'd see a lot of benefit from a dynamic language when writing unit tests since I want to crank them out quickly and not have language / compiler get in the way. I've also been looking into Ruby and Ruby on Rails and there is much to be desired there. The sheer power of the rails 10 minute video is staggering. Sure there are some for Asp.net also, but the difference is in my willingness to actually build an application using the practices in the Asp.Net side. The concepts behind rails are uber!

    So in my initial hunting I've managed to find a few options:

    RubyCLR -- this provides an interop layer between .NET and Ruby. I've used this a bit and really like what I see. My biggest complaint is that the only way I've been able to pass an object defined in ruby back to .NET is by implementing an interface....not a huge deal, just not ideal. This was created by Jon Lam, and if you're into blogging and aren't reading his...you're missing out. Check out http://www.iunknown.com

    IronRuby -- Is a Ruby interpreter for .NET. Since this runs inside the CLR you can do some things here (like inheritance) that you can't do using RubyCLR, however you also can't use all / any ruby syntax either. I haven't tried this yet, but it appears to be a bit less mature than RubyCLR at this point.

    IronPython -- Wow, kudos to you Microsoft. This is a python interpreter for the .NET framework. It is in the late beta stages and from what I have read is fairly stable and performs well. It also looks like it has visual studio integration. The only thing really keeping me from trying it out at this point is that I don't know python syntax very well and from what I've glanced at so far it doesn't look very inviting (especially after looking at Ruby code)....I see all kinds of _ and __ all over the place.

    Boo -- This is a new language with it's own compiler. It offers similar syntax to ruby and pythong (it actually seems like it is taking the better from both) and compiles natively to .NET code. It is very tempting in many regards, however I'm leary of moving to a non-standard custom language that may or may not last or stay supported.

    If anyone has any stories to share with any of these I'd love to hear about them.

    Posted Jun 07 2006, 09:35 AM by chrisortman with no comments
    Filed under:
Powered by Community Server (Commercial Edition), by Telligent Systems