MetaAttributeComponent with SHFB

Oct 13, 2007 at 3:03 PM
Can MetaAttributeComponent be used with Sandcastle Help File Builder? Thanks!

Frank Hileman
Coordinator
Oct 13, 2007 at 3:26 PM
Currently I'm working on SHFB plugin to support this component. I will release new version in a few days.
Oct 13, 2007 at 3:28 PM
Hi,

I was going to make some suggestions about how integration for projects such as SHFB and DocProject should work (so thanks for starting this thread Frank! ;)

I believe, from what I've read online, that SHFB uses a static method to integrate build components into its interface. I plan to add a Sandcaslte configuration file editor into DocProject as well in the future but DocProject is not going to look for a static method. Instead, I'd prefer if custom build components used the System.ComponentModel.EditorAttribute for the following reasons:

  1. It is an FCL attribute so there will be no dependencies on any particular tool.
  2. The editor can be designed specifically for the component as a stand-alone dialog.
  3. Each component can be shown in the project's properties window without requiring a separate dialog to view and edit build components. (DocProject uses the PropertyGrid control, so this is simple to do using dynamic properties with a TypeConverter. And it already uses editors for other purposes so the infrastructure is there).
  4. A service model (ISite and IServiceProvider can be used to provide interaction with the host, allowing components to take advantage of tool-specific features if they exist. Of course, if tool-specific service interfaces are used then a dependency will be required; however, there are many useful service interfaces defined in the ComponentModel namespace that can be used instead. (DocProject already has this infrastructure in place for general project options in VS and in the DocProject External UI.)
I plan on creating my own build components eventually and this is how I've planned to integrate custom editors.

If SHFB, DocProject and other tools would like to support graphical interfaces for custom build components then I believe there should be an agreed-upon, universal approach to save everyone some trouble.

So what do you think? (I'd like to include Eric in this discussion as well, so I'll post a discussion in SHFB and link here.)

Thanks,
Dave
Coordinator
Oct 13, 2007 at 3:52 PM
Edited Oct 13, 2007 at 6:38 PM
Hello Dave,

I would like to keep my components independent on tools like SHFB or DocProject. I've discussed it with Eric on SHFB forum (http://www.codeplex.com/SHFB/Thread/View.aspx?ThreadId=16184). I'll distribute my SHFB plugin as standalone assembly with own configuration dialog and runtime component registration (at build process).

I agree with idea of common universal interface for using additional build components across custom tools.
Oct 13, 2007 at 4:45 PM
My own 2-cents is that the UITypeEditor API is overkill for presenting a UI, and restrictive. I can understand why Darilek would like to keep the component independent of either tool. I can also understand why Dave would like to use an already available API in the base class library.

The property grid is a flexible way to configure something. And you do not have to write a lot of special or tool-specific code to be able to use it. You just need to supply an object when requested, then stick that object in the property grid, which uses reflection to find properties and let you edit them.

Why not also use reflection to get the "editable object" from the component? A naming convention, a method with this signature, object GetEditableObject()? Just put the build component in a pre-defined directory, then either tool could pick it up find that method and use it for configuration.

Reflection could also be used to save the properties, i.e. look for a method with the signature:
string Save()

And assume that is an xml fragment.

Frank
Oct 13, 2007 at 5:05 PM
Edited Oct 13, 2007 at 5:06 PM
Hi guys,

Please take a look at the bullet points in my original post.

UITypeEditor is certainly not overkill, it's far more flexible. And hard-coding a particular signature is actually a hack since there is already support for this type of thing in the ComponentModel namespace, which is what I'm trying to show :)

Again, the benefits of using a UITypeEditor are automatic integration with the PropertyGrid control, support for both dialogs and drop-down editors, service support through ISite and IServiceProvider, an FCL attribute, and ease of use (if you're already familiar with this model then there's nothing new to learn).

