Programmatically setting the version of the Enterprise Library Configuration Tool for Visual Studio

I previously wrote about the issue we ran into using Enterprise Library and Unity that caused us to have to roll our own version of the binaries.  The procedure to get the config tool to reference our custom binaries involves changing the EnterpriseLibraryConfigurationSet solution property.  Since we are developing a Starter Kit to be used for new projects starting up here at the Church I wanted to add to our Starter Kit automation the setting of the property to the appropriate value.  Tried as hard as I wanted I couldn't get it to work until I accessed the Solution Property using EntepriseLibraryConfigurationSetPropertyExtender.EnterpriseLibraryConfigurationSet which is how it was listed when I enumerated the property collection. 

So the one line piece of code to do the job is

Dte.Solution.Properties.Item("EntepriseLibraryConfigurationSetPropertyExtender.EnterpriseLibraryConfigurationSet").Value = "StackV1EntLib";

Of course that needs to be accompanied with an entry in the Registry that the StackV1EntLib string can point to which is listed below

[HKEY_CURRENT_USER\Software\Microsoft\Practices\EnterpriseLibraryV4\ConfigurationEditor\StackV1EntLib]

"ConfigurationUIAdapterClass"="Microsoft.Practices.EnterpriseLibrary.Configuration.Design.UI.SingleHierarchyConfigurationUIHostAdapter"


"ConfigurationUIAssemblyPath"="C:\\Program Files\\MSStack\\V1\\StackEntLib\\Microsoft.Practices.EnterpriseLibrary.Configuration.Design.UI.dll"


"ConfigurationUIPluginDirectory"="C:\\Program Files\\MSStack\\V1\\StackEntLib\\"

 

Technorati Tags: Enterprise Library,Unity,VSX

Programmatically setting multiple startup projects on a Visual Studio solution

  A month or so ago I was waist deep in Visual Studio automation code trying to figure out how to create a solution programmatically with multiple startup projects.  I searched and searched on the Internet, but could never find the answer.  I knew that the code I was writing was very, very close, but it wasn't working.  At the time I had to step away and work on other things that were more important, but today I was in and around that code and tried again.  I found the answer on good old Google in less than 10 minutes - http://www.dotnetmonster.com/Uwe/Forum.aspx/vs-ext/1609/Editing-DTE2-Solution-SolutionBuild-StartupProjects .  It is as simple as setting the StartupProjects property of the SolutionBuild object to an array of objects populated with the unique name of projects in the solution.  I had been trying to set it to a string array of the same thing!  Talk about close.  Either way job accomplished.  Our VS automation is now just a little more polished as a result.

Technorati Tags: Visual Studio,VSX

