*.nef files not found in the current workspace

[gsmachado]

Hello @devhawk @djnicholson

I have a Golang workspace, where I create a token.go file, which is a smart contract. I compiled this smart contract in the workspace, and a token.nef file was the output:

Then, after initializing the neo-express and stuff, I tried to deploy the contract like this:

Then, this message immediately appeared:

I believe this is a bug since I clearly have at least one .nef file in my vscode workspace.

[gsmachado]

ah... I don't know if that's a completely new feature or not, but it would be AWESOME to add the "Deploy contract" menu to the menu context of *.nef files.

Like, adding "Deploy contract" here:

[djnicholson]

I think the problem is that there is no metadata file (and the text of the error message is a bit misleading!)

Adding a right click option for .nef will be possible (I'll still have to make it emit an error if the metadata cannot be found, though)

[gsmachado]

I think the problem is that there is no metadata file (and the text of the error message is a bit misleading!)

hmmm... got it. So, what's the file extension the vscode extension is looking for to detect the "metadata" (file manifest/ABI)?

And, most importantly: how does the vscode extensions associate that a metadata file belongs to a particular .nef file? (given the fact that a workspace could contain multiple compiled smart contracts (.nef's))

Adding a right click option for .nef will be possible (I'll still have to make it emit an error if the metadata cannot be found, though)

Looking forward to it! 💯 👍

[devhawk]

NEON produces four files - .nef, .manifest.json, .abi.json and .nefdbgnfo. They are all generated in the same folder as the source DLL or project file resides and all have the same base file name. i.e. mycontract.dll generates mycontract.nef, mycontract.manifest.json, mycontract.nefdbgnfo and mycontract.abi.json.

The NEF and manifest files are required for deployment. nefdbgnfo is used by the debugger. abi.json is redundant in NEO 3 - that information is duplicated in the manifest file.

[gsmachado]

@devhawk alright, neow3j outputs these files.

But it seems that some of the SDKs/compilers in the community does not follow this.

Do you think that we could write a small "standard" (NEP) for this? Or even, include this information to NEP-14 and NEP-15. I could try to propose this, since it gets clear to interoperability of tools at a higher level (e.g., vs code extensions, etc).

[devhawk]

There's already a neo proposal for the contract manifest: neo-project/proposals#114

[gsmachado]

NEON produces four files - .nef, .manifest.json, .abi.json and .nefdbgnfo. They are all generated in the same folder as the source DLL or project file resides and all have the same base file name. i.e. mycontract.dll generates mycontract.nef, mycontract.manifest.json, mycontract.nefdbgnfo and mycontract.abi.json.

@devhawk I don't see anywhere written that files should be named ".manifest.json" or ".nefdbgnfo.json", or "*.abi.json" in this proposal, though.

Again, just because NEON produces those files and that neo3-visual-tracker searches for those specific file name patterns doesn't mean that at the moment all compilers do the same. That's what I was referring to.

However, if neo3-visual-tracker get smart enough to detect those manifests based on file content, well, then it's a different story. Then compilers/developers could output any filename they want (by default). But, this is not an optimum solution IMHO (very time consuming, not scalable, etc etc) and should not be pursued for now.

I would prefer simply to "standardize" that, somewhere, and make compilers aware that those names should be produced by default. 😄

[devhawk]

@devhawk I don't see anywhere written that files should be named ".manifest.json" or ".nefdbgnfo.json", or "*.abi.json" in this proposal, though.

Good point @gsmachado regarding .manifest.json file extension. File extension for debug info however is specified in NDX-DN11. And the .abi.json file is not used at all in neo 3, so we can safely ignore that file.

Technically, from the platform perspective, only the file contents of the contract binary and manifest matter - the platform doesn't store them in the file system with an extension anyway. However, for the sake of tooling, it seems we should include some text in both the NEF and manfest NEPs that specify file extension naming conventions when this content is stored in a file system.

You want to open the issues or should I @gsmachado ?

[gsmachado]

@devhawk I initiated the discussion and Erik included in the NEP. 👍 😄

[gsmachado]

aaaaaand, it was also included in this NEP. 🚀

[gsmachado]

@djnicholson you can assign this issue to me. I will test your last commits and I will come here to close the issue if that's the case, thanks.

[gsmachado]

I forgot to close this issue. My fault.

I tested and it's fine. Closing. 💪