Neo: Use neo, neo-vm, neo-plugins and neo-cli in a single solution? (With multiple projects inside)

[lock9]

Hello,

It would be easier to develop new features and test neo if neo and neo-cli belonged to the same solution.
I don't think nuget package is the best way to improve the project "as fast as we need to" because it's not possible to debug a project if it's a nuget dependency. Also, if we open neo solution (without neo-cli) and try to find usages of some methods, it won't find any, but they are being used in neo-cli.

I'm setting up a test environment for NEO (startup blockchain from zero and making it easy to update the source code), but the current state of the dotnet solution makes it very, very hard to update and manage.

Is there any chance we could use a single solution, with neo-cli being one of its projects? ... please?

[lock9]

If anyone is interested, this is how NeoResearch replaces the reference in the project:
https://github.com/NeoResearch/neo-tests/blob/master/docker-build-neo-cli/Dockerfile
```BASH

remove neo blockchain package from neo-cli project, referencing it to the the docker local neo

RUN dotnet remove /opt/neo-cli/neo-cli/neo-cli.csproj package neo
RUN dotnet sln /opt/neo-cli/neo-cli.sln add /opt/neoLib/neo/neo.csproj
RUN dotnet add /opt/neo-cli/neo-cli/neo-cli.csproj reference /opt/neoLib/neo/neo.csproj ```

[lock9]

Hello,
I think these are the benefits of joining the projects into single solution:

• It's easier to clone and run the project;
• It's easier to debug;
• It's easier to update the code;
• It's easier to add new projects to the ecosystem;

Cons:

• Its easier to keep track of versions using a nuget package. My suggestion: use branchs/tags instead.

[lock9]

@neo-project/core Can we have a branch for this?

A branch where we have a solution using git-submodules instead of nuget packages?

1 - We need to ensure it's version compatibility, today the versions are completely detached. If someone changes something in neo, they have no idea of the side effects in neo-cli or other, so, what happens in practice, is that the person who "fixes" neo-cli usually have no background on what they are fixing, and the person who broke it, have no idea that it was their fault that it broke.

2 - I'm sure we will have a better efficiency if the person who changes neo also changes neo-cli, or at least provide basic guidance. I believe people don't do that because they simply don't know that the project broke (not always possible, but when possible, recommended)

3 - This drastically improves how new developers understand the project since it is very hard to see all the pieces. We have new core developers joining our team and we need a way to make them see all pieces "talking to each other".

This branch won't hurt your eyes in the branch list!
If you guys are against, please tell me how do you debug all source codes together. I replace project references weekly and this is starting to hurt my brain :(

[shargon]

I hate git-submodules :P

[lock9]

@shargon but are you "against" me creating a branch for this?
@shargon how do you run them together using source code? Please, this branch won't hurt you.
Can I consider you "neutral"? 😆

[shargon]

We can do it, but this branch need to be maintained. In which project is better, neo-cli?

[lock9]

@shargon I think the best is to use it here. I understand that neo is a dependency of neo-cli, but neo is where the hard work is done. Is where the changes start and need to be adapted.
I think this should be in our main project, and I think this is the main project.
I understand the "dependency" relationship, but I don't think that is this that matters now, we want a better development experience, I don't see why care about the "relationship direction" in this case.

[lock9]

I'm closing this in favor of #727