The question came up from several attendees at my MSDN Webcast on ClickOnce yesterday:

"Can I launch a XXX application using ClickOnce?" (fill in XXX with VB6, MFC, etc. - non-.NET applications)

The answer is yes, you will just have to employ a little trick.

What you need is a simple little launcher application that IS a Windows .NET application. So do the following:

1. Create a new Windows Application project with VS 2005.
2. Delete the Form1 from the project.
3. Add the unmanaged EXE and any supporting files to the VS 2005 project, which makes them part of this application from a ClickOnce perspective. As a result, they will get deployed with this application to its cache folder and can be executed by this launcher app.
4. Edit the Program.cs file Main method and delete the current method body (which launches the application and the form) and replace it with code to launch the unmanaged executable. This just requires a single line of code: Process.Start("MyUnamangedApp.exe");

Note: You will need to give the launcher app full trust in the ClickOnce security settings.

Note2: If the unmanaged app relies on ActiveX or COM objects, those need to be added to the project as well, and you will need to add a reference to the COM DLL's to the project to get their reg-free COM information added to the manifest. See this article for more details.

You can download a sample implementation here.

For those who attended or are interested, here are the demos from my MSDN Webcast on ClickOnce yesterday.

You can find the webcast link for on-demand viewing here.

For the demo that went awry demonstrating on-demand updates, the little mistake I made was that I said that if you turn off automatic updates (Check for updates option at top of Updates dialog), then you need to put in an Update location, which is true. But what I was doing was fully qualifying the path to the deployment manifest, which is incorrect. What you need to put is just the URL to the root folder where the deployment manifest resides. VS will automatically append the deployment manifest file name. So when I was putting in:

http://localhost/ClickOnceOnDemand/ClickOnceOnDemand.application

I should have just been putting

http://localhost/ClickOnceOnDemand/

Another little tidbit I didn't mention is that you will need Full Trust for on-demand updates, which is unfortunate because it means the app has to request full trust even though it may not be doing anything privileged beyond on-demand updates.

In previous builds of WCF (Indigo), you had to have a particular namespace included in your config file. Specifically, instead of the default root element of:

<configuration>
<!-- The rest of your config settings -->
</configuration>

You needed to have:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<!-- The rest of your config settings -->
</configuration>

By doing that in previous builds, you got intellisense for the schema elements and attributes of the <system.serviceModel> element, letting you discover the right entries to get features like transactions, security, bindings and so on correctly configured.

When I installed the Nov CTP, I was immediately lost because my intellisense seemed to have gone away. If you add a WinFx Service from the Web Site templates, the web.config still has the namespace shown in the second config snippet above. But the trick is that it is no longer needed, and in fact confuses VS on what schema elements to expose through intellisense. The system.serviceModel schema elements are now merged with the C:\Program Files\Microsoft Visual Studio 8\Xml\Schemas\DotNetConfig.xsd schema as part of the VS extenstions install, so they are there by default now in the config file intellisense.

Thanks to my colleague Juval Lowy for discovering this fact and giving me back my intellicrack!

Here are the demos from my MSDN Webcast today on the DataGridView control.

You can find the sample DataGridView chapter for my book here.

You can view the webcast on demand through the links here.

My friend Clyde Barretto has started blogging. He has been giving some great talks to the local area user groups on developing custom Windows Forms controls. Hopefully we will see some good technical content there sharing his knowledge. Welcome to the blogsphere, Clyde!

I gave a talk on connecting smart clients with WCF on Tuesday at Boulder .NET. Had a good turnout desipte the proximity to the holiday and had a good time.

The talk covered the fundamentals of connecting applications with WCF since most of the people there had never seen anything on WCF. Then I moved into some of the specific client concerns when using WCF, similar to my talk at VSConnections.

You can get the slides and demos here:  Slides   Demos

When I demonstrate the use of interface-based programming in a class, I always give a demo of using interface-based programming combined with a factory pattern to add dynamic behaviors to an application. This is basically a scaled down version of what the provider model in ASP.NET 2.0 and the Enterprise Library do to allow you to externally configure components that will be called by the framework at runtime. ASP.NET actually uses abstract base classes instead of interfaces because they also provide some shared implementation, but the concepts are basically the same.

 

