Tuesday, July 03, 2007

I've been working with the Visual Studio deployment projects for years now, but always in a very simplistic manner.  That is, I've used them to deploy my applications, install my services, etc, but I've never needed to get into custom development.

Sure, I've long leveraged .NET's ability to have Installer classes to execute custom code when the application in installed to perform tasks such as Event Log creation and/or registration.  This is quite easy, in fact.

Without diving too deeply into it right now, a simple form comes down to the following tasks:

  1. Create a public class that derives from System.Configuration.Install.Installer.
  2. Add the [RunInstaller(true)] attribute to the class.
  3. Add the appropriate code to your Install, Rollback, and Commit method overrides.
  4. Add your application's output to your setup project's Install and Uninstall Custom Actions.

That's it - the installer takes care of everything.

However, my needs with a recent pet project involved passing data to my installer class from the setup project.  This is easily accomplished by following these steps:

  1. Add a dialog to your installer (e.g. there's one called "Textboxes (A)" that will work fine).
  2. Each of these basic dialogs (A, B, and C) contains 4 edit fields.  In order to pass the values from the edit fields to your installer you must name them.  You can use the defaults, but EDITA1, EDITA2, etc don't tend to make much sense.  You name them by changing the EditxProperty property on the dialog.  This is now the variable name you can reference in your code.
  3. Pass the value to your installer by selecting the 'Primary output from XXX (Active)' node in the appropriate Custom Action and setting the CustomActionData property.  This string is defined as a space delimited parameter list.

    For instance, if you named a property 'ROOTFOLDER', you could define the parameter as follows:
    /rootFolder=[ROOTFOLDER]

    If you want to pass more than one parameter, you space delimit them:
    /rootFolder=[ROOTFOLDER] /userName=[USERNAME]

    Of course, if there's a space (or the potential for a space) in the value, you'll need to enclose the property in quotes:
    /rootFolder="[ROOTFOLDER]"
  4. You can then reference the parameters by name in your installer code:
    public override void Install(IDictionary stateSaver) {
       base.Install(stateSaver);
       try {
          string rootFolder = this.Context.Parameters["rootFolder"];
          // do something, such as create the folder, write a configuration file, etc
       }
       catch ( Exception ) {
          // do some logging here
       }
    }

All in all it's pretty straightforward and easy to do.

Happy coding!

Tuesday, July 03, 2007 4:28:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [3]  |  Trackback
 Saturday, June 30, 2007

Well, I must say that I'm happy about our very first .NET User Group Lunch which took place a couple of days ago (06/28/2007).  We had about 15 people show up to Ruby Tuesday in Jordan Landing and we had a great time.  I really enjoy the commaradie of the group.  We're going to shoot for another lunch in a few weeks and we're looking for suggestions for locations (both to maximize accessibility and therefore attendance to these events).

If you have thoughts, please follow up on the User Group forums.

Saturday, June 30, 2007 4:19:00 PM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Monday, June 25, 2007

This week we're starting what we hope will be a long and fun tradition for the Utah .NET User Group: A .NET User Group Luncheon.

Here are the details as outlined on the website:

By popular demand, we're starting up what we hope will be the first of many .NET User Group lunches.  This is a time where the members of the group can gather, collaborate collectively, frolic and fraternize, and consume comestibles.  We've had a great time gathering after the monthly meetings each month and would like to continue that tradition during the daylight hours when (hopefully) more people can make it..

As a tentative schedule, we're thinking of having a lunch gathering every two weeks at different points throughout the valley.  That way, if you can't make one lunch, hopefully you can make the next one.

This first one will be in Jordan Landing at Ruby Tuesday.  To accomodate everyone's disparate work hours and various commutes, we're allotting 1.5 hrs for lunch from 11:30 AM - 1:00 PM.  You don't need to come for the entire time, show up whenever you like.  Again, things may and probably will change as we get this underway (such as times, dates, and locations), but we just want to get the ball rolling.

We love this group and hope to have a good turnout to this, the inaugural lunch.

If you plan on attending, please check the appropriate option below so we can arrive in time enough to warn them :)

Come one and all, good times are to be had!

