VS fails to build todo sample

[vyta]

Followed steps to set up dev environment and to debug locally (https://docs.microsoft.com/en-us/azure/service-fabric-mesh/service-fabric-mesh-tutorial-debug-service-fabric-mesh-app), fails with "There were build errors" window, but no errors in errors list.

[vipul-modi]

If you open the following solution, does it build? https://github.com/Azure-Samples/service-fabric-mesh/tree/master/src/counter/src

[vyta]

Getting the same thing for the counter app

[vipul-modi]

The output has multiple sources, check the output of Service Fabric Tools or other sources. @dbreshears

[sgreenmsft]

You can increase the build output verbosity by going to Tools > Options > Projects and Solutions > Build and Run, and modify the MSBuild project build output verbosity to Detailed. This should provide additional information about the build process that will help diagnose what's going wrong.

[sgreenmsft]

One common issue is for port conflicts to prevent a service from starting. That is, two applications could attempt to allocate port 20006 or 20008 (the ports used by todolistapp). You can use the Service Fabric Local Cluster Manager to ensure that no running SF Applications are using either of those ports before attempting to F5 todolistapp.

[littlenetcoder]

I was also facing docker file build issue, But after setup MSBuild project build output verbosity to Detailed, I saw unauthorized error for downloading image from docker hub repository. Once i logged into my docker hub account using power shell - docker login. I am able to run samples successfully. This might help.

[tbertenshaw]

another thing to check is if you are running the samples on windows 2016 then the docker images are incompatible. You cannot run microsoft/aspnetcore:2.0-nanoserver-1709 on 2016. This manifests itself with a reexec error in the servicefabric tools panel when its pulling the docker images

[tbertenshaw]

@ChackDan submitted a pr which hopefully will resolve this issue. https://github.com/Azure-Samples/service-fabric-mesh/pull/17

[ChackDan]

Thankyou @tbertenshaw. @vyta - can you try this fix.

Personally, I think we may still need a sample using nanoserver. That could be a nother version you publish.

[tbertenshaw]

Could submit one with a generic nanoserver image

On 20 Jul 2018 17:23, Chacko Daniel notifications@github.com wrote:

Thankyou @tbertenshawhttps://github.com/tbertenshaw. @vytahttps://github.com/vyta - can you try this fix.

Personally, I think we may still need a sample using nanoserver. That could be a nother version you publish.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Azure/service-fabric-mesh-preview/issues/232#issuecomment-406651715, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AB6rkmPEz6TuxVpx6pPbo2XcpAhQrU2Gks5uIgPzgaJpZM4VTftJ.

[BigMorty]

@vyta - Any update on getting the samples to work?

[vyta]

I still am unable to build/debug the counter service in VS. I can build and run the service outside of vs, docker build/run and it works., but I cannot docker run the image that was built by VS

[BigMorty]

Have you increased the build output verbosity to 'Detailed' as @sgreenmsft suggested above? Do you see anything actionable? If you are OK with sharing the output from the various Output windows in Visual Studio you can do that as well. You can email them to me at mike.morton@microsoft.com.

By the way, you will not be able to 'docker run' the image built by Visual Studio, it does not have everything that is required. We dynamically map assemblies into the image during debugging to keep the F5 time to a minimum.

[vyta]

Uninstalling everything, including the Service Fabric runtime and reinstalling worked. I didn’t uninstall the runtime last time, so that might have been the fix.

[vyta]

closing

[codeputer]

So I found the problem on my machine, but I'm not sure if it's everybody problem - as I'm new to Docker... the DNS resolution failed on ToDoServiceName entry in the web front end. The value "todoservice" would not resolve to the external IP address of the docker container - which in my case was 192.168.1.64. I found this by dumping the network of the docker image after it started, and I changed the todoservcename to the IP address. which results in http://192.168.1.64:20008/api/todo and it worked.

not sure if a DNS entry is suppose to be made in the localhost file, or how it is expected that the todoservice entry is to translate to the external IP address of the docker container - would be nice to know … it works now but if that address changes …..