UPDATED: ClickOnce MSBuild Resigning Task and More#

This is an update to my previous post.  While going through the code I found that there was a hard coded string in CopyClient and GetClientVersion for the application name so I pulled it out to a parameter.

File Attachment: ClickOnceTasks.zip (11 KB)

Leveraging the code that MS Patterns and Practices released for ClickOnce I made a MSBuild task to resign a ClickOnce deployment.

Scenario:  Moving a ClickOnce deployment from a QA environment to a Production Staged then again to Production.

Tasks included:

  • SaveAndSignManifest
  • CopyClient
  • GetClientVersion

A ClickOnce deployment must be resigned if files are changed, say the download URL and/or the client configuration file change.  Using this MSBuild task I was able to automate the moving of a ClickOnce deployment to different environments.  This task is very simple but got the job done.  An example of the usage is shown below.

<Project DefaultTargets="UpdateClient" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
 <UsingTask TaskName="ClickOnceTasks.SaveAndSignManifest" AssemblyFile=".\bin\Debug\MsbuildTest\ClickOnceTasks.dll" />
 
 <Target Name="UpdateClient">
  <SaveAndSignManifest FileName="Example.application" CertPath=".\Example_TemporaryKey.pfx" DeploymentProvider="
http://localhost/ExampleClient/Example.application" />
 </Target>
 
</Project>

The files are first copied and changed to the the new download location then the above tasks is run to resign the ClickOnce deployment. 

Monday, January 22, 2007 1:17:32 AM (GMT Standard Time, UTC+00:00) #    Comments [0]  | 

 

Toyota Tacoma vs Nissan Frontier#

Lately I have been researching new trucks.  I do not tow or haul much but the bed of the truck is especially useful for carrying bikes around so the mid-size trucks seem appealing.  I’m a lazy person, when going out for a nice long mountain bike ride putting a bike on top of the truck/car/suv or on a rear mounted bike carrier is just a little bit too much.  Being able to toss a bike in the bed (on mounts or not) is a big plus for me.  I’m specifically looking for a crew cab long bed mid size truck.

Looking at the mid-size truck options there are really only two out, the Toyota Tacoma and Nissan Frontier.  Yeah there are more options but you would be off your rocker to look at anything other than Toyota or Nissan in this class.  I have always been a fan of Toyota (I had a 2001 Tacoma) so naturally I gravitated towards the new Tacoma.  I started off reading many reviews on both the Nissan Frontier and Toyota Tacoma.  They are head to head in the reviews but from reading the specifications I feel you get a lot more for your money from Nissan. 

Both the Tacoma and Frontier use a timing chain which is great (if you ever have replaced a timing belt you would understand why).  The Frontier has four wheel disk brakes while the Tacoma has drums in the rear.  The Tacoma says it has 9.5” of clearance while the Frontier is said to have 10.1”.  After looking at both I find this hard to believe that the Frontier has more ground clearance than the Tacoma but that is what the web site says.  The Nissan is very easy to get into and feels lower to the ground.  I like a nice interior, which is what really got me looking at the Frontier.  Nissan offers a nice leather interior with a lot of extras which is not even an option on the Toyota Tacoma.  The price with the leather and the extras on the Frontier is almost the same as a top end Tacoma.  The Frontier does not feel like a hot rod behind the wheel but rather feels like truck (yeah sounds stupid).  I say the Frontier feels like a truck because the engine has that low torquey V8 feel even though it is a V6, but still has more than enough passing power when the pedal is put to the floor.  I currently own a 2006 4Runner (same engine as the Tacoma) and it feels much faster off the line than the Frontier.    The bottom line for me was what do I get for my money; the items I get on the Frontier over the Tacoma are: running boards, power seats, heated mirrors, leather interior, heated front seats, heated rear window, roof rack and sun roof.

If you haven’t yet picked up on it I chose the 2007 Nissan Frontier LE Long Bed.

Wednesday, January 10, 2007 2:14:01 AM (GMT Standard Time, UTC+00:00) #    Comments [0]  | 

 

ExtendedCAB Workspaces and Services#

File Attachment: ExtendedCAB.zip (22 KB)

In a couple of my previous posts I had put up modified code for workspaces to add a “SmartPartClosed” event and I also posted about a ControlDisposedService.  I have put all this code into its own assembly and it is available for download above.

Some things to note is the ExtendedWindowWorkspace contains most of, but slightly modified source from the CAB distribution.  This is because there was some bugs that I fixed and some things I added that were not possible to add if I derived from the WindowWorkspace.  There was an issue with setting the location of a window and I also added StartPosition.  The workspaces have very little modification, the main addition was the SmartPartClosed event which was needed for notification when a SmartPart was closed.

The control disposed service does just what is sounds like.  When a control is disposed it is removed from the WorkItem by the ControlDisposedService.  For the ControlDisposedService to work the ControlDisposedStrategy must be hooked up in the Application class like so.

  protected override void AddServices()
  {
        this.RootWorkItem.Services.AddNew<ControlDisposedService, IControlDisposedService>();

        base.AddServices();
  }

   protected override void AddBuilderStrategies(Builder builder)
   {
        builder.Strategies.Add(new ControlDisposedStrategy(), BuilderStage.Initialization);

        base.AddBuilderStrategies(builder);
   }

