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

Bad error message if Microsoft.NETCore.App isn't a "platform" in the project.json #2578

onovotny opened this Issue Apr 18, 2016 · 28 comments


None yet
Copy link

onovotny commented Apr 18, 2016

Steps to reproduce

Create a new project/exe that uses the netcoreapp1.0 framework.

Add a dependency "Microsoft.NETCore.App":"1.0.0-rc2-24015"

Expected behavior

A better error saying that the type needs to be a platform. The entry should be
"Microsoft.NETCore.App": {
"version": "1.0.0-rc2-24015",
"type": "platform"
And that fixes the error correctly.

Actual behavior

Errors that suggest putting in RID's

Severity    Code    Description Project File    Line    Suppression State
Error       Can not find runtime target for framework '.NETCoreApp,Version=v1.0' compatible with one of the target runtimes: 'win10-x64, win81-x64, win8-x64, win7-x64'. Possible causes:   Dapper.Tests    C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets  241 
Error       1. The project has not been restored or restore failed - run `dotnet restore`   Dapper.Tests    C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets  241 
Error       2. The project does not list one of 'win10-x64, win81-x64, win8-x64, win7-x64' in the 'runtimes' section.   Dapper.Tests    C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets  241 

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-rc2-002418)

Product Information:
Version: 1.0.0-rc2-002418
Commit Sha: a8686e5

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14316
OS Platform: Windows
RID: win10-x64

@onovotny onovotny changed the title Bad error if NETStandard.Core.App isn't a "platform" Bad error message if NETStandard.Core.App isn't a "platform" Apr 19, 2016

@onovotny onovotny changed the title Bad error message if NETStandard.Core.App isn't a "platform" Bad error message if Microsoft.NETCore.App isn't a "platform" in the project.json Apr 19, 2016

NickCraver added a commit to StackExchange/Dapper that referenced this issue Apr 19, 2016


This comment has been minimized.

Copy link

Petermarcu commented Apr 19, 2016

The other option here is that you could build a standalone application by providing runtimes. This would create a self-contained application. Perhaps a 3rd option in the error (maybe it should be first) that says the package may be a platform?

@Petermarcu Petermarcu added this to the 1.0.0-rtm milestone Apr 19, 2016


This comment has been minimized.

Copy link

guardrex commented Apr 20, 2016

I don't think "A better error saying that the type needs to be a platform." is accurate. It's entirely reasonable to use Microsoft.NETCore.App without "type": "platform" in a standalone project. In which case, the exception line ...

Error 2. The project does not list one of 'win10-x64, win81-x64, win8-x64, win7-x64' in the 
'runtimes' section.

... is fairly clear. I agree though with the sentiment of @onovotny that this is bound to come up and confuse devs new to the application types.

Perhaps, the exception could be a bit more explicit:

Error 2. The project does not list one of 'win10-x64, win81-x64, win8-x64, win7-x64' in the 
'runtimes' section. If the project does not include '"type": "platform"' with the 
'Microsoft.NETCore.App' dependency and this is a self-contained standalone application, 
list one or more of 'win10-x64, win81-x64, win8-x64, win7-x64' in the 'runtimes' section of 
'project.json', restore the project, and use 'dotnet publish --runtime {RID}' to obtain 
executable output.

... wordy, yes, but utterly clear what needs to be done. Outside of that, another option would be for exceptions to hotlink to stable documents ... e.g., this would link directly to @blackdwarf's upcoming application types document, which also makes it clear what the dev should do.


This comment has been minimized.

Copy link

NinoFloris commented Apr 26, 2016

So hooking into this, how would one have both options on at the same time?
E.g. I would like to locally, for devs, have "platform", but at build time I want to have self contained publishes.

Currently I either have to switch it to build when I need to produce a production build or have all the different development machine runtimes in the project.json.

Is there a good story for this?


This comment has been minimized.

Copy link

davidfowl commented Apr 26, 2016

@NinoFloris no, there's no good story for that. Here's a question though, why not just develop standalone?


This comment has been minimized.

Copy link

NinoFloris commented Apr 26, 2016

@davidfowl I'm not sure what you mean by standalone, by rid's? as in "type": "build"?

