Announcement: Visual Studio 2017/.csproj Migration

[NickCraver]

While Dapper currently "works" on some version of the VS 2015/project.json tooling, it's a pain. It's highly specific. (It varies). And it's getting no more love from the .NET team. It's time to upgrade to the VS 2017 .csproj project system.

Aside from one blocker which I'm monitoring in NuGet/Home#4853, we're ready to do this. I've got a branch up: vs2017, and the main commit is here: ae7a29a.

This means anyone contributing to Dapper needs to be on the new .csproj system. This works both in Visual Studio 2017 and in Visual Studio Code. There's a new build.ps1 updates to build from the command line (you'll need the dotnet tools installed): https://www.microsoft.com/net/download/core

I'll update the build.sh as soon as I can from a MacBook to test on. Another set of moves will just be inside the directories, files into src/ and tests/ folders (I haven't done this yet as to be minimally conflicting with existing PRs).

As a quick comparison, here was the old Dapper\project.json:

{
  "packOptions": {
    "summary": "A high performance Micro-ORM",
    "tags": [ "orm", "sql", "micro-orm" ],
    "owners": [ "marc.gravell", "nick.craver" ],
    "releaseNotes": "http://stackexchange.github.io/dapper-dot-net/",
    "projectUrl": "https://github.com/StackExchange/dapper-dot-net",
    "licenseUrl": "http://www.apache.org/licenses/LICENSE-2.0",
    "repository": {
      "type": "git",
      "url": "https://github.com/StackExchange/dapper-dot-net"
    }
  },
  "version": "1.50.2-*",
  "authors": [ "Sam Saffron", "Marc Gravell", "Nick Craver" ],
  "description": "A high performance Micro-ORM supporting SQL Server, MySQL, Sqlite, SqlCE, Firebird etc..",
  "title": "Dapper",
  "copyright": "2017 Stack Exchange, Inc.",
  "dependencies": {
  },
  "buildOptions": {
    "xmlDoc": true,
    "warningsAsErrors": true
  },
  "frameworks": {
    "net40": {
      "frameworkAssemblies": {
        "System.Data": "4.0.0.0",
        "System.Xml": "4.0.0.0",
        "System.Xml.Linq": "4.0.0.0"
      }
    },
    "net45": {
      "buildOptions": {
        "define": [ "ASYNC" ]
      },
      "frameworkAssemblies": {
        "System.Data": "4.0.0.0",
        "System.Xml": "4.0.0.0",
        "System.Xml.Linq": "4.0.0.0"
      }
    },
    "net451": {
      "buildOptions": {
        "define": [ "ASYNC" ]
      },
      "frameworkAssemblies": {
        "System.Data": "4.0.0.0",
        "System.Xml": "4.0.0.0",
        "System.Xml.Linq": "4.0.0.0"
      }
    },
    "netstandard1.3": {
      "buildOptions": {
        "define": [ "ASYNC", "COREFX" ]
      },
      "dependencies": {
        "System.Collections": "4.0.11",
        "System.Collections.Concurrent": "4.0.12",
        "System.Collections.NonGeneric": "4.0.1",
        "System.Data.SqlClient": "4.1.0",
        "System.Dynamic.Runtime": "4.0.11",
        "System.Linq": "4.1.0",
        "System.Reflection": "4.1.0",
        "System.Reflection.Emit": "4.0.1",
        "System.Reflection.Emit.Lightweight": "4.0.1",
        "System.Reflection.Extensions": "4.0.1",
        "System.Reflection.TypeExtensions": "4.1.0",
        "System.Runtime": "4.1.0",
        "System.Runtime.Extensions": "4.1.0",
        "System.Runtime.InteropServices": "4.1.0",
        "System.Text.RegularExpressions": "4.1.0",
        "System.Threading": "4.0.11",
        "System.Xml.XDocument": "4.0.11",
        "System.Xml.XmlDocument": "4.0.1"
      }
    }
  }
}