That darn backlog there is so much stuff in it!

  I used to be a believer that when a good idea came around you should throw it on the backlog.  Those ideas (or bugs) live on the backlog indefinitely waiting for their chance to "dance".  As I re-evaluate my thinking from a Lean perspective I am reconsidering that approach.  In Lean maintaining large amounts of inventory (queued inventory) is frowned up.  Without going into all the gory detail of Lean (if you are an Agilist, want to be an Agilist, or develop software go read about Lean and think about it in terms of your software development process - it will be good for you) large amounts of inventory lead to "inventory rot".  In the software world this amounts to requirements that were scoped two years ago by a Business Analyst that is no longer around or a bug reported by a tester two releases ago.  The information relevance in those backlog items has dropped considerably during the time that they were idle.  As time goes on and it becomes obvious that prioritizing them won't happen - close them.  Dump them.  If they are important they will show up again.

  In addition to trimming the backlog appropriately it may make sense to have tiered backlogs.  There will be a Sprint backlog (or Iteration Plan) that represents the work in flight.  It is useful to have an "on deck" backlog that represents the work coming up in the next 6 months or so.  The "long range" backlog represents those ideas and concepts that are more "out there" and likely are fairly vague, large, and inestimable.  Each backlog requires different types of care and feeding and involves different sets of people in the care and feeding process.  The Sprint backlog is the focus of the team, talked about in Standup as people report progress, and the tactical focus.  The On-Deck Backlog should be actively worked by the Business Analyst, Customers, Technical Lead/Architect, and Project Manager.  Perhaps this is a weekly, bi-weekly, or monthly meeting.  The Long Range backlog is likely discussed perhaps monthly or quarterly as needed to identify items ready to move on-deck and be fleshed out, identify new directions that need to be captured, and obsolete ideas that are no longer applicable (don't forget this one!).

  With bugs I subscribe to the Broken Window theory.  The more you have the less likely you are to care.  You have to be careful with that of course - take it too far and you end up with a product with no bugs, but no features either because you have spent all your time fixing bugs that weren't important.  Once a bug has been identified as costing more to fix than it is worth you start to have a case for closing it and dropping it off the bug backlog.

  The goal is to make sure your focus is where it needs to be.  Your Sprint Backlog efforts should be  focused on execution.  Moving those items through the development process as effectively as you can.  On-Deck Backlog efforts should be focused around locking down the requirements for the items so that they are ready to be executed on (a blog on how critical it is to do requirements definition is in the works).  The Long Range backlog efforts should be focused around making sure that you have outlined the key strategic elements for the future and analyzing them in the context of the market you are serving to see what value propositions make the most sense to pursue.

Technorati Tags: Agile,Backlog,Lean,Software Engineering

Using Resources with WPF and Winforms

I had a developer ask me how to use Resources the other day.  Honestly I had never used them for any production system and so I didn't know.  So I decided to find out.  Below is the code on how to do it in WPF and then after that how you would do it in Winforms.

WPF

I borrowed a lot of  this example from http://mostlytech.blogspot.com/2007/09/enumerating-xaml-baml-files-in-assembly.html.  The article I link to showed how to iterate through Resources files that are in your solution with the Build Action set to Resource.  I then use that to put an image on a button that alternates every time it is clicked.  At http://forums.msdn.microsoft.com/en-US/wpf/thread/1bb025e8-a20a-43c4-a760-8666c63ff624/ it explains how to work with Resources that you define in the Resource tab in the Project Properties.  You can also set an image directly in XAML as shown below

using System;

using System.Collections;

using System.Collections.Generic;

using System.IO;

using System.Reflection;

using System.Resources;

using System.Windows;

using System.Windows.Media.Imaging;

namespace WpfApplication1

{

    /// <summary>

    /// Interaction logic for Window1.xaml

    /// </summary>

    public partial class Window1 : Window

    {

        private int ButtonClicks = 0;

        List<object> EmbeddedResources = new List<object>();

        public Window1()

        {

            InitializeComponent();

            Assembly asm = Assembly.GetExecutingAssembly();

            Stream stream = asm.GetManifestResourceStream(asm.GetName().Name + ".g.resources");

            using (ResourceReader reader = new ResourceReader(stream))

            {

                foreach (DictionaryEntry entry in reader)

                {

                    if (entry.Key.ToString().Contains(".jpg"))

                    EmbeddedResources.Add(entry.Key);

                }

            }

        }

        private void Button_Click(object sender, RoutedEventArgs e)

        {

            ButtonClicks++;

            ButtonImage.Source = new BitmapImage(new Uri(EmbeddedResources[ButtonClicks % 2].ToString(), UriKind.Relative));

        }

    }

}

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Grid>
        <Button Click="Button_Click">
        <Image Name="ButtonImage" Source="Images/IMG_7680.jpg" />
        </Button>
    </Grid>
</Window>

Winforms

I didn't spend as much time looking at the Winforms side of things, but here is a snippet of code that can be used.  Note that I set the Build Action for the Image file to EmbeddedResource because that is what all the examples said to do.  Bitmap has an overload that allows it to resolve Resource References.  The name of the resource becomes <Namespace>.<Path>.<Filename>.

pictureBox1.Image = new Bitmap(typeof(Form1), "Images.IMG_7680.jpg");

Technorati Tags: WPF,Winforms,Resources,.NET