Support for .NET Core, using NuProj and fixing issue #3

[fubar-coder]

• Moved source code to a shared library
• Created two projects - one for .NET Profile136 (.NET 4.0, SL5) and one for .NET Profile259 (.NET 4.5, .NET Core)
• Create NuGet package using NuProj
• Fixes Problem with "NewFolder\" #3
• Using a GlobalAssemblyInfo.cs (only one place to change the version number)

[SLaks]

Why is this a hard-coded version?
Can it be linked to the assembly version like a normal .nuspec?

[fubar-coder]

It's a limitation of NuProj. However, to make it usable from a build server, I can add the following lines to the project file:

  <PropertyGroup>
    <VersionDependsOn>$(VersionDependsOn);GetNuPkgVersion</VersionDependsOn>
  </PropertyGroup>
  <Target Name="GetNuPkgVersion" Condition="'$(NuGetPackageVersion)' != ''">
    <PropertyGroup>
      <Version>$(NuGetPackageVersion)</Version>
    </PropertyGroup>
  </Target>

This would allow one to set NuGetPackageVersion which would override the version in the NuGet project.

However, I found that the version detection of NuGet sometimes doesn't work and prefer setting the version explicitly.

[SLaks]

Why do you need two different projects?

[fubar-coder]

I need two different projects, because I have two different portable libraries. One for .NET profile 136 and one for .NET profile 259.

EDIT: It seems that I cannot create a PCL that supports both .NET 4.0 and .NET Core, which is why I need to create a new PCL for .NET 4.5 and .NET Core.

[fubar-coder]

The main reason to use NuProj is that I can simply add project references and it'll automatically create all the necessary lib and dependency entries (with the xmldoc file). It can easily be configured to create a symbol package which will be uploaded to symbolsource.org which is quite convenient when a user of the library runs into problems.

[sphiecoh]

Support .net core yet?