We are planning to purchase SciChart wpf library, based on your answer for the question below we will decide whether we have to purchase library with source code or only binary is sufficient.
Our application is an library (Lib1.dll) which gets loaded into another application(App.exe) via some predefined interfaces. And there is possibility of multiple instances of library(Lib2.dll, Lib 3.dll, **.dll) from different vendors could be loaded into the same application.
In WPF Framework, when it tries to load the Control library of same name but different versions (and public Key Token), then it throws an exception. This issue arises only when control library has the same name. Since in Sci Chart, it has been decided to remove version information from control library https://www.scichart.com/should-we-remove-the-version-number-from-the-scichart-dll/ , then if Lib1.dll uses SciChart control version 1.0 and Lib2.dll from other vendor loads the SciChart version 2.0, it will throw an exception.
One solution is to ensure that all the SciChart libraries including future versions have different library names. Any other option ??
Let us know if you need any clarification.
Thanks Andrew for your quick response.
I agree that, using the AppDomain will solve this issue, however using the AppDomain will hit the performance.
When we investigated this issue, we found that by adding the below changes to the Control library csproject file, this problem could be avoided. This is bug in WPF framework.
i.e for SciChart Control csProject , if we add below statements, then this problem could be avoided without using AppDomain
<PropertyGroup> <AssemblyVersion>X.X.X.X</AssemblyVersion> // ( Library Assembly Version) <PublicKeyToken>XXXXXXXXXXXXX</PublicKeyToken> // ( Library public key token) </PropertyGroup>
If it is, this has been taken care in SciChart library, this problem could be avoided without changing the Assembly Name.
Let me know for anything.
The response from our survey was ‘yes, you should remove version number’ as its out of date with current best practice in .NET. Also, we would not be able to use NuGet to deliver our DLLs if the version number changed on each build. So, I’m afraid we will not be reversing this decision.
One survey respondent wrote C# already has a mechanism to restrict loading to specific versions, so this is redundant. It might be worth looking into C# AppDomains as this might solve your problem.
Please login first to submit.