DocProject already uses a PropertyGrid control and service providers, extensively, and I suspect SHFB does as well. But DocProject is a bit different since it provides VS integration and an external UI, so I like having this model because it provides the feature-set that I need and works in all scenarios.

Thanks for the feedback,
Dave
Oct 13, 2007 at 5:22 PM
Hi,

I just read the post that you linked to on SHFB, thanks. (FYI, you have to use [url:http://...] to make an external link that works correctly ;)

I agree with Eric that implementing an SHFB plug-in, although it may provide extra features for SHFB, is certainly not going to keep your components "independent" and as you mentioned, it may add issues when it comes to installation since your components may have to be aware of certain SHFB files (don't know for sure though).

That's why I'm suggesting the EditorAttribute approach - if Eric wants to provide a service for custom build components that do the same thing as his plug-ins, he can, and it will make things much simpler for your installation as well. You won't have to know anything about the SHFB installation or files since you could just use the service programmatically to configure SHFB-specific options for your components at runtime. Of course, that would mean your components may still have a dependency on Eric's service interfaces, but if he can use an existing FCL interface to provide the features of his plug-in support then your components could still be truly independent.

- Dave
Oct 13, 2007 at 8:26 PM
I've already voiced my opinion on using a plug-in as a configuration method and for inserting said configuration into the configuration file at build time in the SHFB thread but I'll repeat it here. I don't think it's a good idea as it complicates things and certainly isn't tool agnostic as it relies on the SHFB plug-in model. The plug-in model is strictly for altering the SHFB build process overall and shouldn't be connected to the build components especially since they already provides a configuration method. The problem with build components is that they don't implement a convenient IPlugIn type of interface that can be used to fully describe what to do with it.

I have been giving this some thought over the past few days. For SHFB, my idea is to create a Components folder much like I did for the plug-ins. SHFB will look in this folder and any of its sub-folders for a set of available build components. Rather than trying to stuff everything in the assembly and have to use reflection to figure out what it needs, my plan is to create an XML file sort of like a manifest that describes the component. It would name the component, provide a default configuration, and the name of the static method within the component that can be used to invoke an editor dialog much like I've already got although now it's name isn't required to be hard-coded, it just has to accept and return a string containing the configuration XML. If no method is provided, I will open an editor dialog that lets you edit the raw XML.

The file would also provide information on where in the sandcastle.config file the component configuration needed to be placed. Of course, the problem here is that there isn't an easy way to identify the components so I'd just come up with some arbitrary ID and description attributes to put on them to provide a way to identify before or after which component it should appear. This is fine for SHFB but if it's going to be used universally, we'd have to agree upon a common way of naming the existing parts of the stock sandcastle.config file. With this approach, you just have to drop the manifest and the build component assembly in the folder and the tool does the rest.

As far as the property grid goes, it's fine for editing objects with simple properties but when you want to do more with a property, you've got to write the supporting classes to provide better editing support. A simple example is the PostTransformComponent which supports a logo option. It's editor lets you view the image and preview it using the defined alignment and sizing options. If that is to be converted to support a property grid type editor, I've got to come up with a custom editor to do that. I find it simpler and more flexible to provide a dialog for editing the configuration. The other advantage is that you don't have to be familiar at all with the designer classes, UI type editors, type converters, etc. and all of the related stuff. You just have to know how to put together a simple dialog box. In order to implement a component, it shouldn't be necessary to have to learn a whole lot of stuff about how the designer classes work and write lots of supporting code and designer classes in order to provide editing support.

That's all I've got for right now.

Eric
Oct 13, 2007 at 11:27 PM
Hi Eric,

Thanks for the reply :)

From your response, I think the problem is going to be the fundamental differences in architecture between DocProject and SHFB, so let me state how I envisioned this to work for DocProject so that we can have both of our architectures out on the table first.

First off, DocProject exposes the sandcastle.config inside new projects. DocProject doesn't need to name each component since a user can simply add it where they want in the file. Therefore, it also doesn't need a Components folder or a component-configuration file since they will add no value to DocProject.

I was thinking about having a simple dialog that listed the components, top-down, with buttons to move the selected component up or down in the stack and to insert new components at any position. The fact that a custom component may require a certain position to function properly is something that just cannot be accounted for automatically given that the semantics of a Sandcastle configuration file is completely open to the person whom designs the presentation style. I'm not willing to give up this level of flexibility in DocProject either, so custom component authors will just have to provide enough documentation to let consumers know where in the build stack it must be added based on its function. The truth is, it's possible that a custom build stack might not even work with certain custom build components so I'd rather not try to handle this situation in code.

As for custom components being able to display dialogs, it seems that I wasn't clear enough before so I'll try again :)

Being able to show a custom dialog that has nothing to do with a property grid is exactly what I'm after with UITypeEditor. The interface is extremely simple and allows authors to pop open their own custom dialog. But it also allows them to open a drop down window if the component is being hosted as a property in a PropertyGrid control, if the right services are provided to it from the host application.

The reason why a static method is not going to be flexible enough is because I want component vendors to be able to take advantage of DocProject's API through services (IServiceProvider, which using UITypeEditor makes extremely simply. I also want to have a dynamic property in the PropertyGrid named, Components that, when expanded (think ExpandableObjectConverter), will list each build component in the entire stack, top-down, as nested dynamic properties. If an author uses the DisplayNameAttribute then that could be shown as the name.

This way a user can quickly pop open the editor as a drop down window or a dialog without having to go through some other dialog first. Basically, it will help to integrate component configuration into the properties window for each project by giving users one-click access to component-specific dialogs.

All that stuff I mentioned before about services and type converters are actually internal to the host (e.g., DocProject, SHFB), for the most part. I probably shouldn't have mentioned them because they are related more to implementation than high-level architecture - sorry.

Here's an example build component as I envisioned it to work:

[Editor(typeof(MyBCEditor), typeof(UITypeEditor))]
[DisplayName("My Custom Build Component!")]
public sealed class MyBuildComponent : BuildComponent
{
  public MyBuildComponent(BuildAssembler assembler, XPathNavigator configuration)
    : base(assembler, configuration)
  {
  }
 
  public override void Apply(System.Xml.XmlDocument document, string key)
  {
    // TODO: stuff
  }
}
 
public sealed class MyBCEditor : UITypeEditor
{
  public override UITypeEditorEditStyle GetEditStyle(ITypeDescriptorContext context)
  {
    return UITypeEditorEditStyle.Modal;
  }
 
  public override object EditValue(ITypeDescriptorContext context, IServiceProvider provider, object value)
  {
    if (provider == null)
      throw new ArgumentNullException("Missing service provider.");
 
    IXPathNavigable innerXmlConfig = (IXPathNavigable) 
      provider.GetService(typeof(IXPathNavigable));
 
    if (innerXmlConfig == null)
      throw new InvalidOperationException(
        "Um, where am I?  The host didn't provide my config!");
 
    string xml = innerXmlConfig.CreateNavigator().InnerXml;
 
    // DocProject already provides this service now to custom build engine 
    // providers in its DocProjectOptions class: 
    IUIService hostUI = (IUIService) provider.GetService(typeof(IUIService));
 
    // This service is theoretical.  It would be optional, although if used it would
    // result in a dependency on DocProject's library: 
    IDocProjectHostService host = (IDocProjectHostService) 
      provider.GetService(typeof(IDocProjectHostService));
 
    // This interface is one of the main interfaces in DocProject, I just need 
    // to provide the service above so that custom build components can get it.
    IDocProject project = host.Project;
 
    // TODO: use 'project' to do, basically anything to the project, 
    // such as get reflection information or information about source 
    // assemblies.  Or even run a build in the background, etc.
 
    using (Form form = new Form())
    {
      InitializeForm(form, xml);
 
      if (form.ShowDialog(hostUI.GetDialogOwnerWindow()) == DialogResult.OK)
        return true;  // success, host should persist the changes to innerXmlConfig
      else
        return false;  // canceled by user
    }
  }
 
  private static void InitializeForm(Form form, string xml)
  {
    TextBox textBox = new TextBox();
    textBox.Name = "Xml Configuration";
    textBox.Text = xml;
    textBox.Dock = DockStyle.Fill;
 
    Button okButton = new Button();
    okButton.Text = "&OK";
    okButton.DialogResult = DialogResult.OK;
    okButton.Dock = DockStyle.Right;
    okButton.Margin = new Padding(0, 0, 8, 0);
 
    Button cancelButton = new Button();
    cancelButton.Text = "&Cancel";
    cancelButton.DialogResult = DialogResult.Cancel;
    cancelButton.Dock = DockStyle.Right;
 
    Panel panel = new Panel();
    panel.Height = 50;
    panel.Dock = DockStyle.Bottom;
 
    panel.Controls.Add(cancelButton);
    panel.Controls.Add(okButton);
 
    form.Controls.Add(panel);
    form.Controls.Add(textBox);
  }
}

I hope that clears up why for DocProject a plug-in or component-configuration file is not required and why using a static method is just not the right way to go. I hope that you feel users of SHFB can benefit from this approach as well :)

