We've not been able to produce an executable that runs on any machine other than the development machine. We've had some problems understanding the Northwoods documentation, as well as locating documentation on what a licenses.licx file should look like. As we've got to have a demo on another laptop in the morning, We'll have to ask for some help on how to get this executable licensed correctly. Your docs state: Thus as the developer you should make sure that your executable’s project includes a licenses.licx file including lines such as the following: Northwoods.Go.GoView, Northwoods.Go, Version=, Culture=neutral, PublicKeyToken=a4e3b7b70161cfe8 Northwoods.Go.GoPalette, Northwoods.Go, Version=, Culture=neutral, PublicKeyToken=a4e3b7b70161cfe8 We asume this means that this file is not generated, but that we should use a text editor to create a new text file named licenses.licx. If that is indeed the case, what should we supply for the PublicKeyToken value?. We assume that if we are using only GoDiagram Win 2.1.2, that we should include one entry only in this file, is that correct? Our license receipt stated that it was for version 2.1.1, would that have caused problems for us? What do we supply for the /i: parameter of lc.exe? We assume this should be a path to Northwoods.Go.dll, is this correct? We are aware we must include the licx file as an embeddable resource. Are there any other potential gotchas in this process that we should be aware of? We'll greatly appreciate any and all advice.

It might be easiest to look at the ProtoApp sample. This includes both a LICENSES.LICX file that you can use (unchanged if you don’t use any other 3rd party controls) as well as a .BAT file to compile and link everything (which demonstrates the /i: parameter).
Visual Studio .NET automatically maintains the LICENSES.LICX file for you, if you drag-and-drop a control/component from the ToolBox to the Form designer window. However, I believe it does not automatically update that file with the controls you are actually using as you edit your application, nor with the version numbers of the actual controls that you are using.
So, typically, the LICENSES.LICX file is generated by VS.NET, but you’ll need to update its version numbers of the components you use. I believe this the most common pitfall. Not making sure a copy of the LICENSES.LICX file is in the executable’s project, if your application is divided into an EXE and several UI DLL’s, is probably the second most common problem.
Microsoft .NET version numbers have four parts, all of which are considered for identification purposes by the .NET runtime. As far as Northwoods licensing is concerned, we just care about the major and minor version numbers (now 2.1).
The release or base-level number (the third number) just helps to distinguish different releases. There were several 2.1.0 beta releases; most of the functionality was present but things weren’t complete. There were a few 2.1.1 beta releases (with some enhancements, such as no-touch deployment support) and what I thought was the final 2.1 product release, labeled 2.1.1. But alas, our beta testing and regression tests did not catch some meaningful errors (as reflected in this forum!), which is why in the past month we have produced a beta 2.1.2, a release candidate 2.1.2, and the final 2.1.2.
The build or revision number (the fourth number) we have, for now, subverted for our purposes to represent the version of the .NET framework that it was compiled for.

OK we finally got it going. The instructions are really not clear unless one has previously used and deployed licensed .net components. Microsoft’s documentation is lacking as well. To wit, If you have not used the forms designer to create the controls, it is not clear from where the .licx file originates. Then, it may well be hidden in solution explorer unless the developer has it set to display object files and the like, something one might not be aware of unless they had been through the drill previously.