I use a simple little example of a client that defines an IDog interface (in a separate interface only assembly that it can share with component providers) that specifies the contract that providers are expected to implement. I then show how to build components separately that the client has no specific type information about, and load and invoke the behavior defined in those components dynamically through a factory and based on the interface definition that is the contract for how those components expose their behavior and some configuration file entries that the factory can use to load and instantiate the types. The client is able to do this without requiring any code modifications to accept new components, and can even have new behaviors added at runtime without needing to restart the application.

 

I have repacked the demo I normally give in class to:

Make it a little cleaner

Separate out the factory into a generic factory in a separate assembly that could be reused for any project

Use the new Settings features in the .NET 2.0 framework to enter the type information into a configuration file instead of using a separate XML file like I used to.

 

The factory method looks like the following:

 

public static T[] ConstructType<T>() where T : class

{

   // Refresh the config cache in case the config file has been edited at runtime

   Settings.Default.Reload();

   // Load the collection of components from the string collection in config

   StringCollection componentTypeInfoColl = Settings.Default.Components;

   // Create a list to add the components to as they are created

   List<T> components = new List<T>();

   // Loop through the config strings trying to create instances of the appropriate type

   foreach (string componentTypeInfo in componentTypeInfoColl)

   {

      try

      {

         // Config entries should be in the form:

         // Fully.Qualified.TypeName, AssemblyName

         // Split into its two parts

         string[] typeInfo = componentTypeInfo.Split(',');

         // Dynamic load the assembly

         Assembly assem = Assembly.Load(typeInfo[1].Trim());

         // Dynamic instance creation

         T instance = assem.CreateInstance(typeInfo[0].Trim()) as T;

         if (instance != null)

         {

            components.Add(instance);

         }

      }

      catch { } // Just ignore invalid types

   }

   return components.ToArray();

}

 

So the only things you need to know to use this as a factory for other purposes than this demo is that it expects the type information to be entered in the client configuration file with an application settings section like the following:

 

<configuration>

    <configSections>

        <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >

            <section name="DynamicFactoryLibrary.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />

        </sectionGroup>

    </configSections>

    <applicationSettings>

        <DynamicFactoryLibrary.Properties.Settings>

            <setting name="Components" serializeAs="Xml">

                <value>

                    <ArrayOfString xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

                        xmlns:xsd="http://www.w3.org/2001/XMLSchema">

                        <string>Animals.Dog, Animals</string>

                      <!--

                        <string>Animals.GermanShepherd, Animals</string>

                        <string>Animals2.Shitzu, Animals2</string>

                        -->

                    </ArrayOfString>

                </value>

            </setting>

        </DynamicFactoryLibrary.Properties.Settings>

    </applicationSettings>

</configuration>

 

I’m just using a StringCollection as the type for the component type collection, so each component that you want to add to the collection should be added to the section in the form:

 

<string>Animals.Dog, Animals</string>

 

You can see a couple of additional components commented out for dynamically adding them into the application (even while it is running). The type information uses a standard convention for specifying type information through a config file: specifically the fully qualified type name of the type, followed by a comma, followed by an Assembly name to load it from.

 

You can grab the whole sample here.

 

To demonstrate the example in action:

• First build the InterfaceBasedProgramming solution, which builds the interface contract assembly, the factory library, and the client application. The default client config file has all of the type information for available components commented out.
• Open the build output folder of the client (InterfaceBasedClient\bin\debug) and run the client by double clicking on InterfaceBasedClient.exe.
• Push the button and observe that you get nothing because no types have been provided or plugged in though the config file yet. Leave the client running.
• Next open the Animals solution, build it, and copy the build output (Animals.dll) from the bin\Debug folder into the client’s bin\Debug folder.
• Edit the InterfaceBasedClient.exe.config file through an editor, and uncomment the Dog type information as shown in the snippet of config file above, save the file.
• Hit the button in the client again, you should see a standard Dog Bark (through a message box).
• Edit the config file again, uncommenting the type information for a GermanShepherd (which is also defined in the Animals assembly), and save.
• Push the button again and you will see that type is dynamically used from the already loaded assembly.
• Go open the Animals2 solution and build it.
• Copy the Animals2.dll from its bin\Debug folder into the bin\Debug folder for the client.
• Edit the config file for the client again to uncomment the type information for the Shitzu type, and save.
• Click the button in the client again and you should see all three types of dogs bark. 