- Dave
Oct 13, 2007 at 11:45 PM
I'm still not convinced about the UITypeEditor. Your example uses IDocProjectHostService which then ties the component to DocProject and would require distribution of one of your libraries. Thus we lose tool independence.

Eric
Oct 14, 2007 at 12:02 AM
Hi Eric,

But it's an optional service. As I stated in the comments, it would provide a level of flexibility that I may need for the components that I plan to write.

And and author doesn't have to (and shouldn't!) redistribute an entire DocProject assembly just to use that interface. For example, DocProject uses BuildAssemblerLibrary.dll but I certainly don't ship it with DocProject ;)

Basically, if a component author wanted to take advantage of a DocProject host service and an SHFB service, then it's just a matter of adding a class to encapsulate using each particular service. To do this AppDomain.CurrentDomain.AssemblyResolve can be used for when the framework can't load an assembly on its own (although, DocProject is installed in the GAC so it won't be necessary). That's how I delay load Sandcastle's assemblies from within DocProject without deploying them - DocProject knows where they're located so when the framework asks, DocProject responds with, "look here...".

I understand that some of this stuff might be too advanced for users but a simple working code example that shows how to run a dialog and isolate code to specific hosts should do the trick. The code above handles the dialog part nicely, so all that would remain is a class that encapsulates the DocProject host UIs and catches FileNotFoundException if the assembly is not installed.

If you want, check out this class for the implementation I use in DocProject: AssemblyLoader.cs.

- Dave
Oct 14, 2007 at 12:17 AM
I just realized that the AssemblyLoader code would probably be easier to understand with some examples of implementations as well :)

