mcneel / rhinocommontemplatepackage Goto Github PK

Hi @piac, @dbelcher

In @dbelcher's Your First Plugin with C# guide, it's recommended to reinstall the plugin each time we rename a command (see L108).

I'd like to update that line to reflect the current practice, which seems to be:

1. We do need to manually install the plugin on first build + debug run
2. During subsequent debug runs we don't need to reinstall the plugin after renaming commands

Before I do that, I just want to confirm that this is indeed the behavior. If so, which RhinoCommonTemplatePackage commit caused this? Was it caused by a Rhino update?

Thanks!

/dotnetversion=4
is no longer needed. Rhino 5 always uses .NET 4

System.Data
System.Data.DataSetExtensions
System.Xml
System.Xml.Linq

all seem pretty unusual for standard RhinoCommon plug-ins. Let's remove those from the project references

All I really care about is the Command name, not the name of any class.
I can just change the string for the name.
(Lowell's feedback)

It seems we might want to tweak the wizard so that it would accept to have the same name of the plug-in. Later, We can change the command class name to something unique, if the name is already taken.

A little bit more work but will allow people to figure out just one name.

In order to make C# plug-in compatible with the Rhino Installer Engine, the "RhinoCommon templates for v5" might need a new line in the AssemblyInfo.cs:
[assembly: AssemblyInformationalVersion("2")]

The static properties that let you access the singleton instances of the command and plug-in classes should be written as automatic properties. Here's a sample

public class MyPlugIn : Rhino.PlugIns.PlugIn
{
  ///<summary>Gets the only instance of the MyPlugIn plug-in.</summary>
  public static MyPlugIn Instance { get; private set; }

  public MyPlugIn()
  {
    Instance = this;
  }

  // You can override methods here to change the plug-in behavior on
  // loading and shut down, add options pages to the Rhino _Option command
  // and mantain plug-in wide options in a document.
}

We might want to experiment with Windows Presentation Foundation (WPF) project type Guids for templates.
This answer shows that it's used by VS to make better context menus:
http://stackoverflow.com/questions/11631034/how-visualstudio-knows-about-the-type-of-current-project

http://www.mztools.com/articles/2008/mz2008017.aspx

Rhino Templates cannot currently be loaded into VS 2019. I suspect this is owing to a flag in the manifest file rather than any limitation in VS 2019.

Please update accordingly.