For the students from my recent class in Sweden, you can download all the demos I did dynamically (as opposed to the ones you already have in your demos folder and available on our site at www.idesign.net) from the following link:

http://www.softinsight.com/downloads/Linsoft05ClassDemos.zip

 

I finished teaching a .NET Systems Programming class (aka Advanced .NET Master Class) this week in Linköping Sweden. This was my first time to Sweden, and I was very impressed. It is a very beautiful country and the people are very welcoming and friendly. The class went well, and then yesterday I had the chance to spend the day touring Stockholm. The first thing I discovered is that one day is not nearly enough! There are so many things to see there. I spent some time wandering around the Gamla Stan (old city) section, shopping and having some lunch. I visited a couple of churches and the palace that date back to the 13th century. Then I headed over to the Vasamuseum, where they have the recovered Vasa - a 1600's man of war that sunk within 1 km of where it was launched because the crown got a little carried away trying to make it the most impressive warship afloat at the time and ended up making it so top heavy it flipped over as soon as the wind caught its sails. There were a bunch of other museums and sites I would have liked to see, but I ran out of light and time and had to catch my train back to Linköping.

I'm supposed to teach another class over here in March, so I will definitely try to work in another Stockholm visit then as well.

If you are ever debating about which European cities you ought to visit on a pleasure trip, make sure you add Stockholm to the top of the list!

Home for one day from Dev Connections, and now I am off on travel for another week to teach an Advanced .NET Master Class in Linkoping, Sweden.  

Currently somewhere over Maine headed Northeast and enjoying wireless connectivity in flight. I had heard some airlines were considering doing this, I guess SAS was the first, and maybe still only one. A little pricey at $29 for an 8 hour flight, but worth it when you have online work you really need to get done and 8 hours to kill. Kind of cool.

I gave two WCF (Indigo) talks at DevConnections today:

Build Event Driven Applications with Indigo:   Slides   Demos

Connecting Smart Client Applications with Indigo:  Slides   Demos

In the Event Driven Applications session I cover creating list based subscription services with direct callback services in the clients, using duplex channels to set up callbacks, and a Pub-Sub implementation that gives loosely coupled events that I will have more information on here in the near future.

In the smart client session, I covered client concerns with respect to channel selection, asynchronous calls, sessions, transactions, callbacks, security, and peer-to-peer.

Good time!

My second session of the day yesterday at DevConnections was on ClickOnce deployments, and specifically the various security protections and options that ClickOnce offers for preventing unauthorized applications from being able to run through a ClickOnce launch.

You can grab the slides and demos here:  Slides   Demos

Some of the key takeaways from this session were the following:

• ClickOnce provides a simple, powerful, and easy to use mechanism for deploying smart client applications with minimal maintenance effort and IT Admin involvement
• ClickOnce provides runtime security protections through the Code Access Security (CAS) infrastructure of .NET to prevent applications launched from ClickOnce from being granted permissions to perform any operations or access any resources that the application was not specifically allowed to do.
• ClickOnce app default permissions are determined by the launch URL and how it maps to built-in CAS location-based code groups (MyComputer, LocalIntranet, Internet, TrustedSites, UntrustedSites).
• If the application manifest requests permissions greater than those that would be granted based on the CAS location-based code groups, permission elevation needs to occur.
• By default, permissions can be elevated in one of two ways: user prompting or trusted publishers.
• If an application is launched through a link to a deployment manifest that is signed by a publisher certificate that is not in the Trusted Publishers certificate store on the client machine, the user will be prompted by default and can accept or reject the application. If they accept it, the permissions for that application will be elevated to whatever permissions the application manifest has requested.
• If an application is launched that was signed with a publisher certificate that is in the client machine's Trusted Publishers certificate store, then no user prompting will occur and the application permissions will be automatically elevated to whatever the application manifest requests because it is coming from a trusted source identified implicitly by IT admin when they installed the publisher certificate in the Trusted Publishers store.

