Why does deploying chaincode in hyperledger not work? - hyperledger-fabric

Question

I am working on the hyperledger fabric v2.0 and after I have set up the network, created the channels I am not able to set the chaincode.
The Linux command: ./network.sh deployCC was not working.
So it says i should use the ollowing valid call example:
./network.sh deployCC -ccn basic -ccp ../asset-transfer-basic/chaincode-go -ccl go
If I use this command, I recieve the following error:
Error: failed to normalize chaincode path: 'go list' failed with: go: inconsistent vendoring in /home/akosua/fabric-samples/asset-transfer-basic/chaincode-go:
github.com/golang/protobuf#v1.3.2: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
github.com/hyperledger/fabric-chaincode-go#v0.0.0-20200424173110-d7076418f212: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
github.com/hyperledger/fabric-contract-api-go#v1.1.0: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
github.com/hyperledger/fabric-protos-go#v0.0.0-20200424173316-dd554ba3746e: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
github.com/stretchr/testify#v1.5.1: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
run 'go mod vendor' to sync, or use -mod=mod or -mod=readonly to ignore the vendor directory: exit status 1
Chaincode packaging has failed
Deploying chaincode failed
I updated the current golang (v1.15)
Thank you for helping me!

Answer 1

After I reproduced your situation, I solved it through the method below.
To install the smart contract dependencies, run the following command
fabric-docs/chaincode
cd $GOPATH/src/github.com/hyperledger/fabric-samples
cd asset-transfer-basic/chaincode-go && \
GO111MODULE=on go mod vendor
run deployCC command in test-network
cd test-network && \
./network.sh deployCC -ccn basic -ccp ../asset-transfer-basic/chaincode-go -ccl go
[EDIT]
After checking your answer, I reproduced your situation again. I wrote the order as it was.
first assumtion
1-1. I thought that apt update had no effect at all, and it was solved by deleting the previously incorrectly created/installed file from ./network.sh down.
1-2. Therefore, after installing the wrong vendor, I artificially executed and executed the command, and produced the same error.
1-3. However, in the ./network.sh down command, the vendor was not cleared, and in the up command, the method suggested in the above answer was executed in the script.
1-4. The error was not resolved, and I had to find another problem.
The other assumption
While analyzing the ./network.sh down script, it was confirmed that the docker volume was cleared.
It was assumed that the problem occurred because a package containing the wrong vendor remained on the docker volume.
2-1. As in the initial assumption, the deployCC command was executed based on the wrong vendor.
2-2. After the same error occurred, the network was shut down without clearing the volume of the docker network.
2-3. After replacing the chaincode with the correct vendor, reloading the network, and executing the deployCC command.
2-4. The same error occurred, and the remaining volume was confirmed to have an effect.
2-5. The entire network was evaporated through the -v option. In addition, all unnecessary volumes were evaporated through the docker volume prune.
2-6. After that, the network was reloaded and the deployCC command was executed, and it was confirmed that it was working normally.
In other words, the file related to the previous wrong chaincode remained in the dokcer volume, and it seems to have been resolved as it was deleted by a script that evaporates the volume in ./network.sh down together.
docker rm -f $(docker ps -aq) # This is a dangerous command because all containers are erased.
docker volume prune

Answer 2

I found my mistake/solution now.
First I checked for updates again: sudo apt update
Then I put the network down and up:
./network.sh down and than open it again by ./network.sh up
Afterwards I could continue without errors