Look at it like this, I will only deploy to debian flavors, and preferably a fat dist with everything included. I will not deploy to osx, windows, linuxmint, etc. so why add all of them in my config?
However I may want to bytecode compile on those, let me take care of the existence of a runtime.

Why will it not just build the stated runtimes but does it complain about your current runtime not being stated?
Because who cares that my current runtime is not in the project.json, let me handle that, and yes I know about -r and I understand that for dotnet run this error message would be desirable.

Another option that pops into my head would be a dotnet build switch for a plain bytecode / platform compile, just ignore all runtimes. Having to step down to the compiler to do just this is brutal.

As little config ceremony as possible is the goal right?


This comment has been minimized.

Copy link

hal-ler commented Apr 27, 2016

What about separating shared platform and standalone apps into different TFMs? This makes the decision clear both for the CLI and the developer and the error message could be specialized for the TFM. It also allows a developer to include both options into their project.json at the same time with no confusion (as long as the TFMs are clearly named).

I was playing around with this option around a month ago when netstandard was also runnable and it seemed to work well. I could build standalone versions for a set of runtimes and still have a back-up shared platform app for everything else supported by the CLI.


This comment has been minimized.

Copy link

hal-ler commented Apr 27, 2016

Developer tools are another scenario where both shared platform and standalone builds are desirable in my view. For example your build system might rely on NuGet, ScriptCs and some other tools. Instead of downloading a 20MB standalone version for all of these (with replicated copies of all platform libraries), one would first install the SDK (as it is needed for the build) and just download the shared platform versions of these tools. However the standalone versions of these tools are also preferred to exist in the wild for other applications.


This comment has been minimized.

Copy link

NinoFloris commented Apr 27, 2016

Yeah, I also thought about that. It's not really good as runtimes are something in the background and are not part of the real dependencies. So it does not make any sense to have different TFM's for portable and standalones.


This comment has been minimized.

Copy link

NinoFloris commented Apr 27, 2016

Hah our answers just crossed.

I really do think that there should be some way to just create a portable but I don't know enough about all the constraints and underlying thought behind the current model to know what the options are.

I hope @davidfowl can spare some of his time to explain why it is as it is.


This comment has been minimized.

Copy link

macakmujo commented Sep 17, 2016

thanks it works for me, :)
I got this bug when transfering my .net core solution to other laptop, I changed my
global.json from "version": "1.0.0-preview2-003121" to "version": "1.0.0-preview2-003131"
and got error, what does this setting "type": "platform" do exactly ?


This comment has been minimized.

Copy link

iberodev commented Sep 19, 2016

As per this documentation

The type: platform property on that dependency means that at publish time, the tooling will skip publishing the assemblies for that dependency to the published output. You don't need these since they will be installed with .NET Core on the targeted machine.

I am getting this error when trying to deploy for first time a web app with "version": "1.0.0-preview2-003131" in global.json and