I’m slowing pulling out the lessons learned from the implementation of a CAB smartclient that was developed over this past year.  This is the first pass and as time goes on there will be more additions.

Wednesday, January 10, 2007 12:49:33 AM (GMT Standard Time, UTC+00:00) #    Comments [0]  | 

 

Powershell: Unit Testing a PSCmdLet with NUnit#

Daniel posted how to unit test a CmdLet by calling invoke().GetEnumerator() then moving next.  And Scott posted about testing powershell scripts with NUnit.  And this article on msdn2 talks how to make a console app to run a command.

This example will be following very close to the msdn2 article to build PSCmdLet tests in NUnit.  The PSCmdLet “Remove-Brain” is very simple, when invoked it does a WriteObject(true).  The below fixture is just a sample of what can be done for unit testing with commandlets.

    8     [TestFixture]

    9     public class SampleTest

   10     {

   11         private static RunspaceConfiguration config;

   12         private static Runspace runspace;

   13         private static Pipeline pipe;

   14         private static Command command;

 

  • The FixtureSetup creates a RunspaceConfiguration which loads the snapin
  • The FixtureSetup creates a runspace and opens it

 

   16         [TestFixtureSetUp]

   17         public void FixtureSetup()

   18         {

   19             config = RunspaceConfiguration.Create();

   20             PSSnapInException warning;

   21             config.AddPSSnapIn("LuifITPSSnapin", out warning);

   22 

   23             runspace = RunspaceFactory.CreateRunspace(config);

   24             runspace.Open();

   25         }

 

  • The FixtureTearDown closes the runspace

 

   27         [TestFixtureTearDown]

   28         public void FixtureTearDown()

   29         {

   30             runspace.Close();

   31         }

 

  • The Setup creates a new pipeline and adds the “Romove-Brain” command

  

   33         [SetUp]

   34         public void Setup()

   35         {

   36             pipe = runspace.CreatePipeline();

   37             command = new Command("Remove-Brain");

   38             pipe.Commands.Add(command);

   39         }

 

  • The test adds the parameter to the command
  • The pipeline is invoked which runs the command
  • The returned collection of PSObjects contains the objects that where written. 
  • Asserting that there is only one and that my brain has been removed

   41         [Test]

   42         public void CanRemoveMyBrain()

   43         {

   44             command.Parameters.Add(new CommandParameter("Person", "ME"));

   45 

   46             Collection<PSObject> psObject = pipe.Invoke();

   47 

   48             Assert.AreEqual(1, psObject.Count);

   49             Assert.IsTrue((bool) psObject[0].BaseObject);

   50         }

   51     }

Friday, January 05, 2007 1:26:54 AM (GMT Standard Time, UTC+00:00) #    Comments [0]  | 

 

Building a Managed MMC Snapin#

I just cam across this post by Bart De Smet about building a managed MMC Snapin.  Very useful and I look forward to making use of it. 

Friday, January 05, 2007 12:34:38 AM (GMT Standard Time, UTC+00:00) #    Comments [0]  | 

 

Why are there so many stupid drivers!#

All day I have been a magnet for bad drivers.  I try to hurry past them but they do something stupid before I can get by.  You know the drivers I’m talking about, they usually have the gas tank door open and a bunch of bad bumper stickers saying something about dogs or cats.  Maybe there should be one more bumper sticker, something like “It has been 30 seconds since I have done something stupid”.  One more tip off is if the drivers sun glasses are larger than their head, usually means they have a pair of binocular glasses hiding underneath there.

Usually I let things bounce off me but for some reason today seemed much worse.

Thursday, January 04, 2007 10:38:10 PM (GMT Standard Time, UTC+00:00) #    Comments [0]  | 

 

It's the little things that are taken for granted#

As a consultant I find I tend to take the little things for granted.  I happen to know if a small company that is filled with very smart people having backgrounds from many different places.  The challenge they faced was how to manage defects.  The discussion revolved around having both Severity and Priority and it resulting in to many possible combinations.

I always recommend using both Severity and Priority no matter what the size of the organization is.  This is contrary to some other beliefs out there on having both Severity and Priority but the overhead of having both is minimal and return is high.  They provide two completely different pieces of information that are usually supplied by different people.

Severity is how bad is the problem.  This is usually (and should be) supplied by the person who found the bug.  Very rarely is severity changed from the original value set by the person who logged the bug.

Priority gives a level of importance which results in time frame of completion.  Priority is usually assigned at a bug triage meeting and is decided upon by more than one person.

By using both Severity and Priority you can get a good idea of what has to be completed and when.  Depending on when certain pieces of code go live you may have a low severity bug as a very high priority because even though simple needs to be completed before the code is released.  Severity is definitely not a good indication of when bugs should be done.

Thursday, January 04, 2007 10:09:45 PM (GMT Standard Time, UTC+00:00) #    Comments [0]  | 

 

All content © 2008, John Luif
On this page
This site
Calendar
<November 2008>
SunMonTueWedThuFriSat
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456
Archives
Sitemap
Blogroll OPML
Disclaimer

Powered by: newtelligence dasBlog 2.1.8102.813

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

Send mail to the author(s) E-mail

Theme design by Jelle Druyts