SciChart® the market leader in Fast WPF Charts, WPF 3D Charts, and iOS Chart & Android Chart Components

Welcome to the SciChart Community Forums!

Please use the forums below to ask questions about SciChart. Take a moment to read our Question asking guidelines on how to ask a good question and our support policy. We also have a tag=SciChart on Stackoverflow.com where you can earn rep for your questions!

Please note: SciChart team will only answer questions from customers with active support subscriptions. Expired support questions will be ignored. If your support status shows incorrectly, contact us and we will be glad to help.

0
0

Is it possible to run two versions of SciChart at the same time? I wanted to create a new project in my codebase using the new SciChart version 2.1, without having to upgrade my other projects referencing 1.6. Of course, I now get version conflicts in my final build. Renaming the DLL did not work, is there a way around this?

  • You must to post comments
0
0

Hi there,

you should be able to, we enabled this in the latest v2.1.1 release.

i assume when installing you selected a folder other than the default Program Files/ABT Software/SciChart?

can you check your program files folder and see if there are two SciChart installations there?

it should have installed v2 to ABT Software/SciChart v2.1.1/

you just need to ensure you reference the right dll when adding references in visual studio.

Best regards,
Andrew

  • rjodon
    Thanks for your response. Sorry, I'm not sure if I was clear with my question, or maybe I don't completely understand. I only have 2.1 installed on my machine, but I still have the 1.6 dlls being referenced. So I have two DLLs, both named Abt.Controls.SciChart.Wpf.dll, one of them is 1.6, the other is 2.1. Each of my 2 projects references a different version. My projects however, are part of the same codebase, so compile to the same output directory. Due to the DLLs having the same name, but different version, I can only ever have one version of the Abt.Controls.SciChart.Wpf.dll in my output directory. I tried renaming the DLLs by suffixing the version number (e.g. Abt.Controls.SciChart.Wpf.1.6.dll and Abt.Controls.SciChart.Wpf.2.1.dll), but this does not work, as the projects still end up trying to locate the Abt.Controls.SciChart.Wpf.dll at runtime. I have other third party DLLs that include a version number in their DLLs, so I can therefore reference different versions without having to completely upgrade to a new version in one big bang. I was wondering if there was a way I could do this with SciChart. Cheers
  • Andrew
    Aha, I see. Good idea. Well currently the Dlls are named the same, but installed to separate directories. I would suggest that if you want to do an upgrade while keeping your old source intact, you should create a copy of your working directory (e.g. if using SVN or Git, checkout to a new directory, or create a branch) and perform the upgrade (referencing new DLL from new installation folder) in the new working dir. Then, once you are happy, commit to your repository and if necessary merge. That's how I would do it, although I'll add to our feature board the idea of having version numbers in DLLs. We do release pretty often (every few weeks) so a new version number might annoy some people, but might help others. Thanks for the suggestion! - Andrew
  • rjodon
    It definitely would be helpful in my scenario. I actually have a number of projects referencing 1.6, and only wanted to upgrade a few to 2.1 and use multiple versions simultaneously. I know it would be preferable to upgrade everything to 2.1, but my main issue was with the refactoring done between 1.x and 2.x. This means that I need to upgrade every single project to use 2.1 and fix all the errors created due to the refactoring. This scenario would be preferable, but I have time restrictions unfortunately. Thanks for your help!
  • Andrew
    Update: as it happens we're writing a performance test-suite, to test the performance of SciChart across multiple scenarios and versions. We've run into exactly the problem you're describing - different versions result in a FileNotFound exeption. The reason is that the DLL AssemblyName (internal to the DLL) is the same across versions, and visual studio can't pick them up as separate, despite different version numbers. So, to resolve the problem we're going to have to release Dlls with version number in the filename and assembly name. That will help us and hopefully help you too. Thanks for reporting! Best regards, Andrew
  • rjodon
    Ah great news. Yes, that is exactly my issue and will help in future upgrades. Cheers
  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.