New-instruction-for-using-Visual-Studio-to-develop-and-debug-strategies

Yes it's not just rusty, it's applicable to WL6 only. For WL7 we'd need to rewrite it. Adding it to our backlog.

I was able to generate a strategy dll in VS buy creating .NET Core library and then adding WL7 references to dependencies and directing output path to ..\Quantacula, LLC\Wealth-Lab 7\.

The only issue I have is that my DLL get copied to 'netcoreapp3.1' subdirectory.
Each time I compile it I have to re-copy back to \Wealth-Lab 7. Once I copy it WL7 discovered it and add it to Strategies folder.

It turns out that this is already documented under ExtensionApi:

Strategy Library API

It's a start but I think we could beef it up with a step by step procedure of debugging a strategy in VS or VS Code.

@MohammadRashid

QUOTE:
The only issue I have is that my DLL get copied to 'netcoreapp3.1' subdirectory.

Solution: Stopping MSBuild appending TargetFramework to OutputPath
https://www.tabsoverspaces.com/233608-stopping-msbuild-appending-targetframework-to-outputpath

We'll expand on it in some of our API doc as the Visual Studio team didn't make it obvious and for some reason refrained from making it configurable via GUI.

---

Step by step:

1. Suppose your project is called ''Strategies''. Close solution in Visual Studio, find ''Strategies.csproj'' in the solution directory and modify the header, adding the two lines:

CODE:
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath> <AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>

The beginning of the file now looks like this:

CODE:
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <UseWPF>true</UseWPF>
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath> <AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
  </PropertyGroup>
...

2. Launch Visual Studio as admin: right-click on the shortcut as choose "Run as administrator".

3. Reopen your project and go to Project > Properties. There make two changes:

* On Build tab, set Output path to: "C:\Program Files\Quantacula, LLC\Wealth-Lab 7"
* On Debug tab, set Executable to: "C:\Program Files\Quantacula, LLC\Wealth-Lab 7\WealthLab7.exe"

Provided you tweaked the properties correctly, the Strategies.dll file will get copied (or overwritten) into the WL7 folder when you click "Start Debugging" (F5 key) and then Wealth-Lab 7 will automatically start. If a breakpoint is hit in your code you can evaluate variables and even edit your code on-the-fly to the extent allowed by VS. This is known as Edit and Continue feature.

I don’t usually use debug mode. But what I really want is to code in VS and to have a pipeline like this:
- Write strategy code in VS.
- Compile in VS.
- Run the strategy in WL7 with no need to restart WL7 so it can see the strategy and run it.

What I can by this moment: I can write code in VS, compile in VS, automatically save to WL7 folder (if WL7 is not running). So what is left is: to be able to compile while WL7 is running (now VS generates error) and WL7 to be able to see the actual compiled strategy without restarting.

Please-please. Help with that. I can’t write much code and experiment withing WL7 Code Editor.

Writing code is iterational process. It doesn't look good to restart WL7 many times during the process, it's not convinient at all.

Follow instruction in my Post #4 to set things up and learn about Edit and Continue. E&C is what you're looking for. No need to restart WL7 except for some modifications of lambda expressions and anonymous methods.

If I create Net core class project - many words are underlined red. If I create .Net Framework project - there are no red underlining, but the error when F5.

Squiggly lines should go away if you add a reference to WealthLab7.dll.

They didn't, but here is some more detail. A little bit Russian language. Something about versions.

I mean this screen was made before adding WealthLab7.

Well this is assembly version mismatch. Like the assembly reference you're trying to add to your project having a higher version than installed build of WL7. Double check your paths.

The problem was that my VS project used .Net Core 3.0 ant VS didn't see my installed 3.1.

VS reinstalling helped.

So, I'm in.
(after deleting all that "debugger detected" generating extensions)

So, what I did:
- F5 in VS.
- Found my strategy in WL7.
- Ran backtest.

And what is a pipeline if I whant (beeing in WL7) make some changes to the strategy and run backest again? The pipline I know is:
- shift-F5 (stop debugging) in VS. WL7 closes.
- Make changes.
- F5. WL7 starts again.
- Finding strategy.
- Running backtest (plus setting backtest settings again maybe).

Is there a faster pipeline? For example letting me to avoid:
- restarting WL7 (I do not do it manually, but it takes time).
- opening my strategy (it will be on Home Page, but still).
- Setting backtest settings again.

At the risk of repeating Post #4 above, it works much differently. No need in Shift-F5!

Strike F5 in VS. Set a breakpoint in your code (you can do it at any time). Once control falls to that code line, VS automatically pauses program execution and you can evaluate variables and even edit your code on-the-fly with IntelliSense support. Let me suggest you find out more about Edit and Continue feature:

https://www.youtube.com/watch?v=tVqYS-SfkVk

Thanks a lot, Eugene, now it seems to work as expected).
Sorry, I was focused on fighting errors and exceptions) and didn’t pay enough attention to the last sentences of your instruction).

Now I feel ready for creating dream strategies)).

I still can't like comments to the topic where I'm an author, so let it be the best answer)

I will add that the directions in Post #4 apply to both Local.Indicators.dll and Local.Components.dll common-code libraries as well as Local.Strategies.dll libraries all built with Visual Studio 2019.

When done as directed in Post #4, VS builds three files into the WL7 install directory: Local.Components.dll (the binary executable), Local.Components.pdb (symbols table for symbolic debugger), and Local.Components.deps.json (version dependency manifest).

Which one are you guys using - Visual Studio Code or Visual Studio Community Edition? I am confused which one is compatible with WealthLab 7?

I am using Visual Studio Community Edition 2019 and it's ok.

I thought I can get away without setting up Visual Studio and learning it. But very soon I got tired of adding WriteToDebugLog() statements. I have to say developing in Visual Studio is 50x more efficient. Probably I would have saved many hours if I had picked up Visual Studio on day 1 of WL7 :-)

It's time for a compliment!

The WL7 integration with the VS 2019 Debugger is well done. Debugging (when set up correctly) is just like a Kids game.

Compared to QS (or Ninjatrader, which I was using the years before), it's integrated very smooth and it also takes me (finally) away from the "WriteToDebugLog mumbo jumbo"...

Great Job!!!

you can also just add this as a post build event in the project file

copy "$(TargetPath)" "C:\Program Files\Quantacula, LLC\Wealth-Lab 7\." /Y

OK, got it working according to #4 post (VS2019). Pressing F5 launches WL7 and am able to debug and do some editing. However, there is a limit to VS's ability to on-the-fly edit the code. Thus having to stop debugging, which restarts WL7 at the next debug.

Is there a way to keep WL7 from restarting, even when stopping debug (tried to understand posts #14/15)?

Unfortunately, certain changes you make (LINQ in the first place) require restart of the attached application. You're better off asking on StackOverflow.

Yes, sometimes you still have to restart WL7 anyway. But still I find it more convenient to use VS with WL7 for making strategies.

It is most definitely more convenient.