Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C# AddressBook example and/or documentation not adequate to get started with version 3.5.1 #4119

Closed
dchennells opened this issue Dec 31, 2017 · 5 comments

Comments

@dchennells
Copy link
Contributor

dchennells commented Dec 31, 2017

Steps to repro:

  1. Download current version 3.5.1 and open Google.Protobuf.sln in VS2017 v15.x (I used 15.4).
  2. Set a breakpoint on line 52 of AddressBook Program.cs.
  3. Rebuild all from within the IDE.
  4. Run in the IDE (F5)

Results:
A. Builds okay.
B. After F5 run, a brief (<100 ms) screen flash appears of a console window opening and closing.
C. Nothing on the Debug output pane.
D. No errors.
E. Breakpoint not hit.

Expected result:
Hitting the breakpoint if set or alternatively have the console window appear and stay up.

Documentation consulted:

  • The CSharp tutorial references the AddressBook project and says that the example is "complete" within the "csharp/src/AddressBook directory of the GitHub repository".
  • The ReadMe.md file in the csharp root talks about building the Google.Protobuf.sln but does not refer to any known issues in running (debugging) with the default startup project of AddressBook and configured Startup object.
  • The examples ReadMe at https://github.com/google/protobuf/tree/master/examples speaks about using Bazel, but the actual Build and Workspace files in the examples folder does not have a section pertaining to C#

I'm sure I'm missing something obvious. Is running the csharp example in VS2017 a supported scenario? I have not yet tried to create a replacement AddressBook2 project using alternative dependencies such as the full framework or NET Core 2.04.

Happy to pitch-in in getting the csharp example up and running or in improving the docs if someone can provide some initial guidance as to any known issues.

UPDATE - FURTHER OBSERVATIONS 1/2/2018:

  1. I performed a clean re-installation of VS2017 to 15.5.2 to confirm that the problem persists with the latest version of the tooling. AddressBook does not run, at least not in the IDE in debug mode.
  2. I attempted to migrate the AddressBook project as provided in 3.5.1 to NETCore 2.0 but found that the path of least resistance is to use File-New in VS2017 to create a replacement project in a new solution and then migrate the other existing constituent projects. Having done that, the AddressBook example runs okay targeting .NET Core 2.0.
  3. Alternatively, I note that it is possible within the existing solution to create a full framework version of AddressBook that runs okay.

I would be happy to prepare a pull-request based on number 2 (above) to get the AddressBook project working and simultaneously migrate it to NETCore 2.0, a far more viable framework in any case. I will be on holiday from mid-January, so please let me know sooner rather than later if this would be useful, (@jskeet).

@jskeet
Copy link
Contributor

jskeet commented Jan 2, 2018

I can't reproduce this, I'm afraid.

I've just downloaded the 3.5.1 zip file, opened the solution file in VS 15.5.1 and run the AddressBook sample and it came up with a prompt as expected.

What happens if you try to run the app from an open command line window instead?

Have you tried setting a break point at the very start of Main instead of on line 52?

@dchennells
Copy link
Contributor Author

dchennells commented Jan 2, 2018

Thanks for your immediate reply, @jskeet. Your affirmation that it worked in your environment encouraged me to look closely at the tools. Turns out that post-.Net-Core-2.0 releases of VS2017 require opting in to support the earlier versions of that framework, and under a somewhat misleadingly narrow label. There is no backward compatibility support within the IDE by the .NET Core 2.0 bits. (Perhaps the VS team wishes to turn the page on their 1.x alpha-like tooling support for .Net Core as quickly as possible.)

vs2017 configuration

It might be worth highlighting this in the ReadMe.md for the C# solution, where you say,

"Although users of this project are only expected to have Visual Studio 2012 or later, developers of the library are required to have Visual Studio 2017 or later, as the library uses C# 6 features in its implementation, as well as the new Visual Studio 2017 csproj format."

For example, you could add the sentence:

"In addition, in order to run and debug the AddressBook example in the IDE, you must install the optional component ".Net Core 1.0 - 1.1 development tools for Web" (as it's labelled in current versions of the VS2017 installer), above and beyond the main .NET Core cross-platform development feature."

Incidentally, my offer remains open to assist with the migration of the AddressBook project to .Net Core 2.x once the time comes. I would also be interested in evaluating/testing the relevance of the new memory buffer-oriented C# 7.2 bits to the core code in the C# version of the Google.Protobuf itself. Would it make sense to open that as a separate issue or is that ultra low priority at the moment?

@jskeet
Copy link
Contributor

jskeet commented Jan 2, 2018

Re: Span: there's already a feature request for it: #3431

Your readme suggestion sounds good to me - if you could file a PR for that, it would be good.

"Migrating" the AddressBook project to .NET Core 2.x would be a single character change: in AddressBook.csproj, just change netcoreapp1.0 to netcoreapp2.0. I'd expect that to work with no other changes - from VS2017. However, I believe our CI systems etc are still using the 1.0 SDK. Updating to use the 2.0 SDK would require a non-trivial amount of work in my experience, as we'd still need to also install the 1.0 runtime in order to run 1.0-based tests.

@dchennells
Copy link
Contributor Author

Thanks for your support with that minor edit to the ReadMe @jskeet, which appears to be on its way. I'll close this issue as soon as a change is completed.

On the one-character migration (!): that seems like the reasonable expectation. Hopefully the VS tools will support that path by the time it makes sense for protobuf to make the upgrade.

Regarding C# 7.2, I've followed up with a brief note on the feature request discussion you linked to see when (and whether) there would be value in moving forward with that.

@xfxyjwf
Copy link
Contributor

xfxyjwf commented Jun 25, 2018

ok to close this issue now? The linked PR was merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants