Only publisher and uacommander containers are running.

[digitaltwinconsortium]

Only publisher and uacommander containers are running.

[KingAlawaka]

I realized the issue was, BuildOutput was copied to the /app folder in the container, but .dll files are not in the right place. Inside the BuildAndRun.cmd file .dlls are trying to access directly inside the /app folder. But the correct folder is /app/bin/ so as a quick fix I manually copy-paste all the .dll files in the bin folder to the parent folder BuildOutput. However, it fixes the old issue but now I am facing a new issue

Since it's not working, I decided to change the paths in the BuildAndRun.cmd appropriately to access the .dlls. without moving them manually.
I change /app/Station.dll to /app/bin/Station.dll
However, now I'm getting an error like this.

Any thoughts about this?

[barnstee]

Let me try to repro on a clean machine.

[barnstee]

Can you send me the output of the dotnet --info command, please? Also, the build of the container should create a .\BuildOutput directory with the DLLs in there, not in /bin. ./Buildoutput is then mapped to /app within the container. Did you run the script from the .\FactorySimulation folder?

[KingAlawaka]

Sorry for the late reply.

This is the output of dotnet --info command

Yes, I run the script inside the .\FactorySimulation.
When building the project it is not building the DLLs inside the BuildOutput folder. It is created inside ./Buildoutput/bin
Because of this, I manually move the DLLs from the bin folder but still, it's not working.

Thank you very much for your support

[barnstee]

Thanks for the detailed steps. I managed to reproduce it and fixed it. Please try it out.

[barnstee]

Fixed with checkin 86f14d3

[KingAlawaka]

I will check this and let you know about it.
Thanks again for your support

[KingAlawaka]

I am still getting this error. Any thoughts?

When I stop the running containers, I see these containers are not attached to the network error. I am not sure whether it's related to this issue or because containers have not started correctly. Hope this helps too.

[barnstee]

The container not connected to network is simply a follow-on issue since they containers did not start. The assembly not found error appears to be a known issue with dotnetcore 2.1, see here: https://stackoverflow.com/questions/52028310/could-not-load-file-or-assembly-microsoft-aspnetcore-connections-abstractions. Upgrading to 2.1.5 appears to be fixing it. Can you try?

[KingAlawaka]

Can you please explain to me how can I do that?
because in the .csproj file .NetCore is 3.1.0

Thanks in advance

[barnstee]

Sorry man, I just realized that you had 3.1 already installed. I had another look and it turns out there was a conflict between the assemblies generated from the Azure Function "Pressure Relief" and the MES/Station project, even though they all use DotNetCore 3.1. I have moved the Pressure Relief project into its own solution (and folder) and now it is working for me. Please sync and try again. Sorry for taking so long to fix this.

[KingAlawaka]

Thank you very much for your kind support. Now it's working.
The moving Pressure Relief function did the trick.
I also sent you an email.
Thanks again