# Sunday, May 22, 2016

Executables vs class libraries

In classic .net, class libraries had an "output type" of "class library" in the property pages (and .csproj) and the extension ".dll". Executable libraries have output types of "Console application" or "Windows application" and the extension ".exe". Asp.net projects are special, actually class libraries launched by IIS.

In dotnet Core, the project.json specifies executables (that have a "static void Main" - including asp.net Core projects) with this section in project.json:

"buildOptions": {
    "emitEntryPoint": true

The other key difference is the dependencies and frameworks. Libraries can refer to the "netstandard" abstract APIs (dependency "NETStandard.Library"). Executables need a runnable framework - "netcoreapp" (dependency "Microsoft.NETCore.App").

So a minimal library project has a project.json like this:
  "version": "1.0.0-*",
  "dependencies": {
    "NETStandard.Library": "1.5.0-rc2-24027"
  "frameworks": {
    "netstandard1.5": {
      "imports": "dnxcore50"


A minimal executable project has a project.json like this:

  "version": "1.0.0-*",
  "buildOptions": { "emitEntryPoint": true },
  "dependencies": {
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.0-rc2-3002702"
  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"


Referencing projects in a solution

Almost all real-world .net solutions are not single projects- they contain multiple linked projects. A console or asp website will depend on one or more class libraries, containing the business logic or interfaces to databases or webservices. At the very least, there should also be one or more test projects containing the unit tests.

In classic .net, the .csproj project files had a special type of project reference between projects in a solution. In dotnet Core RC2, the project.json file lists all dependencies as nuget packages. When you add a project reference is Visual Studio (using the "Preview 1" tooling released with RC2), it appears just like a nuget reference. You must manually add a special qualifier to indicate a project reference.

"dependencies": {
    "CoreLib": {
        "version": "*",
        "target": "project"
The "target" is by default "package", but here we make it "project". The "version" can be a wildcard (in a solution we're not worried by semver breaking changes).

You can build with Visual Studio and the "dotnet" command line- but in Visual Studio any cross-project references persistently have red lines and no intellisense. The tooling - at least as of "RC2/Preview 1", with and without Resharper - simply doesn't recognize cross-project references.


The "netstandard" framework means a class library is portable across common APIs - from dotnet Core ("netcoreapp") to the full .net framework, .net 4.6 ("net46").

As at RC2, a Core asp.net project uses "netcoreapp1.0", which is a superset of "netstandard1.5". It can also consume libraries that use "netstandard1.0", "netstandard1.1" up to 1.5.

Libraries should generally specify lower (less restrictive) netstandards. Don't lazily specify 1.5 when you can run in 1.0, and be used by a wider range of consumers.

netstandard1.0-1.2 do not include the [assembly: Guid("")] attribute in AssemblyInfo.cs. It's used for COM, so most libraries that are only used by .net can safely remove it.

Multi- targeting

You can explicitly add other targets apart from "netstandard". It doesn't make a lot of sense for "net46", which is netstandard, but you can specify "net45", "net40", "net35" or even "net20".

Let's take some traditional ADO:

using System;
using System.Data.Common;

namespace CoreLib
    public static class AdoLib
        public static void ExecuteDbReader(DbConnection connection)

            using (var cmd = connection.CreateCommand())
                cmd.CommandText = "SELECT * FROM Products";
                using (var dr = cmd.ExecuteReader())
                    while (dr.Read())

For dotnet core, the dependencies will be NetStandard.Library, System.Console and System.Data.Common.

But if these are in the top level "dependencies" section, they aren't compatible with the "net" frameworks. Those libraries aren't in nuget packages, they are in GAC assemblies as part of the .net framework library.

The dotnet Core dependencies can be moved under the framework for "netstandard". For the "net" frameworks, we can specify GAC references (which may not correspond exactly to the nuget packages) within frameworkAssemblies. This is what the project.json looks like:

    "version": "1.0.0-*",

    "dependencies": {

    "frameworks": {
        "netstandard1.1": {
            "imports": "dnxcore50",
            "dependencies": {
                "NETStandard.Library": "1.5.0-rc2-24027",
                "System.Console": "4.0.0-rc2-24027",
                "System.Data.Common": "4.0.1-rc2-24027"
        "net45": {
            "frameworkAssemblies": {
                "System.Data": ""
        "net40": {
            "frameworkAssemblies": {
                "System.Data": ""
        "net20": {
            "frameworkAssemblies": {
                "System.Data": ""

Now "dotnet publish" will generate a package that supports net2.0 to to dotnet core.

In practice, dotnet core APIs aren't exactly the same- for instance there are no DataTables. Most real life code will probably require conditional code, wrapped in compiler directories. Automatically we now get compiler symbols for each framework when it's built- "net20" and so on. You can also add your own, via "compilationOptions": { "define": ["CLASSICNET"] }

posted on Sunday, May 22, 2016 5:58:41 PM (Romance Daylight Time, UTC+02:00)  #    Comments [0]
# Wednesday, May 18, 2016

net Core RC2 came out on 2 days ago (May 16 2016). I tried upgrading a simple class library so that it can support .net Core RC2 plus older .net frameworks.

It was relatively straightforward, unlike RC1. Here's what I did.

The library I used was very simple (my public holidays project).  There is just one project. We're not doing tests for now- we're using vanilla MsTest. RC2 still only supports XUnit, but we should get MsTest for RTM. For now, we want to be able to use the "classic" solution, with tests, and add a parallel "Core" solution that sits alongside it.

Installing RC2

  • If upgrading from RC1, clear the nuget cache: nuget locals all -clear
    • If you upgrade projects, there are numerous low-level changes (project.json structure, package names)
  • If you installed older versions of RC2/dotnet CLI, uninstall them via Programs + Features ("Microsoft Dotnet CLI for Windows". You can also get rid of "Microsoft ASP.Net 5 RC1 Update 1" which seemed to work but didn't disappear from the list)
    • If you forget (as I did!), VS shows the error "The project is configured to use .NET Core SDK version 1.0.0-preview1-002702 which is not installed or cannot be found."
  • Use the "Microsoft .Net Core 1.0.0 RC2 VS 2015 Tooling Preview 1"


I added a project.json, but I added it alongside the .csproj. There was a bug in RC1 that Visual Studio/ nuget didn't like csproj and project.json together (https://github.com/dotnet/corefx/issues/4544, last updated April, see also Marc Gravell's instructions at http://blog.marcgravell.com/2015/11/the-road-to-dnx-part-1.html, November 2015 so RC1). Let's find out if it's fixed.

  "version": "1.0.0-*",

  "dependencies": {
    "NETStandard.Library": "1.5.0-rc2-24027"

  "frameworks": {
    "netstandard1.3": {
      "imports": "dnxcore50"

  • We're just using the standard library (we could depend on loads of individually specified packages, but this is very concise).
  • The package/dll name is the folder name.
  • Not sure why we're importing dnxcore50, when dnx is supposed to be gone- from the discussion on github it looks like another transitional thing. Maybe it will be gone for RTM in June.
  • You can use framework netstandard1.5 or roll back to netstandard1.0. For 1.0 - 1.2, it red-lined on [assembly: Guid( attribute in AssemblyInfo.cs. So netstandard1.3 it is.

I opened up the old solution. Building in Visual Studio broke: "Your project is not referencing the ".NETFramework,Version=v4.0" framework. Add a reference to ".NETFramework,Version=v4.0" in the "frameworks" section of your project.json, and then re-run NuGet restore."

The workaround (from the github issue) is to add <ResolveNuGetPackages>false</ResolveNuGetPackages> to the .csproj. If you have packages, tough.

First dotnet build

There's documentation on the "dotnet build" command here: http://dotnet.github.io/docs/core-concepts/core-sdk/cli/dotnet-build.html

>dotnet build
Project x does not have a lock file
Project x does not have a lock file

Saying it twice doesn't make it any more helpful. The lock file is something to do with a package restore. 

>dotnet restore
log  : Restoring packages for C:\...\project.json...
info : Committing restore...
log  : Writing lock file to disk. Path: C:\...\project.lock.json
log  : Restore completed in 950ms.
>dotnet build

It builds!

We now have a dll and pdb in bin/Debug/netstandard1.3
We also have a json file, (x.deps.json), which shows you everything in .NETStandard,Version=v1.3

Parallel solutions

I created a second solution alongside the current solution (essentially the same, minus the test project).

Next, alongside the current project, I added an xproj file (a cut-down csproj). To get this file, I created a new Core library in Visual Studio in a different folder, and stole the xproj. I had to change the <RootNamespace>x</RootNamespace>.

I also changed the  <OutputPath Condition="'$(OutputPath)'=='' ">.\bin\</OutputPath> ( to .\bin\core\ ) so building the current and new projects put things in different places. Note this only works in Visual Studio- "dotnet build" doesn't look at the .xproj. Instead you have to >dotnet build -c Release -o .\bin\core\ -f netstandard1.3 (note you have to specify the framework when you use --output).


Adding older frameworks to project.json is as simple as adding the targets (which are the same as used in nuget).

  "frameworks": {
    "netstandard1.3": {
      "imports": "dnxcore50"
    "net35": { },
    "net40": { }

This works, but in Visual Studio it has a deep output folder structure. Using the dotnet command line, it's exactly what you'd expect.

Not sure why Visual Studio adds more levels.

Packing up

Nuspec is now in project.json. Add json like this:
  "packOptions": {
    "summary": "Wonderful library",
    "tags": [ "Wonderful" ],
    "owners": [ "me ],
    "projectUrl": "
    "licenseUrl": "
    "repository": {
      "type": "git",
      "url": "

We now use "dotnet pack" instead of "nuget pack": http://dotnet.github.io/docs/core-concepts/core-sdk/cli/dotnet-pack.html
>dotnet pack -c Release -o .\artifacts

  • Pack builds the project, but you can pass --no-build.
  • Note the version number is taken from the project.json (not the AssemblyInfo.cs).


Hopefully appveyor will roll out RC2 support soon (maybe this week?), and we can have easy CI builds. Once that is in-place, I will use it to publish the pre-release package to nuget.

More complex dependencies, particularly on older parts of .net like ADO, will be more challenging. It would be easy to find yourself with heavy compiler directives all over your code.

Sometime after RTM, project.json will be phased out, and we move back to csproj (hopefully improved). I suspect this will come with the release of the next version of Visual Studio (2017?).

posted on Wednesday, May 18, 2016 8:47:50 PM (Romance Daylight Time, UTC+02:00)  #    Comments [0]
# Thursday, February 25, 2016

Part 1 here


https://vimeo.com/154708153 Something C# 7 This Way Comes - Bill Wagner (c#7 wish list is https://github.com/dotnet/roslyn/issues/2136 )
https://vimeo.com/155107766 C# Language Internals - Bart De Smet
https://vimeo.com/155521073 Under the hood of C# 6.0 - Bart De Smet


https://vimeo.com/156402866 .NET Deployment Strategies (Octopus Deploy)
https://vimeo.com/156264107 Versions are evil - how to do without in your API - Sebastien Lambla
https://vimeo.com/155653145 Distributed Systems principles
https://vimeo.com/155646004 Best Practices for Building a REST-ful API - kevin Dockx

Case studies

https://vimeo.com/156420622 The Times - tools behind a newspaper website (Nodejs, Chef, aws, &, atom-json in S3)
https://vimeo.com/156417164 Azure Portal - tools behind a big SPA
https://vimeo.com/155521095 Polyglot Persistence -Ayende on RavenDb


https://vimeo.com/156551919 - ES 2015: The next javascript version today


Not NDC London, but another NDC event (security day) had several Troy Hunt security talks. Some repetition over the his other talks (e.g. https://vimeo.com/153220272 50 Shades of AppSec), but watch these anyway for a very entertaining and informative introduction to security

https://vimeo.com/154962595 Web Security Essentials by Example
https://vimeo.com/154956509 Both Sides of the Attack
https://vimeo.com/154958732 Lessons from 220 Million Breached Records

posted on Thursday, February 25, 2016 7:54:25 PM (Romance Standard Time, UTC+01:00)  #    Comments [0]
# Monday, February 08, 2016

Not all videos are up yet, a few I may add in a second link dump. I saw most of these live, but several are worth seeing again. See also my slides/github rep link dump

https://vimeo.com/153745433 - The changing state of immutability C# - Jon Skeet
https://vimeo.com/153900560 - What does an "Open Source Microsoft Web Platform look like?" - Scott Hanselman
https://vimeo.com/154034601 - A brief history of ASP.NET: From 1.0 to 5.0 - Damian Edwards and David Fowler

https://vimeo.com/153220272 - Troy Hunt, 50 Shades of AppSec
https://vimeo.com/153908385 - Making Hacking Child's Play - Troy Hunt
https://vimeo.com/154041158 - What's new in Security in ASP.NET 5 and MVC 6 - Dominick Baier
https://vimeo.com/154172925 - Introduction to IdentityServer - Brock Allen (not actually asp 5)
https://vimeo.com/153102690 - .Net Core Authorization Stack - Barry Dorrans

.Net Core (Asp.Net 5 at the time!)
https://vimeo.com/153212604 - .Net Core CLI, Damian Edwards and David Fowler
https://vimeo.com/153749266 - Middleware introduction - Scott Allen

https://vimeo.com/154049610 - Knowledge Work Culture - Michael Norton
https://vimeo.com/154312751 - Testing with No Harm - Enrico Campidoglio
https://vimeo.com/154301830 - Case Studies in Terrible Testing - Todd Gardner

https://vimeo.com/154588594 - Docker - Mark Rendle
https://vimeo.com/154025470 - Mark Rendle, Everything I know about computers, I learned from the movies

posted on Monday, February 08, 2016 8:30:21 PM (Romance Standard Time, UTC+01:00)  #    Comments [0]

Note: this is written in February 2016. If you read this in summer 2016 or later, it's ancient history, just ignore.

There's a lot of buzz about the new Asp.Net Core (previously Asp.Net 5) - blog posts, articles and tweets from enthusiastic developers.

It's nice to see Microsoft being open, and to be able to see the git pull requests. RC1 is out and it has a "Go Live" license- Microsoft says you start using it in production.

Don't use this in production. Don't start your next project with it. You probably don't want to spend too much time playing with it for a few months. It's not ready. It's still changing.

As of start February 2016, the blogs and the official docs still refer to "dnx" and "dnu", which will be as dead as the old "k" stuff from a year ago. Want to try the new "dotnet.exe"? All you can do is a "hello world" console with this: http://dotnet.github.io/getting-started/. The promise is great- this will integrate with the .net native efforts, which for now is vapourware. You can't use it with asp.net core yet, even if you take the unstable RC2 packages- the work hasn't been done (check those pull requests). The best information about it was at the NDC conference (video now available).

There's a lot of changes in MVC APIs between RC1 and the unstable RC2 stuff - and there's more changes coming. There's little or no documentation about it yet outside of the github issues and raw pull requests.

Even the project.json structure will be changing. The tooling packages that got lumped in with runtime references in "dependencies" may be separated into "tools", and there may be other changes. The "dnx451" and "dnxcore50" targets are being renamed (I think to "net" and "netstandardapp"). There's some discussion about this (see the video), but as yet nothing is committed to github, let alone documented.

The visual studio tooling is still incomplete and weak. The only testing framework is XUnit (still via a MS fork I think). We've known for some time that Entity Framework Core (was EF7) won't be fully ready even at release (the big one: no lazy loading; "the lack of these features will make EF6.x a better option"). The ADO GetSchema side (needed for any other ORM) has only just started to get a design.

RC1 is nowhere near being what we'd normally call a "release candidate". RC2 might be feature complete- but there's still a lot of churn going on. RC2 was planned for end February 2016 (with RTM end March), but the dates have recently changed to "TBD".

Unless you're working on a popular nuget library, I don't think it's worth investing much time playing with or learning Asp.Net Core just yet. After we get a stable RC2 we can play with the new toys. For "real work", ignore any more "Go Live" licenses - wait until the RTM. I suspect it may be sensible to wait until v1.1 until shifting fully into the new framework.

The multi-targeting (windows/max/linux) is a nice new feature, but no-one is going to ditch all their windows servers. Some of us remember similar things being said about Silverlight, and a few people jumped for that too. My inclination is to dump the restricted "dot net core" experience and run it on full .net 4.6 framework so we can use EF 6, existing libraries and ADO providers, but still benefit from xproj and the new asp stack. Fortunately that's a nice "transitional" story.

Don't get me wrong - this is a positive direction for .net, with lots of very welcome changes. But it's a huge change which is still ongoing. The new open source Microsoft, coupled with some clumsy marketing, means we're looking at something not fully cooked. If you're enthusiastic about the new changes, save yourself some frustration and wait a few more months.

posted on Monday, February 08, 2016 6:38:21 PM (Romance Standard Time, UTC+01:00)  #    Comments [0]
# Tuesday, January 26, 2016

VS 2015 Update 1 had big problems on one of my machines.

This was helpful: How to restore Visual Studio 2015 after the Update 1 (dependency dance)

A MS engineering guy has a full solution (basically a new devenv.config): here

posted on Tuesday, January 26, 2016 10:13:31 AM (Romance Standard Time, UTC+01:00)  #    Comments [0]
# Tuesday, January 19, 2016

A link dump (slides and source) from NDC London, January 2016

ASP.Net 5

Workshop by David Fowler, Damian Edwards. See docs: https://docs.asp.net/en/latest/

Asp.Net 5 authorization workshop by Barry Dorrans

Asp.net 5 Razor taghelpers
Source code: https://github.com/aspnet/Mvc/tree/dev/src/Microsoft.AspNet.Mvc.TagHelpers

Asp.Net 5 Security - slides, by Barry Dorrans

Dominick Baier on Asp 5/MVC6 security

Brock Allen introduction to Identity Server

Other .net

Jon Skeet on immutability in .net

Ian Cooper on service discovery

https://vimeo.com/144824826 - Video of Jimmy Bogard's "Full Stack REST" talk, from another conference (Nov 2015)


https://speakerdeck.com/tastapod/business-mapping - Dan North on Business Mapping
Agile doesn't scale, so this maps people skills (and aspirations) to business KPIs

http://www.slideshare.net/Kevlin/solid-deconstruction - Kelvin Henney on SOLID (yes, open/closed is confusing, but it's really just don't publish public API prematurely)

http://bodil.lol/generators/#0 - Bodil Stokke on Javascript generators

posted on Tuesday, January 19, 2016 1:21:31 PM (Romance Standard Time, UTC+01:00)  #    Comments [0]
# Monday, January 11, 2016

I'm at the NDC London conference, doing the Asp.net 5 introduction by Microsoft's Damian Edwards and David Fowler, who are the guys leading the team writing it. I've downloaded a couple of previous milestones, but it was clear the API was changing radically, so I didn't follow too closely. Now we're on release candidate 1, with 2 due in Feb and the final release at the end of March 2016.

Workshop files are here: https://github.com/damianedwards/aspnet5-workshop

Asp.Net 5 docs are here: https://docs.asp.net/en/latest/

My first impressions from the first day:

It's still changing a lot- we're working off the CI builds nuget feeds, so it's RC1+update 1+lots of changes. RC2 has some big changes still to do, including renaming stuff. It's still too early to start playing in depth, let alone thinking about doing real work in it. There's a lot that isn't there at all. Surprisingly, no MsTest, you have to use XUnit.

But. it's not long until it will be out. And it has some major changes, as big a shift as MVC was from web forms. Developers will have to spend a lot of time learning a new framework.

Asp MVC and WebApi are pretty stable, simple and powerful, but System.Web is a huge beast with legacy going back to ASP classic compatibility. Asp 5 doesn't use System.Web, although some concepts are copied over (there's still something called HttpContext, it just has a lot less in it). So it's faster, more consistent, more portable - for cloud, and cross-platform.

The main changes (from the first day):

There's a new project structure. The website is built into a wwwroot folder - the old VS publish is redundant. On the solution level, there's a global.json (the project list), although .sln still exists. On the project level, there's a project.json and (not seen in VS) an .xproj file that between them replace the .csproj. You can also add other json files- hosting, appsettings.

It's based on nuget packages, so it's easily deployed side-by-side. This downside is the packages are very granular and manual. Visual Studio auto-suggests from nuget feeds while entering the dependencies in project.json. To make it easier, there will be standard packages with simple names that bring in a bunch of other packages (but they aren't there yet). On the MVC level, the Microsoft.AspNet.Mvc package is probably the one you want, unless you want to individually reference Microsoft.AspNet.Mvc.Core and half a dozen other packages for the precise combination of features you're using. Still, we've swapped dll hell for version hell when packages start updating independently.

There is a plan for zero day patching from Windows Update (presumably this is where the GAC comes back). The proposal is that packages are supported for 12 months- so when an update comes out, you have a year to update. In most organizations, applications get released and the team disperses, and no updates are ever done. With Asp.net 5, that could be a problem.

It's bootstrapped just like a classic console- with a public static void Main(string[] args) method. (This was hidden away in IIS before). IIS will now use the static void Main, and more things get done in asp and it's Kestrel server (Kestrel now sits behind IIS, as well as being able to run standalone. HttpListener sounds like it's gone).

Dependency Injection is built in and pervasive. It's used when configuring your asp.net 5 environment, in preference to base classes or interfaces.  In controllers it's not too bad, but in your startup class and middleware you don't have any way to discover what you can do. You have a Configure method which is magically called with the arguments you specify- say, an IApplicationBuilder or an ILoggerFactory. We're going to be relying on the documentation website (and I hope the docs cover updates and and are versioned.)

posted on Monday, January 11, 2016 10:33:05 PM (Romance Standard Time, UTC+01:00)  #    Comments [0]
# Tuesday, August 04, 2015
One of my 4 machines immediately offered to upgrade to Windows 10. The rest are just sitting there, probably because Microsoft is stacking up upgrades over weeks or months.

It's simple to force an update.

Use the Windows 10 media creation tool: http://www.microsoft.com/en-us/software-download/windows10
Download it (it's 18Meg), and run it. Select "Upgrade this PC now". It downloads the multiple Gigs of Win10, then installs.

Privacy settings

Near the end of installation, there will be a screen "Get Going Fast" with the default button "Use Express Settings". Instead click the small link "Customise settings" (it's "Customize" in US versions, "Customise" in UK).

On "Customise Settings" first page, turn off "use page prediction" (2nd option), and at least the first 2 "Connectivity" options below that (automatically connect to open hotspots, networks shared by contacts).
"Smartscreen" and "Send error and diagnostic information" are acceptable.

On "Customise Settings" second page ("Personalisation" and "Location"), turn off all of them.

If you use a local account, it will show "Make it yours" which will convert you to a Microsoft (hotmail/outlook.com) account. Click the small link at the bottom "Skip this step".

Edge is the default browser

Settings > System > Default apps
You can change the Browser, Music, Photo and other defaults here.

Chrome and Firefox will both complain they are no longer default browser- Windows 10 will open the default apps page for you.


Settings is the new control panel. If you followed the defaults, you can fix them here

If you accidentally switched to a Microsoft account, Accounts > Your account > "Sign in with a local account instead".

In Privacy, fix the options under "General", "Location", and "Speech, inking and typing".

In Network & Internet > Wi-Fi > Manage Wi-Fi Settings > "Wi-Fi Sense" turn off both options (Connect to open hotspots, connect to networks shared by contacts).

In Update & Security > Windows Update > Advanced Options > Choose how updates are delivered > make sure you don't use "PCs on my local network, and PCs on the internet" (the "PCs on my local network" should be okay on a home network).

posted on Tuesday, August 04, 2015 9:17:38 AM (Romance Daylight Time, UTC+02:00)  #    Comments [0]
# Sunday, March 29, 2015

I finally moved my project "database schema reader" from Codeplex to Github.

Github import was simple and quick. I didn't import the historical issues (the project went on Codeplex in 2010, and it was a couple of years old then). I just added an "upstream" remote so I can still push to Codeplex and keep it updated. 

Codeplex comments and discussions are disabled at the moment; "we're anticipating that this functionality will be re-enabled early next week"! The codeplex blog hasn't been updated in 2 years, and the "codeplex" discussions are full of spam (fortunately I've never had spam in the project discussions). There are many third-party services that integrate with Github, but nothing links into Codeplex.

The main advantage of the move to Github was hooking into Appveyor for CI builds. It took a few builds to experiment with things. I'm using database integration tests with SqlServer, SQLite, PostgreSql and MySql. Now these are working, the tests are more portable - I can easily recreate the databases. The packaging of the builds (dlls into a zip, plus a nuget packages) was also easy, and can create releases within Github. The appveyor.yml file isn't the easiest way to configure builds, and I soon figured out it's better to use the website UI.

Overall, much better than TFS (ugh!) and TeamCity builds. I played a little with Travis CI (building in Mono), but for now it's not worth pursuing.

I tried Coverity for code analysis, which flagged a few (minor) things, but didn't seem to add a lot more than FxCop.

I looked at Coveralls,  a code coverage service. Code coverage is 77%, incidentally, which I think is quite good for something that includes code to support Oracle, DB2, Ingres, 3 different Sybase databases, VistaDb, Firebird and Intersystems Cache (for now, these must continue to be tested on my machine only.). I don't believe code coverage is very useful, so for now I won't include this into the Appveyor build.

I'm very impressed, and very happy with Appveyor.

posted on Sunday, March 29, 2015 5:41:03 PM (Romance Daylight Time, UTC+02:00)  #    Comments [0]