DocProject creates an instance and calls TryLoadAssembly to see if it's available. That's it!

- Dave
Oct 14, 2007 at 2:33 PM
UITypeEditor is not required to make an object editable in a property grid, it is only required when that object is the value of a property in a line in a property grid. I agree with Eric, as soon as you want to do anything complex with exposed properties you have to learn about a whole slew of ideas, so it is not as high level as saying "provide a UI and give back the resulting xml fragment". I have a lot of experience with property grid editing and its learning curve. I thought at a minimum a property grid might be a structured way to edit the text of an xml fragment. Maybe I was wrong and a text editor is easier.

Dave, component providers can already take advantage of any custom infrastructure, simply by implementing an interface you look for in the tool, and your infrastructure can provide services without UITypeEditor etc. For example your "service" could be used without the service provider system in IComponent, it is just a matter of providing an object when requested.
Oct 14, 2007 at 2:38 PM
The advantage of avoiding dependencies of tool-provided data types (services, interfaces etc) is that the component continues to work as the tool changes. It does not need recompilation. This is a big advantage of reflection-based interaction over interface or serviced based interaction.
Oct 14, 2007 at 4:15 PM
Hi Frank,

It seems that you're arguing against features that I want to support in DocProject! Sure, I can just ditch the whole idea of displaying components in the property grid and simply call a static method, but that's just not flexible enough for my needs :)