And the new .csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <PackageId>Dapper</PackageId>
    <PackageTags>orm;sql;micro-orm</PackageTags>
    <Title>Dapper</Title>
    <Description>A high performance Micro-ORM supporting SQL Server, MySQL, Sqlite, SqlCE, Firebird etc..</Description>
    <Authors>Sam Saffron;Marc Gravell;Nick Craver</Authors>
    <TargetFrameworks>net40;net45;net451;netstandard1.3</TargetFrameworks>
  </PropertyGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'net40' OR '$(TargetFramework)' == 'net45' OR '$(TargetFramework)' == 'net451' ">
    <Reference Include="System.Data" />
    <Reference Include="System.Xml" />
    <Reference Include="System.Xml.Linq" />
    <Reference Include="System" />
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.3' ">
    <PackageReference Include="System.Collections.Concurrent" Version="4.3.0" />
    <PackageReference Include="System.Collections.NonGeneric" Version="4.3.0" />
    <PackageReference Include="System.Data.SqlClient" Version="4.3.0" />
    <PackageReference Include="System.Dynamic.Runtime" Version="4.3.0" />
    <PackageReference Include="System.Reflection.Emit" Version="4.3.0" />
    <PackageReference Include="System.Reflection.Emit.Lightweight" Version="4.3.0" />
    <PackageReference Include="System.Reflection.TypeExtensions" Version="4.3.0" />
    <PackageReference Include="System.Runtime.InteropServices" Version="4.3.0" />
    <PackageReference Include="System.Xml.XmlDocument" Version="4.3.0" />
  </ItemGroup>
</Project>

Note that the .StrongName projects have moved into the same directory (eliminating file include complication), but aren't going away until v2 (since it's a breaking change). The goal is minimal changes to the existing packages on NuGet with this migration.

If anyone has questions or concerns, I'm happy to answer them here.

[nrandell]

I noticed the build.ps1 doesn't just run dotnet build on the entire solution, rather iterating through all the projects?

Is there a reason for this, or is it just a symptom of the previous tooling?

I would expect to see something like this (apologies for pseudo ish code)

dotnet restore
dotnet build -c Debug
foreach test project
  dotnet test -c Debug <project>

dotnet build -c Release
foreach project to pack
  dotnet pack -c Release --no-build -o output <project>

[henkmollema]

@nrandell you can even call dotnet pack on the solution. You can control which packages not to pack (e.g. test projects) by using <IsPackable>false</IsPackable>.

[nrandell]

@henkmollema - nice!
I can go home now - learnt something new today! Thanks

[NickCraver]

@nrandell Unfortunately, you can't restore then pack at the moment if you want pre-releases to work. See NuGet/Home#4337 for details. If I pushed a pre-release to NuGet, everyone would fail to restore and pre-release dependencies. Restore could be simpler yes, but that was bugged on dev-only tooling package references earlier. I'm not sure if it's been resolved, we certainly wouldn't want the build to fail on those.

There's also the possibility that not all packages in the solution have the same version number now or later. So packing them all with 1 --version-suffix (also currently broken on restores) wouldn't even be desirable. There'll be a build overhaul coming with semver.txt in the root which we're applying to all packages here at Stack. There will also be a CI build and MyGet for all packages. I'm working on that now.

@henkmollema That's the the <IsPackable> tip, that certainly is useful. I'll likely bring that in as safety at the very least when we standardize builds, versioning, packages, and feeds here.

[seburgi]

As you can see above, the package System.Data.SqlClient is referenced. This means we are tying the netstandard lib of Dapper to a SQL Server dependency, right? Would you consider a PR that replaces System.Data.SqlClient with System.Data.Common and adds System.Data.SqlClient to test projects where needed?

[mgravell]

yes; we tried to not have provider specific dependencies. In particular we dont want external dependencies, but **if it compiles** with Common, absolutely: do that - it would be an oversight on our part to have an unnecrssarily specific reference.

…

On 21 Apr 2017 5:34 a.m., "Sebastian Burgstaller" ***@***.***> wrote: As you can see above, the package System.Data.SqlClient is referenced. This means we are tying the netstandard lib of Dapper to a SQL Server dependency, right? Would you consider a PR that replaces System.Data.SqlClient with System.Data.Common and adds System.Data.SqlClient to test projects where needed? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#733 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABDsKCc0naOsvfdC1Nz16mYxl2nL83mks5ryDHHgaJpZM4MpRlG> .

[mgravell]

@seburgi addressed here: 637158f

[seburgi]

I was about to start when I realized that to you already did it. :-D Thank you!

[NickCraver]

This is now completed, master is on VS 2017 using workarounds for NuGet/Home#4853 until it's fixed for everyone in 15.3 (~July).