Pre loader

SciChart control version issue.

Welcome to the SciChart Forums!

  • Please read our Question Asking Guidelines for how to format a good question
  • Some reputation is required to post answers. Get up-voted to avoid the spam filter!
  • We welcome community answers and upvotes. Every Q&A improves SciChart for everyone

WPF Forums | JavaScript Forums | Android Forums | iOS Forums

0
0

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.

Background:

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.

Problem

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.

Solution

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.

  • You must to post comments
0
0

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.

Thanking You,

  • You must to post comments
1
0

Hi Vinay,

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.

Best regards,
Andrew

Images
  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.

Try SciChart Today

Start a trial and discover why we are the choice
of demanding developers worldwide

Start TrialCase Studies