"Microsoft.NETCore.App": {
      "version": "1.0.1",
      "type": "platform"


"frameworks": {
    "netcoreapp1.0": {

in project.json

Am I to assume that this version 1.0.1 is not installed in Team Services host?


This comment has been minimized.

Copy link

Tgeo commented Sep 21, 2016

Hopefully this helps someone, I ran into this error message after upgrading some nuget packages in an ASP.NET Core project.

My project.json file had this line before nuget upgrade:
"Microsoft.NETCore.App": { "version": "1.0.1", "type": "platform" }

Then after upgrade, that line was removed and this was added:
"Microsoft.NETCore.App": "1.0.1"

Since this now doesn't list the platform (the focus of this GitHub issue), you just need to revert the newly added line to the previous block (with the "type": "platform").


This comment has been minimized.

Copy link

ricardo-cantu commented Sep 22, 2016

@Tgeo This is exactly what happen to me. I wonder if this needs to be raised as an issue on some other forum as well.


This comment has been minimized.

Copy link

mkalkere commented Sep 26, 2016

When i am trying to build the dotnetcoreapp1.0 as SCD by removing "type":"platform" and by adding
"runtimes": {
"win10-x64": {},
"osx.10.10-x64": {}

in project.json i get the below error.

C:\Users\Mallikh\SCD>dotnet build -r win10-x64
Can not find runtime target for framework '.NETCoreApp,Version=v1.0' compatible with one of the target runtimes: 'win10-x64'. Possible causes:

  1. The project has not been restored or restore failed - run dotnet restore
  2. The project does not list one of 'win10-x64' in the 'runtimes' section.
  3. You may be trying to publish a library, which is not supported. Use dotnet pack to distribute libraries.

can i know what i am doing wrong here please?


This comment has been minimized.

Copy link

blackdwarf commented Sep 26, 2016

@ricardo-cantu @Tgeo this is a known Nuget tooling issue, I believe it is being tracked on Nuget/home.

@mkalkere I just tried a repro on the default template for a console app and it worked. Some questions:

  1. Did you restore the project after adding the runtimes node in the project.json?
  2. If the above doesn't solve it, can you paste your entire project.json in here so we can review?

This comment has been minimized.

Copy link

mkalkere commented Sep 26, 2016

issue got solved when i changed the version from 1.0.1 to 1.0.0

"Microsoft.NETCore.App": {
"version": "1.0.0"


This comment has been minimized.

Copy link

mkalkere commented Sep 26, 2016

@blackdwarf yes i did restore the project after adding the runtimes.

when i changed the version to 1.0.0 it worked.


This comment has been minimized.

Copy link

blackdwarf commented Sep 26, 2016

@mkalkere did you install the 1.0.1 framework?


This comment has been minimized.

Copy link

mkalkere commented Sep 26, 2016

@blackdwarf yes i have installed 1.0.1 framework.

and now i am trying the same thing again. but i am facing the same problem.

this is the complete project.json :

"version": "1.0.0-*",
"buildOptions": {
"debugType": "portable",
"emitEntryPoint": true
"dependencies": {},
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1"
"imports": "dnxcore50",


This comment has been minimized.

Copy link

mkalkere commented Sep 26, 2016

@blackdwarf : Issue was not with the version it was the location at which the runtimes was placed.

it works fine with the below project.json:

"version": "1.0.0-*",
"buildOptions": {
"debugType": "portable",
"emitEntryPoint": true
"dependencies": {},
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1"
"imports": "dnxcore50"




This comment has been minimized.

Copy link

AlanBarber commented Sep 29, 2016

Updated my nuget packages on a core website and ran into the same problem with builds... I followed what @Tgeo said here and that fixed the builds.

I did upgrade from Microsoft.NETCore.App 1.0.0 to 1.0.1.


This comment has been minimized.

Copy link

hksingh commented Dec 14, 2016

@Tgeo workaround by adding platform fixed the issue.


This comment has been minimized.

Copy link

TheRealPiotrP commented Dec 17, 2016

Since this is a project.json issue and there is a workaround available I'm closing this issue.


This comment has been minimized.

Copy link

wilfredogr commented Dec 23, 2016

How do you close if the solution is not clear? I have the same issue with ASPNetCore 1.1.0. I didn't change anything because it is supposed Visual Studio 2015 creates everything from the template I'm using (MVC) right? So how do you determine is JSON problem? Users don't create this file.

This is my project.json:
"dependencies": {
"Microsoft.AspNetCore.Razor.Tools": {
"version": "1.0.0-preview2-final",
"type": "build"
"BundlerMinifier.Core": "2.2.306",
"Microsoft.ApplicationInsights.AspNetCore": "1.0.2",
"Microsoft.AspNetCore.Diagnostics": "1.1.0",
"Microsoft.AspNetCore.Mvc": "1.1.0",
"Microsoft.AspNetCore.Routing": "1.1.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.1.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
"Microsoft.AspNetCore.StaticFiles": "1.1.0",
"Microsoft.Extensions.Configuration.EnvironmentVariables": "1.1.0",
"Microsoft.Extensions.Configuration.Json": "1.1.0",
"Microsoft.Extensions.Logging": "1.1.0",
"Microsoft.Extensions.Logging.Console": "1.1.0",
"Microsoft.Extensions.Logging.Debug": "1.1.0",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.1.0",
"Microsoft.NETCore.App": "1.1.0",
"Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.1.0",
"Microsoft.EntityFrameworkCore.SqlServer": "1.1.0",
"Microsoft.EntityFrameworkCore.Tools": "1.1.0-preview4-final",
"Microsoft.EntityFrameworkCore.Design": "1.1.0"

"tools": {
"Microsoft.EntityFrameworkCore.Tools.DotNet": "1.0.0-preview3-final",
"Microsoft.AspNetCore.Razor.Tools": "1.0.0-preview2-final",
"Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final"

"frameworks": {
"netcoreapp1.0": {
"imports": [

"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true

"runtimeOptions": {
"configProperties": {
"System.GC.Server": true

"publishOptions": {
"include": [

"scripts": {
"prepublish": [ "bower install", "dotnet bundle" ],
"postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]


This comment has been minimized.

Copy link

blackdwarf commented Dec 23, 2016

@wilfredogr the solution is to add type: platform to the Microsoft.NETCore.App dependency, like so:

"Microsoft.NETCore.App": {
    "type": "platform",
    "version": "1.1.0"

This comment has been minimized.

Copy link

Lukenbill commented Jan 4, 2017

Still an issue, Tego's fix works...not sure how this "closes the issue" though


This comment has been minimized.

Copy link

CodingSamurai commented Jan 15, 2017

I agree with @wilfredogr this issue should NOT be closed. First of all, the underlying issue (that a nuget update suddenly breaks a working .NET Core Website by removing "type": "platform") is not fixed and is a critical issue.

Secondly the error message is crap as it's not clear that a nuget upgrade may have simply broken the project.json. So a much better error message is needed, perhaps something that also describes what it means to be a "type": "platorm" (i.e. this is the default needed for a .NET Core Website) would help save people from wasting more than 10 minutes on something NuGet/Visual Studio breaks.


This comment has been minimized.

Copy link

gortok commented Jan 19, 2017

If you update Microsoft.NETCore.App to 1.1.0 (via Nuget) either in VS2015 or via the command line (Mac or Windows), it removes the following:

   dependencies: {
-         "Microsoft.NETCore.App": {
-         "version": "1.1.0",
-         "type" :  "platform" 

and replaces it with this:

 dependencies: {
    "Microsoft.NETCore.App" : "1.1.0",

To resolve this issue, put the type and version properties back in and make the dependency an object instead of a string.

joangilabert added a commit to joangilabert/dapper-dot-net that referenced this issue Apr 16, 2018

actualizacion desde el original (#1)
* Tests: add 4 attempts to repro #457

* Change CE package to one that might work

* Fix *all* the CE references

* Don't attempt to load native assemblies on DNX

* Detect app-veyor for MySql/Postgresql

* Standardize on test db for appveyor

* actual/expected in asserts are the wrong way round

All the tests are wrote in the form actual.IsEqualTo(expected). This
made for some odd error messages when a test failed.

* Initial test setup for #461; note that this does not repro, due to running on SQL-Server - needs to be changed to SQLite to repro

* Fix #461 - change FindConstructor to allow parameters that have a type-handler defined

* New feature: PadListExpansions - reduces query plan saturation by padding "in" lists and populating with nulls; opt-in (see remarks on setting)

* 1.50-beta8 deploy

* Fix typos in the comments for PadListExpansions

* Test for SO35470588

* update performance tests link

* Example for SO35554284

* Add SQLITE to test builds; add tests for issues #466 and #467; fix #466 by adding retry-with-fallback flags strategy

* Update to sqlite rc2, because without that nothing works; add extra tests around sqlite oddities; update tests to reflect sqlite rc2 fixes

* Fix #468 - CreateParamInfoGenerator should treat enums as primitives, not box them as enums

* Don't check for null in the basic enum case

* Support get-only C# 6 properties, i.e. `public int Id {get;}`

* prefer an exact-case backing-field match over a wrong-case regular field (essentially: this promotes get-only properties over regular fields)

* Support xml types by default (XmlDocument, XDocument, XElement) - fix #427

* Set the DbType for XmlDocument / XDocument / XElement

* When doing list expansions (6=>10 etc), use the last non-trivial value - do *NOT* use null, as it causes problems with "not in" clauses; add test for the same

* Recreate all the xproj to reflect the current tooling - old versions break VS15; enable XDocument etc in corefx (#if block was too large)

* Heh, AspNet and DNX (only) work in VS2015; DNX and DotNet (only) work in VS15; I guess we need to use DNX for now, then, as the only one that works in both.

* 1.50-beta9

* Unify test credentials for MySQL; add passing test for SO36303462

* Bumping dependencies version numbers

* Revert "Bumping dependencies version numbers"

This reverts commit 70ee9a7.

* Readme: Better explanation for multi mapping

* fix outpt paths

* Get building

* PowerShell build scripts

* PowerShell build updates: include .Contrib

* PowerShell build script love

* Add bash build scripts

Note: these are hosed on OS X due to file handle limits, see
dotnet/cli#809 for details.

* Bash build: fix test runner on OS X

Note: no tests pass because there’s no integrated security option (or
widely available SQL server) on OS X at the moment. But the build and
test runners are up and going.

* Update .gitgnore for build pathing

* .Net Core: remove floating versions (use stable ones on and get this puppy back in action.

Also: it's 2016.

* Add newer feed back **only for the tests projects**, Sqlite for example has bugs in rc1-final fixed in rc2-15948

* feed only, skip the 2 Sqlite tests until RC2+ packages with the fix are out of pre-release.

* Fix assembly name for Contrib tests

* Runtimes fix, per dotnet/cli#2578

* Fix EntityFramework.StrongName build for RC2

* Update to RC2 final build (24027) libraries. Also bump to beta10

* RC2: Remove CoreFX #1612 blocker - fix is released, yay!

dotnet/corefx#1612 is now closed, tests

* Upgrade project.json files to RC2 format.

Note: on a nuspec comparison, the following dependencies aren't there
anymore: Microsoft.CSharp, mscorlib, System, and System.Core aren't
explicitly specified in frameworkAssemblies anymore. The only one of
these I can imagine mattering is Microsoft.CSharp.

* It's time for appveyor.yml

Tooling changes need to live in the repo now so the build doesn't FUBAR
every time we change the script.

* It took several people a while to find this one.

* RC2 Version bump, since we locked ourselves in with semver on beta9

* Update build scripts to pack for us

* JSON RC2 fixes

* Interfaces are back, simplifying code.

Related issue: #520

* net451 test prep (not quite ready - SQL Geo and interop failing)

* XMLDoc fixes for latest methods and missing DataSet in .NET Core

* .xproj: RC2 upgrade

This fixes null refs with the DNX MSBuild targets when building from
Visual Studio.

* Switch version suffix to be a build parameter

Note: needs love from OS X/*nix later to match

* This .0 addition happens automatically...make it explicit instead.

* git blame game

* Test for #524 (believed to be a failing test; cannot validate or Fix until I get the latest tooling installed)

* Fix #524 - `GridReader` should use the same conversion code as the regular reader

* Add InListStringSplitCount; when set, causes `in @foo` parameters to be implemented using string_split

* fix case of generated SQL in string-split

* Dapper.EF.StrongName: should snk for *all* builds!

* Fixed some syntax errors in project.json files.

* .Net Core 1.0 RTM update

* Remove a bunch of unnecessary (and *theoretically* dangerous, in a very unlikely scenario involving custom cultures installed on a box) C# 7 string $"...{...}..." usages

* Simplify the string_split implementation

* 1.50.1 deploy

* Rename DataTable=>DapperTable; fix #549

* Failing test for #552

* (just to prove that #552 still happens even if the only values seen are 0 and 1)

* Fix for #569

* 1.50.2

* Repackage Dapper.EF to fix System.Runtime; deploy as .52; fix xunit refs; add test for #570

* Added tests to complement documentation of pseudo-positional parameters

* Fix SqlBuilder.OrWhere method which was actually yielding an 'AND WHERE' statement.

* Operate on db records instead of files.

* Add CommannDefinition versions of Query(First,FirstOrDefault,Single,SingleOrDefault)Async and a few unit tests for them

* Improve tests

* failing test for #563

* fix broken test to actually include the error!

* Make CommandBehavior more configurable; default to SingleRow=allowed,SingleResult=disallowed - but expose options; this fixes issues like #563 automatically, and allows the performance aspect  of #554 to be fixed via a global setting

* support for international parameter names (regex categories); fix #601

* Add some <remarks> to the new options

* Capitalization

* Update

Missed second bracket in ID example

* Set true to GridReader.IsConsumed when MultiReadInternal is called

* Non-greedy match for comments regex

Fixes #436, #280
My editor has also normalized a few line endings to LF like 99% of the
file was.

* Fix #634 - dapper now handles connection lifetime and has for ages

* 1.50.3-beta1: looks at #637  re `Guid`

* Toolng cheese move - lock in preview2 for now.

* Fix Contrib test resolution

Note: there's still a 1.0.0 vs 1.1.0 quirk here - digging.

* Add SqlMapper.RemoveTypeMap() method

* Update

* Add test DiscriminatedUnionWithMultiMapping

DiscriminatedUnionWithMultiMapping - test for check correct MultiMapping (splitOn) functionality with discriminated row parser.

* added firebird support

added firebird sql adapter to allow record insert and key retrieving

* Revert "1.50.3-beta1: looks at #637  re `Guid`"

This reverts commit 91725fb.

* Update README with documentation for [ExplicitKey] attribute

* Add GetRowParser documentation/example

* Fix missing Firebase Async, issue #695

TODO: All of these need race love in V2, complete re-vamp.

* Rename package to "Dapper"

Related: #683

* Remove note about requiring open connections

* Added Belgrade Sql Client

In the performance benchmark is added Belgrade Sql client data access
library ( This is a
wrapper around ADO.NET classes that executes queries in async manner
using callbacks. "Belgrade.Sql.Client": "0.6.2" is aded in project.json
file, and new flag "BELGRADE" controls should the test be executed.

* migrate release notes to [master]/docs

* Set theme jekyll-theme-cayman

* Add a full stop just so I can tell if the docs migration is working

* Fix Dapper release notes link

* Security!

* Fixed test issue in Simple.Data performance test (#723)

* Added fix for Simple.Data tast

Due to the missing .FirstOrDefault() in Simple.Data test, performance
numbers for Simple.Data were too high (better than hand coded data
reader). Added FirstOrDefault() to actually fetch the data.

* VS 2017 .csproj Migration
Due to the way VS test works (by injecting an executable entry point), the performance tests needed to be factored out. I also organized all of our existing tests better along the way.
Actual code changes to Dapper itself are very minor, only formatting and documentation fixes (which we need many more of).

The build.ps1 script is upated to work, but note that <frameworkAssemblies> is not working in .nuspec inside the packages in the new .csproj system. I consider this to be a blocker. Issue is here: NuGet/Home#4853

* Correct minor typographical error in (#732)

Under the `List Support` section, the sentence opens with `Dapper allow you`, which should instead be `Dapper allows you`. This PR will correct this mistake, restoring balance to the universe.

After originally spotting this, the most minor of mistakes, I decided to leave it and move on with my life, since it likely effected nobody. Four hours passed and the thought that it existed unchecked had fully manifested itself within my subconscious and I was no longer able to continue with my existence knowing that I had seen this mistake and not exercised my power to correct it.

Thank you, and sorry.

* Define expected behaviour for value-tuple parameters and returns, and implement

* remove redundant test code (oops)

* Better matching of value-tuple names when wrong number of columns - should return nulls for unmapped

* Add tests for the too few/too many columns scenarios for value-tuples; happy to discuss alternative expectations

* Fix Readme typos (#739)

* Fixed link to test suite (#764)

* VS 2017 Build - Making things work (#766)

* Progress on VS 2017 build tooling
* Finally, a working VS 2017 tooling build

* Update appveyor.yml for 2017 build

* Appveyor: update services

* Let's try this again

* Again!

* More path changes

* Appveyor: SQL 2016

* Appveyor: create databases

* Let's just keep adding YAML until this works.

* Appveyor: Formatting & combine init

* Appveyor: Update Postgres path

* Lots of documentation fixes/additions.

* Fix Microsoft.SqlServer.Types for new .csproj

* Fix type loads for the builds without SQL in the GAC

* Fix SQL spatial type loading

* Skip the MySQL FUBAR test

It's indeed broken on their end. We should consider switching providers,

* Add build badge to README

* Appveyor: enable MyGet publishing

* Lots of code cleanup, no functional changes

* C# 7 cleanup: pattern matching for TryStringSplit

* Documentation: GridReader

* Documentation: contrib

* Documentation: EntityFramework

* Documentation: Rainbow

* Tests: make analyzers happy because why not

* Documentation and formatting: secondary types

* Documentation and formatting: SqlMapper

* Benchmarks v2: BenchmarkDotNet and friends

This is based on BenchmarkDotNet (while preserving the legacy format
with minor improvements as well - legacy runs much faster). See #666 for
details. Not an ominus number at all.

Note: this code will get a bit simpler with BenchmarkDotNet categories,
see dotnet/BenchmarkDotNet#248 for details.

* Dependency: Dapper doesn't need SqlClient, only Data.Common

* Benchmarks: customization and formatting

More cleanup to do (removing Type column next), but getting to some very
usable output now.

* netstandard2.0 functionality (w/ runtime breaks)

This adds a netstandard2.0 build to Dapper (and StrongName until v2),
adds a netstandard2.0 test lineup, restores most functionality (except
UDTs for SQL, e.g. .UdtTypeName isn't in netstandard2), and also breaks
things not actually implemented or implemented correctly in
netstandard2.0. Pushing this up so we can work through these with the
.NET teams.

Several things are still broken here (and fail tests):
- Parameter decimal values (not filed yet)
- DataTables as parameters
- .GetSchemaTable() (not yet filed, implementation is completely missing
from SqlDataReader in CoreFX)

While the compile is clean, the above are runtime issues.
`SqlParameter.UdtTypeName` is a separate issue, that one just wasn't in
`netstandard2.0` at we can't support UDTs there until it is.
See dotnet/corefx#17126 for details.

* Fix MySQL tests and disposal (#774)

* Don't create the connection in Dispose: this avoids creating a SQLConnection simply to Dispose it.
* Run MySQL tests against the open MySqlConnection: 'connection' is a protected variable in the TestBase class that is a SQL Server connection, not a MySQL connection.
* Skip broken MySQL tests: as per issue #295, setting "AllowZeroDateTime=True" in the connection string causes an InvalidCastException in SqlMapper.

* Benchmarks: performance and formatting

* Minor README tweaks. (#776)

Use an HTTPS link where possible.
Fix 404 for performance tests.

* Fix for InsertAsync in PostgresAdapter (#689)

* Fix for PostgresAdapter in SqlMapperExtensions.Async. Copied same line of code from SqlMapperExtensions to fix RuntimeBinderException on InsertAsync
* Cleanup

* Try and use BenchmarkDotNet correctly

OperationsPerInvoke is an informational, not instructional property.
What we actually want is the UnrollFactor. Moved into the job definition
to simplify things.

* fix issue #731: AddDynamicParameters repeated if paramtype is DbStiring should work.

* Added EntityFrameworkCore performance tests (#778)

* Perf: add EntityFramework Core to legacy tests

* Markdown tables (#800)

Markdown tables instead of html
“Can be faster” in correct row

* Enable SqlDataRecord TVPs on corefx. (#801)

* Revert "Enable SqlDataRecord TVPs on corefx. (#801)" (#803)

This reverts commit e7ad087.

* Appveyor: use the VS 2017 preview image

* Avoid allocation for linq in CreateParamInfoGenerator and added some other micro optimizations

* Enable SqlDataRecord TVPs on netstandard1.3. (#802)

* Enable SqlDataRecord TVPs on netstandard1.3.
* Update netstandard2.0 SqlClient references to Preview 2.
* Skip TransactionScope tests for netcoreapp2.0.
- According to dotnet/corefx#12534, ambient transaction enlistment is not included with .net core 2.0.
* Update references in Dapper.StrongName.
* Disable parallel test run to stabilize flaky type handler tests.
* Disable parallel test run by assembly attribute.
* Move Issue461 tests to TypeHandlerTests.
* Group type handler tests in a collection, re-enable parallelization.
- Being part of the same collection, type handler tests will run sequentially. All other tests can run in parallel.
* Move tests relying on query cache & type maps to a separate collection.

* Upgade libs, fix tests

This uses the new non-parallel-at-the-end I added to xUnit in xunit/xunit#1411 This way we can run any global test that are other-test-unfriendly much more easily.

* More test fixes

* Appveypr: update to base 2017 image again

.NET Core 2 SDK is on the base Appveyor image now

* Update semver, add to solution

* Fix for #808

Add dynamic overloads for:
- QueryFirstAsync
- QueryFirstOrDefaultAsync
- QuerySingleAsync
- QuerySingleOrDefaultAsync

This may change a lot in 2.x, but many people asking for them now so here they are. Unit tests also fixed for QuerySingleOrDefaultAsync.

Note: this builds on the netstandard2 branch because of the xUnit changes to go with VS 2017 15.3.

* Fix for #815

New overload so this isn't a breaking change. We can collapse down in v2.0 (including the Impl method).

* Update README to remove advetisements

* Tests: xUnit cleanup

This change:
- Removes the Assert shim
- Uses recommended xUnit methods (improving fail errors)
- Cleans up exception tests
- General test formatting fixes
- Removes the netcoerapp1.0 only testing (oops commit)

* Cleanup

* Fix unit tests

* Update README for new assertions

* net40 is dead - remove #if ASYNC bits

* .editorconfig and formatting

* Misc build analyzer fixups

* Lib updates and prep for netstandard2.0 alpha

* Dapper.Contrib: netstandard2.0

* Fix build script

Removes NuGet workaround for pre-2.0 and lines up with other script
enhancements since.

* MyGet feed!

Adding a dapper specific feed, for much easier pushing to NuGet. When
they implement Ctrl+Click in the UI this won't be necessary...or we
break down and automate it finally. Depends on signing plans later.

* Add literal replacement example to readme

* Additional notes on literal replacements

* words are hard

* Tests for DateTime2 compatibility

This shows the importance of using DbType.DateTime2 in Dynamic Parameters to avoid precision truncation

* Shortened the changes

Combined 2 tests into one

* when inserting, check if type implements IEnumerable<T> to determine if it's a collection (#880)

* when inserting check if type implements IEnumerable<T> to determine if it's a collection
* when inserting, check if type is a collection by comparing its implemented interfaces to unbound generic type IEnumerable<> instead of the name "IEnumerable`1"

* bump semver for next release

* Ignore .vscode/

* 1.50.4 release

* Bump semver for next release to 1.50.5-alpha*

* Fix benchmark description typos (#932)

* fix equal tests (#944)

* fix equal tests

* fix test

* Test and fix for #591

This brings behavior QueryAsync behavior on par with Query (sync) and properly returns nothing when an empty result set is encountered.

* Code formatting fix (tabs to spaces) (#896)

* Make DapperRow implement IReadOnlyDictionary<string, object> (#913)

* Change to GetAll to allow the usage of a nullable type in T when T is an interface… #933 (#936)

* Change to GetAll to allow the usage of a nullable type in T when T is an interface.

* Change to GetAll to allow the usage of a nullable type in T when T is an interface: further change to check if val == null and if so then don't try to assign it as a property value.

* Change to Get to allow the usage of a nullable type in T when T is an interface. (effectively the same change as the previous change to GetAll.)

* Change to GetAsync and GetAllAsync to allow the usage of a nullable type in T when T is  an interface.

* Added in UserWithNullableDob and IUserWithNullableDob.

Added in tests for GetAndGetAllWithNullableValues and  GetAsyncAndGetAllAsyncWithNullableValues.

* Added in .ConfigureAwait(false) in the GetAsync Test.
Added comment to identify which issue the test relates to.

* Added NullableDates tables to the test databases.
Adjusted variable names in GetAndGetAllWithNullableValues and GetAsyncAndGetAllAsyncWithNullableValues.

* Changed IUserWithNullableDob to INullableDate.

* fix Insert<T> when T is declared as IEnumerable<T> (#948)

* Removing unjustified use of AppendFormat in StringBuilder class (#989)

* Remove reference to Stack Overflow docs 

Should resolve #992

* Better error messages for .*Async methods when not using  DbConnection (#986)

* Better error messages for .*Async methods when not using  DbConnection

Perhaps in v2 we move these to DbConnection itself ratherr than IDbConnection for the extensions to eliminate the case, but that's breaking...for now we can at least throw a better error. See #757 for details.

* Tweak errors to allow open IDbConnections and those generating DbCommands

Same checks but a bit more lenient with more specific messaging.

* Tweaking error messages and supporting IDbConnection implementations … (#987)

* Fixed dead link in

Replaced a dead link in by a link to the WaybackMachine

* misc tidying

wli3 pushed a commit to wli3/cli that referenced this issue Nov 14, 2018

Merge pull request dotnet#2578 from peterhuene/build-apphost
Implement building with an apphost by default.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment