Update samples for preview.3

[balachir]

WIP branch for updating samples to preview.3. Make changes and/or additions here as necessary.

Fixes #90

[DamianEdwards]

This won't pass the checks until preview.3 is released in its current state as it's not using the release feeds or a preview 8.0.200 SDK release. @balachir do you want to try updating the nuget.config to use the release feed and the global.json to point at the latest 8.0.200-preview SDK (8.0.200-preview.23624.5) for now to ensure this builds?

[DamianEdwards]

This won't pass the checks until preview.3 is released in its current state as it's not using the release feeds or a preview 8.0.200 SDK release. @balachir do you want to try updating the nuget.config to use the release feed and the global.json to point at the latest 8.0.200-preview SDK (8.0.200-preview.23624.5) for now to ensure this builds?

OK I ended up doing the above myself and now we can see what actually needs to be updated in this PR due to changes in preview.3

• Replace calls to WithServiceBinding with calls to WithEndpoint or WithHttpEndpoint
• Ensure library projects aren't referenced by AppHost projects, or if they're intended to be, update their metadata with IsAspireProjectResource="false"

[balachir]

@DamianEdwards thanks. I've made the changes that you suggested, and I can build successfully on my machine now.

[ReubenBond]

I believe this just needs the NuGet.config change reverted before merging

[ReubenBond]

Does this need to be updated?

[balachir]

Yes, I was wondering about it too. Should we set the version to 8.0.200 now that the SDK is available? I'm not sure if the build agent is using this 8.0.200-preview version.

[ReubenBond]

I think so, yes.

[ReubenBond]

I pushed a commit to update it

[balachir]

I believe this just needs the NuGet.config change reverted before merging

I've reverted the NuGet.config changes now.

[davidfowl]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[ReubenBond]

Do we need to add dotnet workload update && dotnet workload install aspire to the workflow yaml?

[DamianEdwards]

Do we need to add dotnet workload update && dotnet workload install aspire to the workflow yaml?

It's already in the build.sh

[DamianEdwards]

The failure repros locally, seems there's an issue generating the manifest for the Dapr sample.

[ReubenBond]

Ah, the issue is that the Dapr CLI is missing on the CI machine:

[ReubenBond]

I added a Dapr CLI installation step to the pipeline

[DamianEdwards]

@ReubenBond still failing

[ReubenBond]

Yeah, I wonder if the dapr integration isn't working on Windows (which is running first and cancelling the linux build) - I'll see if it works on Linux and we can hold off on merging for now

[ReubenBond]

Ok, that wasn't it. We get a different error on Linux. I tried updating to the latest DAPR CLI (the default from the action is very old). I assume it's still not finding the binary. I am trying to enable MS Build Structured Logs to the CI to see what the exact issue is now. We might end up needing to set the dapr/path env var manually

[ReubenBond]

Looking at our code now... did this ever work? The dapr hosting package in Aspire only looks in C:\dapr\dapr.exe on Windows. For Linux, it checks ~/dapr/dapr and /usr/local/bin/dapr. The setup-dapr task doesn't support selecting the installation directory (it outputs a dapr-path var).

I think we need to change the Aspire.Hosting.Dapr package to either check the PATH or allow specifying the Dapr installation directory via an env var. I opened dotnet/aspire#2219 to track.

[ReubenBond]

I'm tempted to say that we should either merge without CI or disable the Dapr sample from building in CI until dotnet/aspire#2219 is resolved and we have updated to a version with that (i.e, Aspire preview 4).
cc @philliphoff - perhaps you know how we might resolve this

[davidfowl]

Skip the tests for the dapr sample

[joperezr]

Looks like this is not updating all of the packages that were shipped yesterday, instead it is only updating the aspire ones. I can push another commit to make sure everything is up-to-date

[joperezr]

Looks like this is ready to go.

[philliphoff]

perhaps you know how we might resolve this

@ReubenBond An ugly way would be to set the DaprOptions.DaprPath value to the CLI path found in PATH in the application host when adding Dapr support in the sample. I've never looked at the GH Action before; I didn't realize it dumped it in a random directory. Agree that it could be useful to use what's found in PATH, if anything, before looking at other specific locations.