UITypeEditor is not required to make an object editable in a property grid, it is only required when that object is the value of a property in a line in a property grid.

I never said that it was required. And yes, as I stated previously I plan to display the components as dynamic properties (line items) in my property grid. I want users to be able to create a dialog or a drop down window. I'm not sure how many more ways I can express this!


I agree with Eric, as soon as you want to do anything complex with exposed properties you have to learn about a whole slew of ideas, so it is not as high level as saying "provide a UI and give back the resulting xml fragment".

I'm trying to support DocProject's feature set at the cost of some ease of use, although I've been working on a Build Component item template for VS this morning that will solve that problem. I'm almost done. It handles everything I've shown above and even supports Eric's static method architecture without an author having to change anything in their code, which is especially nice for my own components since I'll want them to work in SHFB but I also want to take advantage of DocProject's API.


I have a lot of experience with property grid editing and its learning curve. I thought at a minimum a property grid might be a structured way to edit the text of an xml fragment. Maybe I was wrong and a text editor is easier.

I don't think you guys are getting this though... Nobody has to learn anything about property grids at all! The host handles the grid stuff, unless a user wants to take advantage of grid features such as a drop down editor. You'll see when I publish my item template.

Also, DocProject isn't going to have a general-purpose text editor for components that don't provide their own (such as the built-in Sandcastle components). Instead, it's simply going to open the sandcastle.config file in VS's XML editor and select the component's XML - at least that's my plan ;)


Dave, component providers can already take advantage of any custom infrastructure, simply by implementing an interface you look for in the tool, and your infrastructure can provide services without UITypeEditor etc. For example your "service" could be used without the service provider system in IComponent, it is just a matter of providing an object when requested.

The problem isn't how to get tool-specific functionality out of a custom build component, it was how to do it while maintaining independence from tools so that the component may be used everywhere. My architecture allows for this. If I required a user to implement an interface then they would certainly require DocProject to be installed. Using IServiceProvider instead solves that problem. Also, the UITypeEditor is not being used just because it works with IServiceProvider. It's also going to being used, to state this again, because DocProject will display components in the property grid.


The advantage of avoiding dependencies of tool-provided data types (services, interfaces etc) is that the component continues to work as the tool changes. It does not need recompilation. This is a big advantage of reflection-based interaction over interface or serviced based interaction.

Reflection only works one way. I've made it clear in my examples that I would like the components to be able to consume DocProject's API. Having a static method for configuration cannot solve this problem using only reflection :)

Anyway, I think DocProject needs this level of flexibility. If tools such as SHFB don't, then I guess I'll just have to add a static method to support them if I write custom build components myself. (That's why I've included the static method in the item template that I'm working on.)

Here's an example of where having this level of flexibility is useful: Eric, when creating the colorizer if you were to use DocProject's API, when it's available at runtime, the colorizer could automatically create/discover the highlight.xml file relative to the project's directory. It's so simple, but would save users having to worry about paths since VS and DocProject pretty much handle that for them everywhere else.

I guess the best solution is for SHFB to use a static method and for DocProject to use EditorAttribute, and anyone who wants to support both can use my item template. Is that acceptible? Because if it's not I'm certainly still open to any better ideas :)

Thanks,
Dave
Oct 14, 2007 at 4:37 PM
Hi Eric,

Ok, so I realize now that although my item template will be useful, not everyone is going to want to use it. And that's fine, so I guess I'll just have DocProject look for EditorAttribute and if it's not found then look for the static method. But would you at least be open to changing the method signature to accept an IServiceProvider parameter so that users can still take advantage of simple features like IUIService?