Date: Thursday, June 28th, 2007
Time: 11:30 AM - 1:00 PM
Place: Ruby Tuesday in Jordan Landing (
http://www.rubytuesday.com/locator.asp?template=map_search&pWidth=339&pHeight=299&transaction=locMap&recordId=7132)

If you'd like to attend, please visit the post and sign up on the poll, indicating you'll be there.

It should be a lot of fun!

Monday, June 25, 2007 2:47:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  |  Trackback
 Wednesday, June 20, 2007

Tonight I had the distinct pleasure of giving a presentation at the Utah County .NET User Group on the topic of Silverlight - specifically Silverlight 1.1 Alpha.  It was a blast!  Honestly, I was a little nervous going into it, having never really presented on the topic and being relatively new to it myself, but I had a great time.  We talked about Silverlight (previously known as WPF/E) and used Visual Studio “Orcas” with Expression Blend and did some really cool things.  We talked about XAML, created custom controls, retrieved a file from the server and read its contents, automated the HTML DOM from the Silverlight .NET code, did the reverse (called .NET methods from JavaScript), and much more!

If you missed it, never you fear because I'll be addressing the topic at the September 2007 Utah .NET User Group meeting.

Thanks all for coming and to Scott Golightly for giving me this opportunity to present.

Wednesday, June 20, 2007 3:39:00 PM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [4]  |  Trackback
 Wednesday, June 13, 2007

Well, the time has once again arrived, my friends, for our monthly Utah .NET User Group meeting.

We will be pleased to have Craig Campbell stepping up to the plate to discuss Team Foundation Server (TFS).  We know that this has been a topic long desired and we're excited to be able to bring it to you.

Topics of discussion will include (but are not limited to):

  • What is TFS (in relation to SCM)?
  • Source Control
    • Comparisons
    • Features
    • Branching/Merging/Shelving
    • Visual Studio Integration/Other integration/Command line
  • Build
    • Team Build
    • Continuous Integration
    • Orcas changes (v2 of TFS)
  • Project Features
    • Work items
    • Methodologies offered
    • Source control integration
  • Customizations/Extensibility

So bring your friends, family, fellows, and fraternities...you won't want to miss this event.  And though there is no need to mention this, I will:  don't forget it's FREE and open to all.

Date: Thursday, June 14th, 2007
Time: 6:00 PM
Place: Digital Draw Network - Suite 300 (10897 South River Front Parkway, South Jordan)

We'll see you there!

Wednesday, June 13, 2007 4:23:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Tuesday, June 12, 2007

Recently I had the need to create a component in .NET that would be callable as a COM component (not unlike many other such objects in the past).  This one, however, was peculiar in that I also needed to be able to call it from a web page running in IE (due to constraints already on the application, cross-browser support is not a concern in this case).  I didn't want the users to be burdened with dialog boxes or even require that they change their security settings.  I wanted to create the object as 'safe for scripting'.

There are two approaches that I know of that address the issue: implementing IObjectSafety (a COM interface) or directly managing the object via the Component Category Manager (ICatRegister COM interface) and registering the CAT_SafeForScripting GUID.

The first presumes that I have access to and can compile the code, because the IObjectSafety interface must be implemented directly on the object in question.  The second solution can be done after the fact (e.g., within an installer).

Due to the nature of the project, I opted for the first option because, frankly, it was the easier of the two to implement given my time constraints.

The IObjectSafety interface is not native to the .NET world.  As such, in order to implement a COM interface on a .NET object the interface must be defined within the managed code and then decorated with the appropriate attributes.

Here's my implementation of the IObjectSafety interface in managed code:

[ComImport()]
[Guid("CB5BDC81-93C1-11CF-8F20-00805F2CD064")]
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
interface IObjectSafety {
   [PreserveSig()]
   int GetInterfaceSafetyOptions(ref Guid riid, out int pdwSupportedOptions, out int pdwEnabledOptions);
                    
   [PreserveSig()]
   int SetInterfaceSafetyOptions(ref Guid riid, int dwOptionSetMask, int dwEnabledOptions);
}

The ComImportAttribute identifies that the interface was previously defined in COM with the IID specified by the GuidAttribute.  The PreserveSigAttribute is important on each of the methods to tell the .NET runtime to not suppress the HRESULT when the method is called.

Once defined, it's then a simple matter to implement the interface on my class, and indicate that it's safe for scripting:

[ClassInterface(ClassInterfaceType.AutoDispatch)]
[Guid("43B6ADAA-6DE7-43c2-9206-3389C94B9531")]
[ProgId("DemoLib.DemoObject")]
public sealed class DemoObject : IObjectSafety {
   private const int INTERFACESAFE_FOR_UNTRUSTED_CALLER = 0x00000001;
   private const int INTERFACESAFE_FOR_UNTRUSTED_DATA = 0x00000002;
   private const int S_OK = 0;

   public int GetInterfaceSafetyOptions(ref Guid riid, out int pdwSupportedOptions, out int pdwEnabledOptions) {
      pdwSupportedOptions = INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA;
      pdwEnabledOptions = INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA;
      return S_OK;
   }

   public int SetInterfaceSafetyOptions(ref Guid riid, int dwOptionSetMask, int dwEnabledOptions) {
      return S_OK;
   }
}

Once registered (via Regasm.exe), you can invoke methods on an instance of the object via your script:

var obj = new ActiveXObject("DemoLib.DemoObject");
obj.CallSomeMethod();

Tuesday, June 12, 2007 11:06:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  |  Trackback
 Thursday, June 07, 2007

I hate little hacks like this, but here it is nonetheless.  If someone has a better solution I would love to hear it.

I've been tinkering with the WinForms TreeView control a bit and ran into a documented (but undesirable) behavior.  I'm wanting to display my hierarchical node structure in the tree, but I want to 'highlight' some of them for one reason or another.  My preferred highlight in this case is to use a bolding effect on the font and to change the text color.

The undesired effect, however, is when you apply a font to the node that is larger than the base font of the node the text will clip.  Well, bolded text is larger - it's wider than the text and as a result the right-most character(s) get clipped and it looks really tacky.

My hack isn't without it's limitations and considerations, but all I need to do to 'workaround' this issue is to apply some non-breaking spaces in the text to display such that they get clipped and not the actual text.  This is definitely error-prone as well because just one nbsp doesn't necessarily address the issue (but does in my situation for most texts).

string text = “This is ridiculous” + (char)160;
TreeNode node = new TreeNode(text);

I can see this being quite an issue with non-latin-based fonts, though I've nothing to substantiate that claim.

One side-effect of doing this is that the 'clip box' around the text grows to accommodate the non-breaking spaces.  You can surely set your TreeView to use .FullRowSelect, and to turn off .ShowLines, but that may not be desirable in some situations.

Does anyone have/know of a better solution with the plain, vanilla TreeView?  I've tried other tactics but none led to any better results.  Maybe I'm missing something blatently obvious.

Thursday, June 07, 2007 7:29:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [2]  |  Trackback
 Wednesday, May 30, 2007

Just the other day I posted some code wherein an MSMQ queue is created and the Network Service account was granted full control to the queue.  Though I didn't mention it, this was necessary because the Windows Service runs under that account and would need access to the queue.

As it turns out the code sample has issues when running on Windows XP.  Windows XP doesn't allow the NT AUTHORITY\NETWORK SERVICE account to be associated with the permissions on a message queue (I've not looked into why yet).  When the code runs no error is thrown and it happily attempts to grant the permissions.  This results in a queue whose permissions are corrupted (not even an administrator can access it) and all users are denied access.  The only way I've found to remove such a queue is to uninstall MSMQ and reinstall it.  Does anyone know of another solution to that?

Therefore, in my code a put a rudimentary workaround to the problem.  I perform a simple check to see if the OS is Windows XP and if so, not set permissions.  This works in this case (though I hate to rely on these behaviours) because the default permissions on a queue in XP is Everyone:Full Control, so the service can see the queue just fine.

if ( !isWindowsXP() ) {
   const string accountName = @"NT AUTHORITY\NETWORK SERVICE";
   Trustee trustee = new Trustee(accountName, null, TrusteeType.User);
   MessageQueueAccessRights rights = MessageQueueAccessRights.FullControl;
   MessageQueueAccessControlEntry ace = new MessageQueueAccessControlEntry(trustee, rights);
   queue.SetPermissions(ace);
}

...

private static bool isWindowsXP() {
   OperatingSystem os = Environment.OSVersion;
   return ( PlatformID.Win32NT == os.Platform && 5 == os.Version.Major && 0 != os.Version.Minor );
}

Again, very simple and potentially error prone (what about Windows 2000 Pro?), but in my case it suffices. 

Wednesday, May 30, 2007 6:33:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  |  Trackback