[C#][ASP.NET CORE] upgrade generated files to support Visual Studio 2017 format

[seven1986]

update aspnetcore template to newest, can use vs2017 run it

[wing328]

@seven1986 instead of providing Chinese instruction, what about using English instead?

I can read simplified Chinese but I believe our users would prefer English :)

[seven1986]

OK, no problem, thanks 👍

[wing328]

@seven1986 thanks for the PR.

I notice some changes such as removal of "sourceFolder", would these change still good for developers using Visual Studio 2015?

cc @jimschubert

[jimschubert]

This change is a hard upgrade to VS2017 format, and will break all previous users (including those not on Windows).

I think the change should be behind a flag and conditionally apply the new changes. The sourceFolder will be a breaking change, as will the changes to the solution file and project files.

[wing328]

I think the change should be behind a flag and conditionally apply the new changes. The sourceFolder will be a breaking change, as will the changes to the solution file and project files.

@jimschubert Agree. What about supportVS2017?

[jimschubert]

@wing328 I would prefer something like vs2017structure (project, format, etc).

supportVS2017 could be misunderstood as the project not being able to be opened by developers with the newer IDE without that flag. Plus, when newer versions of Visual Studio come out, we're still only creating the project and solution with additional files as created by VS2017. I'm assuming VS2019 will still be able to open it.

I think the nuance is that "support" sounds like it is related to generated code features, while others like "project", "format", "structure", etc. sound more related to supporting files to me.

[seven1986]

@wing328 @jimschubert As a c# developer, I think visual studio will let c# developers know the version changing and benefits(such as the version from 1.0,1.1,2.0), then we go forward ,keep the newest version about server stub and client template.

Could be add a flag to keep every template, for now and feature users
how about : -vs --visual studio 2015/2017 default is 2017

That what I think

[jimschubert]

@seven1986 I don't understand your comment about VS providing hints about the benefits of future versions. VS2015 won't open a VS2017 file, so that can't yet be the default.

Also, the switches would be passed as

--additional-properties=vs=2017

or whatever. It wouldn't make sense to create global switches on swagger-codegen for Visual Studio because most of the languages aren't supported by Visual Studio.

In another point, I don't think visualStudio alone makes sense because many non-Windows developers prefer Xamarin or Rider.

[seven1986]

Hi @jimschubert , sorry for my english.
It is perrty good add a swiche as you say , really agree with you!

--additional-properties=vs=2017

vs2017 can open vs2015 template, but need to convert them.
From my opnion, I think we always providing the newest officail aspnetcore template would be berter, if you want the old , use swiche to get them, just backward compatibility

the benefits I don't know, but the official will make everyone know exactly, that is enough, we just keep the newest official template

[wing328]

@seven1986 my take is to keep vs2015 as the default. This is not to say vs2017 is bad. Just that it was just launched recently and my guess is that our developers are still using vs2015.

In 2.3.0, we will consider making vs2017 as the default if there are enough demand to make the switch.

[jimschubert]

@seven1986 I see what you're saying. For a server generator, I agree it's not that big of a deal.

However, for client generators we have to stick with VS2015 and opt-in to future structure. Like I said, for aspnetcore it could make sense to say it's the latest only. But for the clients, our users may generate against master and it would be confusing to generate clients that support VS2015 in one build followed by a forced VS2017 in the following build. It would be confusing for us maintainers of the C# client(s) and aspnetcore server to have one go VS2015->VS2017 and the other go VS2017->VS2015 via options. We usually side on opt-in for newer code for consistency with other generators and to avoid confusion for the larger user base.

I hope that clarifies my comment a bit more.

[kraihn]

With the release of .NET Core 2.0 MS set the IDE minimum to VS2017. What if instead of specifying which version of VS to use, we allow setting the .NET Core version?

--additional-properties=version=1.0
--additional-properties=version=1.1
--additional-properties=version=2.0

The runtime download page shows both a current and LTS version. The version you specify generates project definitions that work with the minimum version IDE. The default can be kept at the LTS version to prevent users from upgrading all the time.

https://www.microsoft.com/net/download/core#/runtime

[wing328]

@kraihn instead of using version in additional properties, what about using targetFramework instead?

	targetFramework
	    The target .NET framework version. (Default: v4.5)
	        v3.5 - .NET Framework 3.5 compatible
	        v4.5 - .NET Framework 4.5+ compatible
	        v5.0 - .NET Standard 1.3 compatible
	        uwp - Universal Windows Platform (IMPORTANT: this will be decommissioned and replaced by v5.0)

Ref: java -jar modules/swagger-codegen-cli/target/swagger-codegen-cli.jar config-help -l csharp

[kraihn]

@wing328, targetFramework works great. Then instead of the shortened framework version, I would use the named framework version. That would be more aligned to how the dotnet cli works, and it's the value present in the project files.

--additional-properties=targetFramework=netcoreapp1.0
--additional-properties=targetFramework=netcoreapp1.1
--additional-properties=targetFramework=netcoreapp2.0

https://docs.microsoft.com/en-us/dotnet/standard/frameworks

[kenjindomini]

Is there a workaround for getting the server stubs to work in vs2017 while we wait for this to get merged? I tried to merge this pull locally so I could generate working server stubs but 2.3.0 doesn't build.

[jimschubert]

I don't have a Visual Studio 2017 license to evaluate these changes.

Does the branch from this PR not build?

[kenjindomini]

@jimschubert I pulled down this pull request as a branch and got 111 test failures when building the core lib. I followed github's instructions after cloning master: https://help.github.com/articles/checking-out-pull-requests-locally/#modifying-an-inactive-pull-request-locally
I'm building with JDK9

[wing328]

Looks like @seven1986 has removed the branch.

@seven1986 can you add back the branch so that others from the community can help move this forward?

[wing328]

To all,

To add the support, we can follow the post below to upgrade the C# Petstore project file to VS2017:

https://msdn.microsoft.com/en-us/library/ms185327(v=vs.100).aspx

Then commit the change and submit a PR. Based on the difference, we can reverse engineer the change back to the mustache templates.

If anyone has better suggestion, please reply to let us know.

(I don't have Visual Studio 2017 so can't help with this task)

[kenjindomini]

@wing328 After a couple days of playing with it I did get the currently generated files to work in VS2017. The route attributes had //<endpoint> rather than /<endpoint>, not sure if this is an issue with the generator or the VS2017 upgrade process, I didn't look into it at all. Then I added my swagger.json to wwwroot/swagger/v1 and everything started working. The "src" folder doesn't break anything. project.json is deprecated so that and the build scripts can be removed. The options being passed to Kestrel also no longer exist in 2.0. Hope this helps.

Also I would expect the latest version of VS Code to have the same project file format expectations and that is free, open source, and runs on all 3 major platforms (windows, linux, and macos) in both 64 bit and 32 bit.

[AuroraBrignola]

Hi all,
Can I please get some help with a similar issue? I am trying to locally generate a Server Stub using the 2.3.1 version of swagger-codegen, but the solution won't load in VS2017. And also, I would like the generated code to be ASP.NET Core 2. See #7892

[JonKohler]

where's this one at? interested to see this support land