multiversion-revit-plugin-sample icon indicating copy to clipboard operation
multiversion-revit-plugin-sample copied to clipboard
verified publisher icon alvpickmans

Tweaks to simplify and improve the sample

Open StudioLE opened this issue 4 years ago • 3 comments

I noted the following tweaks while implementing the sample on an internal project.

Each tweak is broken into an individual commit as follows:

  1. Suppress an unnecessary and noisy warning

See example: image

  1. Removed AssemblyInfo.cs as it's now redundant with the SDK style format. Moved the metadata to the csproj

  2. Removed PreprocessorDefinitions as that doesn't appear to be relevant to C#. Removed the overly complex win forms logic. If the dev wants to use winforms then they may as well add it explicitly rather than this switch behaviour.

  3. Simplified the Revit API version selection

  4. Revised/Removed the overly complex mapping of metadata from assembly to .addin. It's clearer, simpler, and more flexible for the dev to modify the .addin directly. The one exception to this is the assembly path which is still written automatically to allow flexibility of Release/Debug builds

  5. Removed the DebugOne build. Again I find it overly complicated as the dev may as well just adjust the TargetFrameworks manually to determine what to build for and I can't see any logic behind the previous Debug configuration which built all frameworks as debug. Surely one is only ever debugging a single Revit version?

  6. Simplified version selection. Now you explicit select a single Revit version for Debug (by its version number) and a list of TargetVersions to Release. I did look into also setting TargetVersions for Release by a list of RevitVersions but couldn't find a solution)

StudioLE avatar Jan 04 '22 12:01 StudioLE

Thanks! This project is just one way of implementing Revit plugins targeting multiple versions, so it is not intended to fit everyone's shoes or used blindly. Commenting on the above tweaks:

  1. Nice
  2. Nice
  3. Nice, this was lifted from the original https://github.com/salaros/vs-templates-revit-addin without much changes (credits given in the article, might worth adding a note to it on the README too).
  4. Cool!
  5. I understand where this is coming from, but personally I like that details are set once in one place and replicated there where required. As this is a personal preference on how to setup the solution, devs can choose to modify this template to suit their needs and way of working, but I'd revert this to how it was as the article points to https://github.com/salaros/vs-templates-revit-addin for more details and info on the setup.
  6. Again, this change is a personal preference and no way is better than the other. I still like the fact that on Debug it compiles to all versions the project is configured to so dev does not need to fiddle with the csproj in case there is a need to debug in more than one revit version. I find it easier to remove things from a template that are not needed in a case by case rather than having to add it if needed (MSBuild is not the the simplest thing to get right)
  7. Similar to above comments, personal preference to set all project's supported versions in one place under no MSBuild conditional and just have one for Debug One with the default debug version.

alvpickmans avatar Jan 07 '22 09:01 alvpickmans

  1. [Metadata mapping] Yeah that's fair, I'll revert.

  2. & 7. [DebugOne] Yeah DebugOne does seem to have become a standard so I'll revert but I just never understood why anyone would want to Debug all versions simultaneously?

StudioLE avatar Jan 07 '22 09:01 StudioLE

While we're discussing Any idea whether this can be removed?

    <!-- Force the project to use the legacy debugger engine -->
    <DebugEngines>{351668CC-8477-4fbf-BFE3-5F1006E4DB1F}</DebugEngines>

I don't use this in any of my addins and as far as I'm aware it has caused no issues?

StudioLE avatar Jan 07 '22 09:01 StudioLE