Developing class library w/o shutting down WLP on each rebuild
Author: tcastle
Creation Date: 11/29/2016 11:40 AM
profile picture

tcastle

#1
Any ideas about how to be able to create and test.net developed wealthscript class dlls when Wealth-Lab Pro 6 is running?

As I create class library scripts in .net, I like to run them frequently to make sure that they are working correctly. The problem I run into is that Wealth-Lab Pro 6 apparently “locks” all compiled script .dlls at some point (either when Wealth-Lab starts up or when the .dll is first accessed) and never lets go until WLP shuts down.

WLP also will not recognize a dll script if it does not exist when WLP starts up, so there's no apparent way to create entirely new scripts and have them used by WLP that is already running. The first method would be easier in any event.

Because WLP locks .dlls, one cannot copy a new version of a .dll to replace an older version as long as WLP is running. This requires shutting down and re-starting WLP every time I want to make a change to a dll. I’ve tried to workaround by breaking a wealthscript strategy into two dlls and placing the second one (which contains the frequently changing script code) in a separate appdomain which is unloaded after the script has completed. Unloading an appdomain also gets rid of the dll it contains (there’s apparently no way to unload a dll directly in .net). Everything works fine, except for this: the 2nd dll must inherit wealthlab.wealthscript so that it can contain wealthscript code. But WLP does not seem to permit one wealthscript instance to create/call another. My locking problem is solved, but the 2nd dll can contain only non-wealthscript code.
profile picture

Eugene

#2
You could simply use "Edit and Continue" feature of Visual Studio to make edits without having to rebuild the DLL and closing WLP. Of course it requires that VS is attached to WLP process. It has been discussed on the forum before so you could find more in existing discussions (Hint: google for "site:wealth-lab.com edit and continue").
profile picture

tcastle

#3
Successfully attached Visual Studio strategy class library to WLP process. Debug breaks do pause code execution, but when I attempt to edit code I receive the following message:

QUOTE:
Changes are not allowed in the following cases:
- Attached to a process that does not support Edit and Continue on attach
- The code being debugged was optimized
- The assembly being debugged is loaded as domain-neutral
- The assembly being debugged was loaded through reflection
- Intellitrace events and call information is enabled
- The .Net Runtime this program is running on does not support edit and continue.


I've made sure that code is not being optimized, the above assembly conditions are not true, Intellitrace is not enabled.

I've set .Net runtime to 4.5.1 and am running 64-bit.

I've read that Visual Studio requires running WLP rather than attaching, and that debugging managed code when target is 64-bit does not work. Target must be set to x86 - see here: https://msdn.microsoft.com/en-us/library/7932e88z.aspx

??
profile picture

Eugene

#4
Kindly search the forum for an existing discussion where I successfully troubleshooted a similar case and provided instructions and a workaround. It pops up #1 in the google search (see post #2 for the exact query).
profile picture

tcastle

#5
Confirming that “edit and continue” works with 64-bit WLP and Visual Studio 2015 (Community Edition). Let Visual Studio start Wealth-Lab from debug mode (do not attach VS to already running WLP process). Do this by changing default Debug project property “Start Project” to “Start external program” and supply WealthLabPro.exe full path. Also confirm that “Enable native code debugging” is not selected. Don't forget to direct compiled build output to the folder containing WealthLabPro.exe.
profile picture

Eugene

#6
Right, that's exactly what I was suggesting in the mentioned thread:

Using Visual Studio 2015 for debugging
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).