-
Notifications
You must be signed in to change notification settings - Fork 16
Toolkits targeting multiple versions of the same software
It might happen that a Toolkit targeting a specific software will have to reference different assemblies for different versions of the software.
For example, this happens for ETABS_Toolkit. We will take it as an example in this page.
In ETABS, the various versions of the software have different API assemblies, and the assemblies have different names depending on the software version. For example: ETABS version 2016 has an API assembly named ETABS2016.dll; ETABS version 2017 has one named ETABSv17.dll.
For this reason, it's important to set the Build Configuration of the solution in a manner that allows the needed flexibility and maintains scalability.
For the sake of semplicity we will refer to this as "versioning" in this wiki page.
For example, ETABS_Toolkit needs to reference the software API (and therefore different versions of it) only in the project ETABS_Adapter.
This means that the other projects of the toolkit, namely ETABS_Engine and ETABS_oM, can avoid the problem altogether. No action should be taken on them.
If only one VS Project needs versioning, make sure the others projects' Build configuration target the base build.
You can set this in Visual Studio Build menu → Configuration Manager.
This means that Projects that do not need versioning – in the ETABS example the Engine and the oM – have to:
- For "Debug-type" builds: target the base
Debug
configuration; - For "Release-type" builds: terget the base
Release
configuration.
The following screenshot shows an example for "Debug-type" build:
The assembly name can be set by modifying the Project's .csproj
file.
This can be done by:
In VS, right click the project in Solution Explorer → Unload Project → right click again → edit
.csproj
. Edit, save, then right-click again on the project and do Reload Project.OR by navigating to the project folder and editing the
.csproj
directly.
The AssemblyName has to be defined so that it reflects the build version (e.g. 2017, 2018, etc.) and to be consistent with the naming conventions adopted for the specific Toolkit.
See the following example for the ETABS as an example:
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug17</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
...
<AssemblyName>ETABS17_Adapter</AssemblyName>
...
</PropertyGroup>
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug18</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
...
<AssemblyName>ETABS18_Adapter</AssemblyName>
...
</PropertyGroup>
Once you are done, please try to build using all configurations.
To ensure you are doing this correctly, go to the Toolkit's Build
folder and delete all its contents every time you test a different Build.
Contact the Toolkit's responsible - they will do it for you or assist you in doing that.
-
Introduction to the BHoM:
What is the BHoM for?
Structure of the BHoM
Technical Philosophy of the BHoM -
Getting Started:
Installing the BHoM
Using the BHoM
Submitting an Issue
Getting started for developers -
Use GitHub & Visual Studio:
Using the SCRUM Board
Resolving an Issue
Avoiding Conflicts
Creating a new Repository
Using Visual Studio
Using Visual Studio Code -
Contribute:
The oM
The Engine
The Adapter
The Toolkit
The UI
The Tests -
Guidelines:
Unit convention
Geometry
BHoM_Engine Classes
The IImmutable Interface
Handling Exceptional Events
BHoM Structural Conventions
BHoM View Quality Conventions
Code Versioning
Wiki Style
Coding Style
Null Handling
Code Attributes
Creating Icons
Changelog
Releases and Versioning
Open Sourcing Procedure
Dataset guidelines -
Foundational Interfaces:
IElement Required Extension Methods -
Continuous Integration:
Introduction
Check-PR-Builds
Check-Core
Check-Installer -
Code Compliance:
Compliance -
Further Reading:
FAQ
Structural Adapters
Mongo_Toolkit
Socket_Toolkit