Developing-and-Trading-at-the-same-time

You can run two instances of WL8 right now, shouldn't be a problem. One instance can be trading while the other developing.

This does not work if the dll you modify is loaded by the first instance. There won't be write access to that file.

Glitch, it seems that topic starter would like to split the user data folder. In this case he could run second instance in a virtual machine or in a different PC / cloud server. Having a 2nd installation also works to avoid the DLL file lock.

Hi Eugene. Yes, there are several solutions possible. I think loading the user files depending on the mode WL is started, is very lightweight solution. It can be done on the same machine like running standard WL8 instances at the same time. Having one dev-mode running would allow exclusive write access to such a folder and its files.

If it were me I would be modifying a copy of the DLL, not the production DLL.

That is implicit. There is a copy (locked) in the prod folder. At some point the dev file needs to be copied to the prod folder.

If you don't have two computers, then just make sure your dev DLL is named differently. Then there should be no conflict with locking of the DLL.

Nobody is saying to modify the productive dll.

1. it cannot be modified because of a write lock
2. loading a copy from a different folder does not change the prod dll. The dev instance simply does not load the productive dll.

So two instances running on the same machine but loading two different (dll) files.
For me it is an advantage to work with one workstation. I don't want to have three computers on my desktop.

@Glitch

When i debug a project with VS, the name will be related to the project. At the same time WL is started and tries to load the file. Yes, i can rename the project or i can rename the dll and load WL manually. There are many ways to handle it, sure.
I also can use different computes.

But all these steps would loose the compfort the VS setup has.

All is needed is to load a second instance with a copy of a file. Trivial.

On a single PC you could run the dev environment in a virtual machine.

Mmmm it doesn't sound trivial, you're asking us to create two separate modes. It just adds more complexity. If there's a solution that already works we'd rather not complicate things.

Ok. I admit when you look at the details you probably have to consider more things than I have listed so far.

I think you can simplify the idea further without introducing a separate mode.

When loading WL, only a user directory needs to be scanned. If there are dll files in it, they are loaded first and dlls with the same name from the main directory are ignored (not loaded).

If there is no file or none with the same name as in the main directory, the files from the main directory are loaded as usual.

So, no mode anymore. Only user files are loaded preferentially.
If the developer does not develop he can delete the files from the user directory.
An emty user directory will force WL to load the productive files from the main folder, as "standard mode"

Users who do not develop via the IDE are also not affected, since the user directory is not used.
As a developer, I can simply customize the working directory (output folder) as needed in the VS IDE.

I’m still trying to understand the need for a separate folder. How does the fact that a dll is loaded from a different folder overcome the locking issue?

There won't be a lock because it is about different files.

C:\Program Files\Quantacula, LLC\WealthLab 8\my.dll
C:\Program Files\Quantacula, LLC\WealthLab 8\user\my.dll (different file "copy")

The first instance loads "my.dll" from the main folder (if the user folder is empty at that time).

The second instance will be started out of VS which creates a file in the user folder.
Now when WL is loading its ressources, it loads preferably the my.dll from the user folder. It is not locked by the first instance.

Wouldn’t it be just as easy to delete the dll from the main folder?

It cannot be deleted or overwritten while it is in use (which is the reason for the lock) The first instance is using it.

Ok, it might only be loaded but not in real use. In such a case it could be deleted before running the first instance. But it can be loaded and be in real use because a strategy is running from the dll. In this scenario it does not make sense to delete it before.

That should not stop a developer from working on the project (with the compfort we reached so far) and use it with another WL instance

By the way, the reason why i don't suggest to simply load both dlls at the same time is, that the contents would be duplicated in WL. I guess that could lead different kind of problems. So, one or the other seems to be fine.

I mean delete it before starting WL.

QUOTE:

Ok, it might only be loaded but not in real use. In such a case it could be deleted before running the first instance. But it can be loaded and be in real use because a strategy is running from the dll. In this scenario it does not make sense to delete it before.

Perhaps you overlooked this part. I take into account before the start of the first instance as well as before the start of the second instance. If my project file is in real use i simply need to work with a copy in WL. I only can create a copy with the same name in another folder. This folder needs to be loaded by another instance preferably instead of the dlls in the main folder.

Yes I did overlook that part. It seems like the current solution is two dlls with different names. Perhaps append “dev” or “test” to the test version?

As mentioned before.

Renaming the file will break the automated VS setup for sure. WL needs to be started manually then, because the project always compiles with the same resulting name. You need to define another output folder for the project if an instance of WL is running. Otherwise the file cannot be created, because it can not be overwritten. Then, after renaming it you need to move it manually to the main folder and load another instance of WL. You need to do this with every single change in the code. When starting WL manually the debug mode is not available, so it needs to be started out of VS. So, it would not only be ugly, i guess debugging mode would not be available then at all.

On the other side you can load dlls from two folders easily.

Just load files from the user folder first. Ignore files in the main folder that have the same name as the files in the user folder. Thats's it.

The developer needs to clean/maintain his working (user) folder. The advantage for the developer is, the debugging framework will work with a second instance on the same computer. It is easy to remove files from this user folder, so the dlls from WL standard folders are used.

Thanks for taking time to look into that topic.

QUOTE:
Just load files from the user folder first. Ignore files in the main folder that have the same name as the files in the user folder. Thats's it.

Loading files from a user folder first and ignoring synonymous files in the main folder looks like overcomplication. And it may have other consequences. One day a forgotten file will make a developer stumble and lose time in troubleshooting.

Much like with an overlooked option activated in Preferences and causing trouble - did it happen to you two days ago?
https://www.wealth-lab.com/Discussion/Why-is-my-position-size-less-than-Fixed-Value-8155

QUOTE:
... overcomplication ...

The risk for the devloper is clear. To maintain serveral intstallations, working with different computers, setting up a vm and so on is of course much more trivial than just loading dll files from exactly two folders. "LOL"

No developer is forced to setup the output folder to this user folder, no risk there.
The advantage outweight the risk for people who decide to use it.
And really, is it that hard to make it visible from where the ressources are loaded from?
Like using a different color for the contents or a simple message when starting, like "data loaded from the user folder". Come on guys ... really.

Only DrKoch made a good point but is beyond the topic.
To work with several instances on the same computer that use the same ressources (not only the dll in question) might not be recommendable when one instance is trading. But this is a point that everyone can decide for themselves.

Thanks for the discussion. It is up to you now.

Everyone has their own perception, and in many cases wildly divergent. From my perspective, I’d have no trouble simply naming my development dll something else and getting on with my work. You probably could have done this several times over using the same energy that you used posting in this thread.

We have almost 90 items already in the wish list. Everyone has their own pet items they want to see implemented. We can’t possibly do all of them, but we do our best to prioritize based on demand. Why don’t you submit a #FeatureRequest?

Thanks Glitch. I am fine with it.

Seriously, the alternatives have been mentioned, and I recognize that.
I also respect when someone simply asks when points are unclear.

But "overcomplicated" was too much for me, lol..
Especially compared to the alternatives.

EDIT:
It is not about renaming a file only. The entire debugging process out of VS does not work because of that.

Many thanks to the entire team. The response times and quick feedback are exceptional. I like it.

It's just that you don't always get what you want, that's normal.

Thank you everybody.

You’re still welcome to submit the #FeatureRequest, it sounds like there are things i’m not considering due to not going through the whole process myself so maybe others could benefit from an eventual change.