Sendgrid-csharp: Improve CI process

[clairernovotny]

As a follow up from #221, creating an issue to track this.

The build process today appears to use Travis CI with Mono and xbuild. xbuild is not the most accurate way to build .NET libraries and has many shortcomings.

The current best way to build libraries for .NET (especially if you want to target .NET Standard for .NET Core support) is via MSBuild.

There are many options, but here's a few:

1. use your own build agent but ensure you have VS 2015 Update 3 Community Edition. You'll likely also want to have the .NET Core tools installed.
2. Use AppVeyor for CI as they have free plans for OSS projects. They have maintained images that have current software on them.

[ajepst]

I have this working on AppVeyor the way the build runs locally... (TRAVIS = false) not sure if that has value for you-seems like it would since you don't have any msbuild-based CI now-if so then I would be happy to clean up what I have and extract out the yml into a pull request pretty quickly (probably tomorrow).

The analogue to the full test with API key like you currently run on Travis is more challenging to get working-I haven't spent a lot of time but initial attempts were failing for me. For all I know there's some critical blocker in what's permitted on AppVeyor ... so it may be doable but I'm not sure yet, and it'll take more time to figure out.

[xt0rted]

@ajepst AppVeyor doesn't set secure environment variables during PR builds to prevent them from showing up in the output log. That might be what you're seeing. Stripe.net had this issue since the test API key is supposed to be private. I'm not sure if he ever found a workaround for it though.

[ajepst]

There's a nice option for that that I believe will work- if you look here in the documentation: https://www.appveyor.com/docs/build-configuration/#configuring-build environment variables are a special case and AppVeyor will merge UI-created environment variables with the yml config, so they _could_ be in as non-secure (so they won't be wiped on PRs), but not in the yml (so they won't be visible in the repo). That won't give you the malicious PR build script protection that AppVeyor intends, of course, but it would be pretty much how you're functioning currently on TravisCI.

In any case, at the moment, I'm not working off a PR build. I've gone ahead and gotten my own key for this experiment and I am trying to run AppVeyor against the master of my own fork, with the key unencrypted in the UI (no yml yet so it's not in my repo, my key is applied to the env var right in the AppVeyor online config like I described in the paragraph above. ) Looks like my current issue has more to do with AppVeyor not liking the background prism process getting kicked off as part of the pre-build... "START /B" is the windows equivalent to the unix "&" used in the Travis script and functions this way on my local machine, but for some reason AppVeyor still looks like it's hanging, waiting for the kicked-off prism process to end before moving on from the pre-build step.

[childish-sambino]

This issue has been added to our internal backlog to be prioritized. Pull requests and +1s on the issue summary will help it move up the backlog.