Rebuilding MS123 ScoreCard (Demo version) doesn't work
Author: superticker
Creation Date: 8/23/2020 4:10 AM
profile picture

superticker

#1
I "attempted" to install the WealthLab.Visualizers.MS123 ScoreCard demo in VS 2017, but somehow the namespace and DLL references aren't working at all.


I tried deleting the WealthLab and WealthLab.Indicators references, then re-creating them, but that didn't help. I have no idea where to find the SystemPerformance and SystemResults references. Where are they located? Should I try reinstalling the ScoreCard demo project? (What went wrong with the first install, and why can't I correct it?)

The ScoreCard library is from 2012 using VS 2010. Is that a problem?
profile picture

Eugene

#2
The demo solution is quite dated (and shares very little code with the production version), .NET framework was at v4.0 back in 2012 and now we're targeting v4.6+. That's where the problem is. I've updated target platform version and made sure that references point to the WLD installation folder. Build is successful. Just uploaded the working version to the Wiki.

Important: The production version of MS123 Visualizers/Scorecard cannot co-exist with this demo version. Make sure to delete the demo version files and reinstall the 'real' Extension when you finished.
profile picture

superticker

#3
Thanks for doing that update. I just downloaded the project again, but all the creation dates are old. The download link is still pointing to the old library.

QUOTE:
The production version of MS123 Visualizers/Scorecard cannot co-exist with this demo version.
My goal is to create an entirely new project with the ScoreCard title Net Profile composite. Any ScoreCard metrics with a correlation coefficient less than 0.7 against Net Profit are going to be deleted because they aren't relevant to this project effort. As an entirely separate ScoreCard, they should be able to co-exist since these ScoreCards will be installed separately. Do I need to generate a separate GUID for this?
profile picture

Eugene

#4
QUOTE:
I just downloaded the project again, but all the creation dates are old.

Of course this is the old library (v2012.07 demo) which now should compile and build just fine under modern .NET frameworks 4.6.2 - 4.8 for use with WLD 6.9.15+

QUOTE:
As an entirely separate ScoreCard, they should be able to co-exist since these ScoreCards will be installed separately. Do I need to generate a separate GUID for this?

A Guid isn't that important. The key is to rename namespaces, assembly name and maybe class names.
profile picture

superticker

#5
QUOTE:
This is indeed the old library (demo version v2012.07) but it should compile and build just fine under modern .NET frameworks 4.6.2 - 4.8 ...
It now compiles successfully, but there's new errors about naming conventions. Does the production library also have this problem?


Concerning the creation of a new ScoreCard library ...
QUOTE:
The key is to rename all the classes, namespace and assembly name.
It makes sense to employ a new namespace and assembly name; say WealtLab.Visualizers.NetProfitComposite. But do all the classes also need to be renamed? One would be selecting one ScoreCard library over the other (since they are mutually exclusive), so couldn't they share the same class names?
profile picture

Eugene

#6
QUOTE:
It makes sense to employ a new namespace and assembly name; say WealtLab.Visualizers.NetProfitComposite. But do all the classes also need to be renamed?

Generally you'd think that they don't have to be renamed once you've employed a new namespace. But I urge you to rename class names to avoid potential runtime errors and "unable to cast" exceptions. Finally, it's for your convenience to not confuse your new classes with WL's existing ones.
profile picture

superticker

#7
Thanks for all the advise. This project is also coupled with some regression and factor analysis with R or MatLab, so there are many steps to go. I'm hoping I can get it done without learning the Windows GUI interface. If I do have to learn that interface, I would prefer to do it with Windows Presentation Foundation (WPF) and not Windows.Forms, since WPF is the more portable interface. And franking, I don't think you can find "new" programmers that practice Windows.Forms, so there's a support issue.
profile picture

Eugene

#8
+1 for WPF. It's the way to go.
This website uses cookies to improve your experience. We'll assume you're ok with that, but you can opt-out if you wish (Read more).