NeoVM integration

[lock9]

I am migrating the NeoVM project into the Neo repository.

Note: I've removed .NET Core 3.1 support from Neo VM. I don't see any reason to keep it, and it was breaking the build.

Related to #2972

[Jim8y]

@roman-khimov may you please take a look, i think your extraordinary experience in maintaining the monorepo neogo would be very helpful here.

[shargon]

@lock9 we need to modify the workflow in order to test Neo.VM at the same time

[roman-khimov]

C# packages/modules/projects/whatever are very different from Go packages, so it's hard for me to say anything here. IIUC it'll still be a separate dll (project?), but that should be OK if it has the appropriate code from the latest VM, builds, passes tests and all other components are using it instead of referencing the old repo.

[cschuchardt88]

@lock9 please look at https://github.com/neo-project/neo/blob/master/src/Directory.Build.props and remove those properties from the *.csproj file

Edit:
But keep this line <TargetFrameworks>netstandard2.1;net7.0</TargetFrameworks>

[cschuchardt88]

@Liaojinghui @shargon @roman-khimov Make a note that github actions has to add netstandard2.1 build for neo.vm. On pack or least it may not work, only work with dotnet 7.0

[lock9]

@lock9 we need to modify the workflow in order to test Neo.VM at the same time

It already does:

[cschuchardt88]

is neo-vm building for standard2.1? just check the nuget package to make sure that its not overriding the target framework ( from Directory.Build.props)

[roman-khimov]

@lock9, I think it's a bit more accurate this way. Deal with VM here, then take another (neo-node) repo, then another (modules, oh those modules...) and then we'll get whole #2944 done in a few steps.

[lock9]

Agreed. The previous name wasn't good

[shargon]

I have verified that the code has been ported without being modified except for the references, compiles, passes the unit tests and for my part it can be merged.

[Jim8y]

I think it is good to go, @shargon. But i also suggest to move submoules out of src to the root folder, if we agree on this, can be done after we complete the monorepo. And can you please archive the neo-vm repo, unpin it from the project and pin neo-express instead.

[shargon]

I think it is good to go, @shargon. But i also suggest to move submoules out of src to the root folder, if we agree on this, can be done after we complete the monorepo. And can you please archive the neo-vm repo, unpin it from the project and pin neo-express instead.

Out src why?

[Jim8y]

Out src why?

Not very serious reason, just make the the structure more clear. Just mention it, can ignore this if not agree.

[AnnaShaleva]

LGTM.

And another question from my side: starting from this PR NeoVM tests are being run by GitHub action's Test job the same as the rest of the Neo tests on every PR, right?

Oh, I see the #2970 (comment), so it's OK.

[AnnaShaleva]

Just a question: why the <Copyright>, <Description>, <LangVersion> and other description tags were removed? It is still a separate project, it would be nice to have some description metadata for it.

[lock9]

This was the previous content. I don't think there is a lot to reuse. The older description was just "Neo virtual machine":

<PropertyGroup>
    <Copyright>2016-2023 The Neo Project</Copyright>
    <Description>Neo virtual machine</Description>
    <VersionPrefix>3.6.2</VersionPrefix>
    <Authors>The Neo Project</Authors>
    <TargetFrameworks>netstandard2.1;net7.0</TargetFrameworks>
    <LangVersion>9.0</LangVersion>
    <PackageTags>NEO;AntShares;Blockchain;Smart Contract;VM</PackageTags>
    <PackageProjectUrl>https://github.com/neo-project/neo-vm</PackageProjectUrl>
    <PackageLicenseExpression>MIT</PackageLicenseExpression>
    <RepositoryType>git</RepositoryType>
    <RepositoryUrl>https://github.com/neo-project/neo-vm.git</RepositoryUrl>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
    <Nullable>enable</Nullable>
    <GenerateDocumentationFile>true</GenerateDocumentationFile>
  </PropertyGroup>

[AnnaShaleva]

The older description was just

