Multi-target the various platforms in one .csproj

[csturm83]

Type of issue

[ ] Bug
[ ] Question (e.g. about handling/usage)
[X] Request for new feature/improvement

Expected Behavior

Build QRCoder project against multiple target frameworks in one .csproj/.sln

Current Behavior

There are multiple .csproj and .sln files for the various target frameworks. The impact of changes made to files in one .csproj/.sln with respect to other framework specific .csproj/.sln may not be immediately known at build time in VS (#154). I believe some scripts are in place to help with this, but I believe building for all target frameworks with one gesture is preferable.

Possible Solution

Use the new .csproj file format to target multiple frameworks from a single .csproj (extend the existing QRCoder.NETCore20.csproj and remove the other framework specific .csproj files). Consolidate the Demo/Test .csproj's into a solution with the updated csproj.

The current target frameworks (from .csproj):

• NET35
• NET40
• PCL (Profile 111)
• NETSTANDARD2.0

Note: PCL Profile 111 maps to NETSTANDARD1.1

Proposed <TargetFrameworks>:

<PropertyGroup>
    <TargetFrameworks>net35;net40;netstandard1.1;netstandard2.0</TargetFrameworks>
    <PackageRequireLicenseAcceptance>false</PackageRequireLicenseAcceptance>
  </PropertyGroup>

Note: Other targets could be easily added and tested in the one .csproj.

The value in such a change is F5 building all target frameworks at once. One build error for any target fails the build. Also, it is less confusing for prospective contributors if there is only one solution/main project ;-) .

Another positive side effect is that NuGet packaging is made easy with the dotnet pack command (I don't believe it even requires a manual .nuspec file #57).

Other somewhat related issues: #44 #66

[codebude]

Hi @csturm83 ,

thanks for the stunning work. Some comments and thoughts before merging your PR. You wrote:

There is likely some followup cleanup of .bat and .nuspec files needed if this PR is accepted.

That's correct. CheckBinaries.bat, Compile.bat and Compile_Single.bat can be removed. The only relevant .bat-file is the MyGet.bat. This one is used to build the project and create the Nuget.package. (I use https://www.myget.org/ as build service.) Every time a commit is made to this repository, MyGet will be informed via Webhook and automatically build the project. So if I would merge your changes I there probably will follow a row of commits until I figured out what changes in MyGet.bat are necessary to get the automatically build up and running with the new .sln-file. But that's just effort, not a blocker.

One more thing - can you tell me the downsides of your PR? (I want to understand the side effects of this PR, before merging.) The only downside I can imagine is that you can't use/compile the project with VS2015 or older any longer. So people, which stick to on an old VS (for example professionals which aren't allowed to use Community Editions and don't want to buy a new version only for QRCoder) have to use Nuget package and won't be able to work with the sources. Correct? (Can you imagine more side effects?)

[csturm83]

The only potential downside that I can think of would be that somehow netstandard1.1 doesn't cover an old version of a PCL type of target outside of Profile111?? I'm not well versed in NuGet targets or how nuspecs work, but the current nuspec seems like it might be a little off. I generally rely on dotnet pack for packaging.

As for development environments (IDEs), I understand where you're coming from. You're correct that it would likely only impact working with sources from work places. My current work place supports VS Code, so it might not be that huge of a deal.

[csturm83]

In particular, this target doesn't map cleanly to a netstandard version. I'm not sure netstandard 1.1 covers Windows Phone Silverlight (not sure it matters). I wonder if it even works currently, since it is including a Profile 111 binary in that target folder..

I'm also not sure the 1.6 target works if you put a netstandard2.0 assembly in the 1.6 target folder. Also, I'm not even entirely sure that System.Drawing.Common NuGet supports netstandard1.6..

Update: This issue seems to indicate only 2.0 is supported currently (as far as netstandard goes).