Mike Bouck's RAM

Taking the ClickPain out of ClickOnce

Mike Bouck — Sat, 01 Apr 2006 08:11:29 GMT

The ClickOnce support in Visual Studio 2005 is nice and easy but falls-down in number of areas:

The application manifest (i.e. the "stuff" that comprises your app) is determined by walking the project references of your Windows app. What this means is that if you have deployment artifacts that are non-reference content or late-bound loaded assemblies then the default ClickOnce mechanism in Visual Studio will not pick them up.
Oftentimes the versioning scheme for your assemblies is driven by your build process and ideally you'd want the ClickOnce version number to be in-sync with your assembly version. The Visual Studio ClickOnce mechanism has a very limited versioning scheme that is completely decoupled from assembly versioning and is inaccessible outside of the IDE.
For enterpirse scenarios, it is very common to have a segmented network dedicated for specific functions (e.g. development, test, production). In this scenario the Windows app has to be designed such that certain information (e.g. connection strings, web service urls, etc.) are pushed-into environment-specific configuration files. The deploy process then involves indicating what environment the built bits should be pushed into and then the appropriate configuration files are pulled-in by the deploy process. In this way the same set of bits may be "promoted" from dev to test and finally to production. The default Visual Studio ClickOnce mechanism has no notion of nor capability of dealing with environment-specific information.

For the uninitiated there are four ways to create a ClickOnce deploy package:

Via the Window app's Publish property page in Visual Studio (easiest but essentially unuseable for apps of even moderate complexity for the reasons listed above).
Via mage.exe (command-line utility).
Via mageui.exe (Windows app).
Via MSBuild (using the GenerateApplicationManifest, GenerateDeploymentManifest, GenerateBootstrapper and SignFile tasks).

Note that despite the chosen method, everything eventually calls the MSBuild tasks. So, for the cleanest solution you should just cut straight to the chase and call the MSBuild tasks, right? Ah, but here's the rub -- you have to determine what your application manifest is and feed this list to the GenerateApplicationManifest task via an ItemGroup. You really don't want to have this fixed list that you have to maintain but rather have the application manifest dynamically generated for you. This is the real value of mage.exe which you can point to a directory and it will build-up the app manifest for you. Where mage is less than useful is generating the deployment manifest but you can just use the MSBuild task to do this instead.

This sample demonstrates how to use mage.exe in conjunction with the ClickOnce MSBuild tasks to resolve the deficiencies with the Visual Studio approach. The sample consists of a simple Windows app which displays a value stored externally in the application's App.config file. Note that in this sample there are three versions of this file (stored under the Config directory) -- a "development" version, a "qa" (i.e. test) version, and a "production" version. They are structurally identical, the only varying bits are the values. There is also a satellite class library that is late-bound instantiated and invoked when a button is pressed on the app. There is no reference to this assembly from the Windows app.

In my shop we run the deploy scripts seperately from the build scripts but you could easily tack this on to the end of your build process if so desired. Have fun!

Download Sample

Programatically Registering SoapExtensions Redux

Mike Bouck — Sun, 31 Jul 2005 20:10:42 GMT

I’m using a number of SoapExtensions in my current project and had a need to register them dynamically on the client side; Christian Weyer blogged about a solution using reflection which injects the extension into the in-memory config. This works great for .NET 1.x, but I’m all over .NET 2.0 code these days! Unfortunately, dynamically registering SoapExtensions gets no easier in 2.0, but fortunately hacking the in-memory config does:

/// <summary>
/// Programatically registers a <see cref="SoapExtension"/> at runtime with the specified
/// <see cref="SoapExtensionTypeElement.Priority"/> and <see cref="SoapExtensionTypeElement.Group"/> settings.
/// </summary>
/// <param name="type">The <see cref="Type"/> of the <see cref="SoapExtension"/> to register.</param>
/// <param name="priority">
/// A value that indicates the relative order in which this SOAP extension runs when multiple SOAP extensions are
/// specified. Within each group the priority attribute distinguishes the overall relative priority of the SOAP
/// extension. A lower priority number indicates a higher priority for the SOAP extension. The lowest possible
/// value for the priority attribute is 1.
/// </param>
/// <param name="group">
/// The relative priority group (e.g. Low or High) in which this SOAP extension runs when multiple SOAP extensions
/// are configured to run.
/// </param>
[ReflectionPermission(SecurityAction.Demand, Unrestricted = true)]
public static void RegisterSoapExtension(Type type, int priority, PriorityGroup group)
{
   if (!type.IsSubclassOf(typeof(SoapExtension)))
   {
      throw new ArgumentException("Type must be derived from SoapException.", "type");
   }

   if (priority < 1)
   {
      throw new ArgumentOutOfRangeException("priority", priority, "Priority must be greater or equal to 1.");
   }

   // get the current web services settings...
   WebServicesSection wss = WebServicesSection.Current;

   // set SoapExtensionTypes collection to read/write...
   FieldInfo readOnlyField = typeof(System.Configuration.ConfigurationElementCollection).GetField("bReadOnly", BindingFlags.NonPublic | BindingFlags.Instance);
   readOnlyField.SetValue(wss.SoapExtensionTypes, false);

   // inject SoapExtension...
   wss.SoapExtensionTypes.Add(new SoapExtensionTypeElement(type, priority, group));

   // set SoapExtensionTypes collection back to readonly and clear modified flags...
   MethodInfo resetModifiedMethod = typeof(System.Configuration.ConfigurationElement).GetMethod("ResetModified", BindingFlags.NonPublic | BindingFlags.Instance);
   resetModifiedMethod.Invoke(wss.SoapExtensionTypes, null);
   MethodInfo setReadOnlyMethod = typeof(System.Configuration.ConfigurationElement).GetMethod("SetReadOnly", BindingFlags.NonPublic | BindingFlags.Instance);
   setReadOnlyMethod.Invoke(wss.SoapExtensionTypes, null);
}

WeakReference Cache

Mike Bouck — Mon, 02 May 2005 16:12:59 GMT

There is a fundamental problem with System.Web.Caching.Cache -- what if your application is not a web application and you need some general-purpose cache functionality (e.g. middle-tier logic)? Since there is no equivilent "System.Caching.Cache" class I decided to write one using weak references that has no dependency on System.Web.dll.

Download Source (4.76 KB)

GDN Queued Component Utilities

Mike Bouck — Mon, 02 May 2005 16:06:51 GMT

Contains several useful classes that fill-in some holes with the current BCL Queued Components (QC) implementation. Functionality includes automatic queue moniker construction, QC session management (both synchronous and asynchronous), a QC exception handler base class, a QC custom config section handler, a managed wrapper class for the COM+ Message Mover object, and an object wrapper to marshal .NET serializable types in queued interface calls. Full source code, documentation and samples are provided.

Download Source (139.75 KB)

XML Visualizer for Visual Studio .NET 2003 (XMLVIZ)

Mike Bouck — Mon, 02 May 2005 04:56:15 GMT

I was intrigued, as many were, with Mohammed Barqawi's DataSet QwickWatch add-in over on The Code Project. The thought of leveraging the expression evaluator to populate a form for visualization purposes during a debugging session was compelling and, over the holidays, I decided to see how far I could take the idea. As it turns-out, it is actually quite amazing how much you can do with strings and an AppDomain.CurrentDomain.Load() call! Once I had this nut cracked, everything else fell-together pretty quickly and after a few weeks of furious coding and a small round of beta testing, I decided to release the XML Visualizer for Visual Studio .NET 2003 (XMLVIZ) to a (much!) larger audience.

WHAT DOES XMLVIZ DO?

Basically, XMLVIZ allows you to visualize most XML and XML-backed data sources during runtime a la Whidbey's "debugger visualizers". The difference is you don't have to wait for VS.NET 2005 because XMLVIZ will work with your copy of VS.NET 2003 today! XMLVIZ is implemented as a VS.NET add-in and, once installed, is activated by highlighting any supported, initialized type instance during a debugging session, right-clicking on the selection to bring-up the context menu, and selecting the "XML Visualizer" menu item. The add-in will then grab the XML out of the selected target instance and display it on a modal dialog along with the schema (if available). For ADO.NET types, the data is also bound to a grid to allow navigation, row-filtering, and row version inspection.

WHAT TYPES CAN I VISUALIZE?

Currenly XMLVIZ supports the following types (including derived types thereof):

DataSet,

DataTable (including detached tables),

DataRow/DataRow[]/DataRowCollection (attached rows only),

DataView (including DataViews over detached tables),

DataRowView/DataRowView[] (attached rows only),

DataViewManager,

Exception,

XPathNavigator,

types implementing IXPathNavigable,

well-formed XML in strings,

any XML-serializable type

Download Source

Download Setup