Thanks,
Dave
Oct 14, 2007 at 10:43 PM
No offense intended Dave, but you seem to be stuck on having build components support features in DocProject. That's what I want to avoid. We shouldn't be dictating to build component developers that in order to be used by GUI X they must implement support for this set of attributes/interfaces, be editable within a property grid, and so on. My goal is to go the other way. The build component developers give us a set of information that says my component depends on these things, here's how to invoke an editor for it, etc. now you go figure out how to fit it into your GUI's editing environment. If that involves us wrapping it in a class that makes it editable inside of a property grid, a list box, or whatever, so be it. It shouldn't be something the user has to worry about.

On a similar note, as long as we can find the method to invoke the editor, we can determine the number and types of parameters so again, it shouldn't be required that they implement an editing method that takes anything more than a string. If you support a method that takes a string and a IUIService object, you can look for it and, if found, use it. If not, fall back to the bare minimum method that only takes the string. To me, the use of IUIService implies that the build component is being tied to a specific GUI because its going to expect a set of features that it can get to through that interface.

Eric
Oct 14, 2007 at 10:48 PM
Hi guys,

I've created a preliminary template for C# and attached it as a ZIP file to an old work item: Sandcastle Build Component Item Template. It should work fine with or without any automation tool and with editor support for the Sandcastle Help File Builder, and DocProjcect's editor support once it's added.

Eric, could you please take a look at it and let me know if it's compatible with SHFB? Thanks :)

Simply download the .zip file into your My Documents\Visual Studio 2005\Templates\ItemTemplates\Visual C#\ directory and it will automatically be accessible in Visual Studio's New Project Item dialog.

NOTE: Due to a limitation in VS templates that have multiple files, the {item_name}EditorControl.cs file, where {item_name} is the name assigned by the user, will contain invalid information that MUST be edited manually for it to build. When the file is created it will contain the following string, twice, near the top of the file:

{item_name}EditorControl.{item_name}EditorControlConfiguration
Replace both appearances with:

{item_name}.{item_name}Configuration
where {item_name} is the name assigned to the build component when it was created in the New Item Dialog. For example, CustomBuildComponent1.

Thanks,
Dave
Oct 14, 2007 at 11:05 PM
Hi Eric,

We posted around the same time so I didn't see your reply :)

Anyway, there's no offense taken. I completely understand your point of view on this. It's just that I don't feel like my architecture is forcing anything on component vendors. They certainly don't have to provide a UI, or, if they want to support SHFB then they can use a static method, or UITypeEditor if they want to use DocProject's features. Or, all of the above!

But it sounds like you're suggesting that I'd be able to get these features without using UITypeEditor, which doesn't make much sense to me because that's what that class is for! If I tell vendors, "hey, you can create a drop down or a modal dialog since DocProject simply sticks your component in a property grid" then that's great - they have a choice. But nobody's forcing them to do it. And the beauty of this model is that it has no dependencies on DocProject, although that's kind of what you keep saying I think (unless I'm wrong, please correct me!).

Basically, this is how I see it: To ask component developers to define the feature set of the host seems ridiculous. I'm simply offering features that they can use, but in order to use them I require an FCL attribute that has no dependency on my software.

If we can't decide on one universal method, then at least I can offer this feature as an extra hopefully without interfering with SHFB. That's why I was hoping that you could check out my item template and make sure that it will work with SHFB. The item template has no dependency on DocProject whatsoever and even defines a static method that handles the SHFB stuff. (The link is in a previous post in this thread :)

But I do have one question: Does the string passed by SHFB to the static configuration method contain the component node or just the inner XML? I've coded it expecting the component node to be part of the xml as well.

Thanks,
Dave
Oct 14, 2007 at 11:59 PM
I didn't plug it into the SHFB config to be sure that the component will work but the necessary features appear to be there. I pass the full configuration including the parent <component> element to the configuration method. It's stored that way in the project file to so that I can just look up the component ID and replace the stock component element with the given modified element. It also supports replacement tags in the component path so that everything points to the right location at build time.

