Currently, to convert a UInt160 value to a string you can use with facilities like Runtime.Log(), you have to do this bit of trickery (thank you @hal0x2328):

StdLib.Base58CheckEncode("5" + (ByteString) value))

Where value is a UInt1601 value. I suggest making a ToString()method for theUInt160` type so that it is easily discoverable by NEO developers.

When PrefetchAsync calls DownloadStateAsync the states are currently not committed to the snapshot.

StateServiceStore #L464

Fix ContractParameterParser see neo-project/neo-express#285

from the looks of it

only is getting string value or get it as json object

maybe update documentation is key here?

Back when i last developed in C# as part of a team (admittedly a long time ago now) there was tool called StyleCop, and it was pretty common to enable it and enforce the default rules regardless of opinions of individual team members (consistency over personal preference). It seems like StyleCop is now replaced by Roslyn Analyzers (which I cannot claim to have any experience with).

i think the main issues that old-school StyleCop would have found in the neo-express code base are catching Exception and lack of { and } on one line conditionals.

This issue is intended to encourage a discussion that leaves us confident that we're following current-day norms and best practices for C# development - please don't see it as me trying to force my personal preferences on the code base :)

StateService does not track Ledger contract items (blocks and transactions) since they are already immutable.
StateServiceStore translates requests for such K/V pairs into a call to getstorage. If the storage key doesn't
exist, RpcServer returns an error with code -100. StateServiceStore fails to catch this error.

https://learn.microsoft.com/en-us/dotnet/core/compatibility/sdk/7.0/solution-level-output-no-longer-valid

I've got a branch where I'm working on updates to invoke file parsing. As part of this work, should we consider updates to the .neo-invoke file format?

Today, the ContractParameterParser class parses one or more objects that map to ScriptBuilder.EmitDynamicCall. The object properties map to the EmitDynamicCall parameters

• contract property is parsed into the UInt160 contract script hash
• operation property is a string that indicates the operation to invoke
• args property is an optional array of JSON values that are parsed into a ContractParameters

Other information that could be added to the invoke file

• CallFlags: If not provided, EmitDynamicCall defaults to CallFlags.All. Should we add a call-flags field to the dynamic call JSON object?
• Signers: Today, NeoExpress generates a single signer for an invocation via the Account argument and WitnessScope option. However, this is only a fraction of transaction signing flexibility
  • a transaction can have multiple signers
  • a signer must have an account hash and WitnessScope, but also supports allowed contracts, allowed groups and witness rules. Today, express has no mechanism to allow the developer to specify this additional signer information.
• TransactionAttribute: Transactions can have zero or more attributes. Today, there are only two defined attributes: HighPriority and OracleResponse. Express already has an oracle response command, so there shouldn't be any need to specify this directly. HighPriority is used for ordering transactions in the mem pool, so is conceivably interesting. However, HighPriority transactions MUST be signed by the NEO committee, so they are of limited use by rank-and-file developers.
• Additional GAS fees: transactions in the mempool are ordered by FeePerByte and then NetworkFee, thus there are scenarios for increasing the network fee paid for preferential mempool ordering. However, since neo express runs locally, there aren't typically a large number of transactions in the mempool, so it's not clear how much use this would be.
  • Note, express contract invoke has an --additional-gas argument, but that adds to SystemFee not NetworkFee. This is actually a hold over from Neo N3 beta timeframe where there were bugs in the system fee calculation engine. This argument should probably be deprecated

IMO, we should consider providing a mechanism to encode complete singer information in JSON for use in invoke file scenarios. I'm actually thinking this should be a separate file (.neo-signers maybe?). The current invoke file mirrors invocation script generation so adding signer information would break some backwards compatibility. Additionally, a separate file would enable use in contract run command as well as contract invoke.

We should also add CallFlags property to the dynamic call object. It's not used often, but it's also fairly easy to add. Unlike other properties like account and contract, parsing a CallFlags string -> enum value is straightforward and requires no outside information

nccs RC2 has a known issue where it emits negative numbers as an invalid document index for sequence points in certain scenarios.

While it has been fixed post RC2, this leads to a poor developer experience for RC2. If we update the debug info parser + debugger to ignore these invalid values, we can have a better developer experience for the hackathon

IStorageProvider is specific to node plugins, so it doesn't belong in lib-bctk.

debug info format adding static variables in format v1.2

StateServiceStore has a map of internal contract ID (int32) to contract hash (UInt160) generated from the contracts that were deployed at the point where the state service store branch was created. If a contract is deployed to a chain backed by StateServiceStore, TryGet and Seek methods throw an exception because the newly generated contract ID is not in the contract map.