At least there was some description, so it would be nice to port it. As far as Copyright, Authors and package-related tags (we can change the PackageProjectUrl to https://github.com/neo-project/neo. VM is still a separate package, isn't it?

[lock9]

The other packages don't have this information. I'm not against adding it, but I could argue that this may be done separately and to all the packages. None of the other projects have their own description or custom details.

Example:

Neo JSON:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <PackageTags>NEO;JSON</PackageTags>
  </PropertyGroup>

</Project>

RPC Server:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <PackageId>Neo.Plugins.RpcServer</PackageId>
    <RootNamespace>Neo.Plugins</RootNamespace>
  </PropertyGroup>

</Project>

Neo Modules projects inherit the configuration from this file:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>
    <VersionPrefix>3.6.2</VersionPrefix>
    <TargetFramework>net7.0</TargetFramework>
    <RootNamespace>Neo.Plugins</RootNamespace>
    <Authors>The Neo Project</Authors>
    <PackageTags>NEO;Blockchain</PackageTags>
    <PackageProjectUrl>https://github.com/neo-project/neo-modules</PackageProjectUrl>
    <PackageLicenseExpression>MIT</PackageLicenseExpression>
    <RepositoryType>git</RepositoryType>
    <RepositoryUrl>https://github.com/neo-project/neo-modules.git</RepositoryUrl>
  </PropertyGroup>

  <ItemGroup>
    <None Include="config.json" Condition="Exists('config.json') And '$(IncludeSettingsFileOutput)' != 'False'">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
    </None>
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Neo" Version="3.6.2" />
  </ItemGroup>

</Project>

[AnnaShaleva]

Good, let's just leave it as is, resolved.

[lock9]

Not very serious reason, just make the the structure more clear. Just mention it, can ignore this if not agree.

Could we discuss this in another issue? I like the way it is today

[Jim8y]

@AnnaShaleva lets focus on functionalities. minor issues can be skipped for now and fixed later in another pr.

[Jim8y]

@shargon may you please check, review, and merge?

[shargon]

@shargon may you please check, review, and merge?

No more commits from my last review, we can merge if @roman-khimov approve

[Jim8y]

@roman-khimov please check and review

[shargon]

I will transfer the issues from neo-vm and archive the neo-vm repository after merge this PR

[roman-khimov]

I've also checked that it's the same 3.6.2 VM in d315686 (just *.csproj changes). We've also discussed #2971, there is a solution.

Good to go!

[shargon]

@lock9 “That’s one small step for man, one giant leap for mankind”.

[shargon]

@lock9 take a look to the workflow please

Error: /home/runner/.dotnet/sdk/7.0.404/Sdks/NuGet.Build.Tasks.Pack/build/NuGet.Build.Tasks.Pack.targets(221,5): error NU5026: The file '/home/runner/work/neo/neo/src/Neo.VM/bin/Debug/netstandard2.1/Neo.VM.dll' to be packed was not found on disk. [/home/runner/work/neo/neo/src/Neo.VM/Neo.VM.csproj::TargetFramework=net7.0]

[Jim8y]

@lock9 take a look to the workflow please

Error: /home/runner/.dotnet/sdk/7.0.404/Sdks/NuGet.Build.Tasks.Pack/build/NuGet.Build.Tasks.Pack.targets(221,5): error NU5026: The file '/home/runner/work/neo/neo/src/Neo.VM/bin/Debug/netstandard2.1/Neo.VM.dll' to be packed was not found on disk. [/home/runner/work/neo/neo/src/Neo.VM/Neo.VM.csproj::TargetFramework=net7.0]

Because of this?

<TargetFrameworks>netstandard2.1;net7.0</TargetFrameworks>

[lock9]

Afaik, .NET Standard is just a 'common interface' in .NET. I'll check what is causing the build to break. I don't think it's even possible to make a DLL from .NET Standard Libraries (I'm not sure). I'll check & update the workflow file to fix it.

[lock9]

There were two problems. The dll wasn't being generated but that was a bug caused by conflicting properties.

Fixed by #2989