If you want to prevent the user from ever being prompted and only allow applications from trusted publishers to be launched through ClickOnce (a good idea in an enterprise environment), then you should create the registry key discussed in the slides from the session and set the string values to Disabled for all the zones.

I just got finished doing my first talk here at DevConnections in Vegas and I think it went pretty well. Great crowd, good questions, fun topic.

You can grab the slides and demos here: Slides   Demos

The talk highlighted how to define custom objects and collections to make them suitable for data binding, mostly for Windows Forms, but some of it is applicable to ASP.NET as well.

The key takeaways from the talk are:

• Implement INotifyPropertyChanged on any business entitity type you define that you expect to use in data binding scenarios. This interface defines a contract for the objects to raise PropertyChanged events whenever a property is set on the object. It allows containing collections or bound controls to be notified when the contents of the data object change, which helps with keeping controls synchronized in a form.
• Use BindingList<T> to create strongly typed collections of objects that support rich data binding. It provides full implementation of IList, ICollection, IEnumerable and their generic strongly typed counterparts for whatever type parameter you provide, and it provides a partial implementation of the IBindingList interface. The part that it implements is firing ListChanged events when items are added or removed from the collection. It also looks at the objects type that you provide as a type parameter, and if it implements INotifyPropertyChanged, the collection will subscribe to the PropertyChanged event on each object and raise ListChanged events with a change type of PropertyChanged whenever the contents of an object in the collection change. These features make BindingList<T> collections work seamlessly with data binding to multiple controls and keeps the controls all in sync.
• Use my BindingListView<T> class (in the demos and in my book) to get a generic container that supports sorting (both IBindingList based single property sorts and IBindingListView multi-property sorts), searching, and filtering.

If you were there at the end and saw the on-the-fly demo where I didn't see the saving behavior that I thought I had just implemented, I tracked down the problem. the changes were actually being saved. It was just the way I hooked up the data binding I wasn't seeing those changes.

In the demo, I used the data sources window to generate a Details view (control collection) bound to a collection of Album data. I changed one of the controls in the collection which was bound to a GenreID property on the Album objects to a ComboBox. I then used the Data Sources window to add data binidng to a Genre object collection to populate the list of Genres in the combo box. This sets up the ComboBox to have its contents determined by the Genre collection, but its SelectedValue property is bound to the GenreID property on the current item in the Album collection - generally exactly what you want to be able to edit a property on one object collection item through a lookup list of values in another collection of objects. The problem was that after I selected a new value in the combo box and saved the changes, then restarted the app, I wasn't seeing the modified value set for the Album I was viewing in the other controls.

It turns out the problem was just the order that I did the initial binding of the control collection and the combobox BindingSources. In the form load I had added the following two lines of code to bind the control collection and the combo box binding sources:

albumBindingSource.DataSource = Album.GetAlbums();
genreBindingSource.DataSource = Genre.GetGenres();

The problem is that when you set the DataSource, that is when it intializes the bound controls. So I was initializing the data bindings for all of the controls based on the album data, then intializing the combo box of Genres with a new set of data. That set the SelectedIndex of the ComboBox back to zero, so I wasn't seeing the actual value of the Genre for the current Album, I was just seeing the first Genre value in the Genre collection. The fix is simply to do the initial binding in the reverse order:

genreBindingSource.DataSource = Genre.GetGenres();
albumBindingSource.DataSource = Album.GetAlbums();

Then it works as expected.

Some resources I mentioned in the talk, as well as some additional ones I gave related to after-session questions:

My Book: Data Binding in Windows Forms 2.0, Addison Wesley, January 2006
http://www.amazon.com/exec/obidos/ASIN/032126892X/qid%3D1124482085/sr%3D11-1/ref%3Dsr%5F11%5F1/102-3039504-6850510
Rocky Lhotka binding refresh problem post:
http://www.lhotka.net/WeBlog/PermaLink.aspx?guid=d8306469-7e76-4734-9811-777498808b85
Rocky Lhotka article on binding to business objects: Windows Forms Object Data Binding in .NET 2.0, 15seconds.com, http://www.15seconds.com/issue/040614.htm
My recent article on The Server Side .NET: Build a Data Access Layer with the Visual Studio DataSet Designer, The Server Side .NET, Oct 2005, http://www.theserverside.net/articles/showarticle.tss?id=DataSetDesigner
My recent article in CoDe magazine: Tackle Complex Data Binding in Windows Forms 2.0, CoDe Magazine, July/Aug 2005, http://www.code-magazine.com/Article.aspx?quickid=0507051

Enjoy!

Great post by my colleague Michele from IDesign following a discussion we had on ClickOnce permissions and what users are allowed to do. Check it out!

I'm catching a flight early tomorrow morning to Vegas for VS Connections and am really looking forward to it. VS Connections in particular, and DevConnections in general (the overall conference event) is well run, in great locations, and always has a lot of great content that I can benefit from as well.

I've been spending most of my recent prep time fine tuning the demos for my two WCF sessions, Build Event Driven Applications with Indigo and Connecting Smart Client Applications with Indigo. The more I work with Windows Communications Foundation (aka "Indigo"), I am struck by a number of things:

• I am impressed by how capable Indigo is.
• I am awed by how elegant and simple solutions are to complex aspects like security, transactions, queuing, callbacks, and so on.
• I am dumbfounded by how hard it is to figure out how to get to those elegant and simple solutions.

The last bullet is not really a criticism of what they have come up with, it is just the nature of the beast. I would draw on an analogy from my flying days to explain why this is so. Imagine the cockpit of a WW I fighter aircraft. You probably have half a dozen or less simple dials and gauges, and a stick and throttle. Imagine trying to use that set of controls on an aircraft that can fly at high subsonic speeds at high altitude carrying hundreds of passengers for 12 hour transoceanic flights. Not going to work too well. This is basically where you were at with past technologies to build complex, distributed, heterogenous, connected enterprise systems. It could be done, but the end result was not going to be pretty and it was going to take you a long time to get there.

Now with WCF, it is more like climbing into the cockpit of a 777. There is a technological elegance to everything that is there. But there are still hundreds (if not thousands) of individual switches, controls, displays, electronic gages and dials, menu driven control panels, etc. A great deal of human engineering has gone into everything that is in there so that for any given common task, there are only a couple of relevant controls that you have to touch and put into place to get the job done. The challenge is in knowing which one of those hundreds of knobs and dials to tweak.

The same is true for WCF. Microsoft has created an incredibly powerful and technologically advanced platform that is well adapted to building large distributed enterprise systems. In order to do that, there needs to be hundreds of switches and knobs that you can throw to address different scenarios. The downside to that is bullet number three above - you have to learn which switches and knobs are relevant for a given task, and in what order to throw them.

This is somewhat aggravated right now in that we are only at Beta 1 of WinFx (and its parts WCF, WPF, and WinWF), and the names, shapes, and locations of all the knobs and switches is constantly changing as they work on that human engineering task of trying to make it easier to use. Meanwhile the documentation and samples are seriously lagging, so working with it right now is a little like stepping into that 777 cockpit without any labels on the controls. When you say to yourself, "I just need transactions and certificate based security", it is kind of like saying "I just need to call the flight attendant at the second aft flight station". Simple to describe, but God help you in figuring out which switches and knobs to throw. At least there are not really any destructive ones that you can throw by accident. If you get it wrong, your app may not work, but you would have to go out of your way to write some code that would do bad things when WCF fails to let you communicate.

I'm looking forward to continuing to work with this technology and learn what all those knobs and buttons are for. Learning all the controls of the aft cockpit of the F-14 to run the weapons system, navigation systems, communications systems, and other tasks was one of the funnest things I have done in my life. The fact that we got to do that while strapped to a couple of 50K lb + of thrust zorching through the sky pulling G's and landing on the carrier certainly helped make it interesting. Sitting at a computer leaves a little to be desired in that department, but the learning challenge is still just as fun.