Add documentation on how to build the dotnet-sdk with local dapr build

[yash-nisar]

Describe the proposal

Sometimes, developers might want to work on features that haven't been released yet. In that case some documentation on how to build the dotnet sdk with the local dapr build would be helpful.

e.g.
Under the dapr/dapr repository, do make build and then replace the daprd daemon on your local machine with the newly built one under dist.

[halspang]

@yash-nisar - Since this is an SDK, they just need to include it in their code when they build it. I think as .NET developers, people would be fairly confident in how to do that. Are you looking for something more than that?

[yash-nisar]

Apart from including it in their code, they would also need to replace the binary with the one they've built locally right ? For someone who is new to both go and dotnet, a short paragraph indicating the steps would save some time. Thoughts ?

[halspang]

@yash-nisar - You only need a new binary if you're developing dapr as well. In that case, the documentation should go in the dapr/dapr repo. What do you think?

[yash-nisar]

@halspang In the case where a developer is working on an unreleased feature in the dapr runtime and wants to test it with the dotnet sdk, we might want dotnet sdk to point to the local binary. In that case, I feel we need to mention it here.

[WhitWaldo]

@yash-nisar Increasingly, I've been working to produce RCs of anything that's (tentatively) completed in the repository, but not yet tied to a specific GA release precisely to avoid having to have developers have to create their own builds.

That said, should you need to build anything locally, you need only run dotnet build in the project directory and it should work fine from nothing but a simple git clone.

I'm going to close this issue as there's some information about this here but again, there's nothing inherently special that needs doing in this repository versus any other .NET project to produce a package you can use in other projects (except, of course, barring the convenience of packages installed via NuGet).