Eric
Coordinator
Oct 15, 2007 at 6:42 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Oct 15, 2007 at 7:22 AM
Hello Dave,

thanks for template. Although I've completed configuration support for SHFB, I will try implement it for DocProject also.
Oct 15, 2007 at 1:21 PM
As an end user, I would prefer to use components that do not need to be recompiled when the tool changes... and component providers may not bother to recompile their component, every time a new tool build is released. As soon as you add tool-specific interaction it becomes a type of plug-in, not just a sandcastle build component. That's the end of my 2-cents on the matter :)
Oct 15, 2007 at 2:01 PM
Hi guys,

I had posted a response but it doesn't seem to be here (I probably just clicked Preview and forgot to post it :p)...

Eric,

Thanks for checking it out, I appreciate it.

Martin,

I plan to finish the related work items for DocProject's next release so that if you choose to use the item template, or a variation, it will not be for nothing :)

Frank,

I appreciate your feedback, thanks :)

Using the current item template no recompilation would be required for custom build component vendors to integrate their components into DocProject's UI.

However, if a vendor decides to build against specific DocProject interfaces or the DocProjectEnvironment class then you are correct that the build component would need to be rebuilt as well for subsequent releases of DocProject. Now I don't know whether community members are going to want to do this, but I know that I will. When I create custom components I will rebuild them as well for each release of DocProject. I'll also ship them with DocProject's installer so rebuilding them won't be a problem for me, but I understand if others don't want to for the reasons that you are suggesting.

But please realize that a Sandcastle build component is meant to be a plug-in for the Sandcastle build process. When you want to target Sandcastle command-line builds only in a custom component then you only have to worry about Sandcastle's constraints. However, as soon as you want to target SHFB, for example, then you need to add a static method (optionally). And if you use the Sandcastle build component architecture to create plug-ins that are specific for DocProject, for example, then I don't see what the problem is if you optionally use EditorAttribute. There's nothing stopping you from shipping another version of your component that works outside of DocProject as well for some other tool, or as I've done in my item template, design your component to work anywhere.

In other words, I understand if you don't want to use components that require DocProject interfaces, but if you're not using DocProject then it makes sense. If you are using DocProject, then you may want to have components that fit nicely into DocProject's architecture and take advantage of specific features. It's all about perspective here, and it seems that you'd prefer if everybody only had the ability that Sandcastle offers from the components and nothing else - I can't except that for my custom build components since, obviously, I will be targeting DocProject specifically, among SHFB and command-line support :)

- Dave
Oct 15, 2007 at 5:00 PM
FYI, I just published version 1.2 of the item template and another .zip with the code for a Form that I used to test the item template in a PropertyGrid.

http://www.codeplex.com/DocProject/WorkItem/View.aspx?WorkItemId=10986

Please let me know if you have any questions or ideas on how to improve it :)

Thanks,
Dave
Nov 8, 2007 at 2:11 AM
Hey guys,

I just published the first production release of the item template, which fully supports DocProject's new build component stack editor features and should support SHFB as well, although I haven't tested it:

Sandcastle Build Component Item Template

It's in C#, but I do plan to create a VB.NET version as well.

Please let me know what you think. If you want to try using it and you need some help, just ask. And if you have problems using it with SHFB let me know and I'll be happy to fix the bugs :)

- Dave
Coordinator
Nov 11, 2007 at 9:13 AM

davedev wrote:
Hey guys,

I just published the first production release of the item template, which fully supports DocProject's new build component stack editor features and should support SHFB as well, although I haven't tested it:

Sandcastle Build Component Item Template

It's in C#, but I do plan to create a VB.NET version as well.

Please let me know what you think. If you want to try using it and you need some help, just ask. And if you have problems using it with SHFB let me know and I'll be happy to fix the bugs :)

- Dave


Hello Dave,

I will include DocProject support in next version (1.0.4.0)