GitHub Repository doc updates + NuGet.config uniformity (#188)

Author: cheenamalhotra

CODE_OF_CONDUCT.md

@@ -0,0 +1,5 @@
+# Code of Conduct
+
+This project has adopted the code of conduct defined by the Contributor Covenant
+to clarify expected behavior in our community.
+For more information, see the [.NET Foundation Code of Conduct](https://dotnetfoundation.org/code-of-conduct).

CONTRIBUTING.md

@@ -0,0 +1,80 @@
+# Contributing to Microsoft.Data.SqlClient
+
+General contribution guidance is included in this document. Additional guidance is defined in the documents linked below.
+
+- [Copyright](copyright.md) describes the licensing practices for the project.
+- [Contribution Workflow](contributing-workflow.md) describes the workflow that the team uses for considering and accepting changes.
+
+## Up for Grabs
+
+The team marks the most straightforward issues as "up for grabs". This set of issues is the place to start if you are interested in contributing but new to the codebase.
+
+- [dotnet/sqlclient - "up for grabs"](https://github.com/dotnet/sqlclient/labels/Up-for-Grabs)
+
+## Contribution "Bar"
+
+Project maintainers will merge changes that improve the product significantly and broadly and that align with the [Microsoft.Data.SqlClient roadmap](https://github.com/dotnet/sqlclient/blob/master/roadmap.md).
+
+Contributions must also satisfy the other published guidelines defined in this document.
+
+## DOs and DON'Ts
+
+Please do:
+- **DO** report each issue as a new issue (but check first if it's already been reported)
+- **DO** respect Issue Templates and provide detailed information. It will make the process to reproduce the issue and provide a fix faster.
+- **DO** provide a minimal repro app demonstrating the problem in isolation will greatly speed up the process of identifying and fixing problems.
+- **DO** follow our [coding style](coding-style.md) (C# code-specific) when working on a Pull Request.
+- **DO** give priority to the current style of the project or file you're changing even if it diverges from the general guidelines.
+- **DO** consider cross-platform compatibility and supportability for all supported SQL and Azure Servers and client configurations.
+- **DO** include tests when adding new features. When fixing bugs, start with adding a test that highlights how the current behavior is broken.
+- **DO** consider concurrency when writing tests. Our pipelines run builds and tests in parallel using the same client and server configurations (in an isolated mode). E.g. Consider using dynamic table/database object names instead of hardcoded values (Use existing tests for reference).
+- **DO** keep the discussions focused. When a new or related topic comes up it's often better to create new issue than to side track the discussion.
+- **DO** blog and tweet (or whatever) about your contributions, frequently!
+
+Please do not:
+
+- **DON'T** make PRs for style changes.
+- **DON'T** leave any artifacts on server in tests or leave open resources. Cleaning up all objects is highly appreciated to maintain test server health.
+- **DON'T** skip tests or run them conditionally unless necessary. If conditions are not met, test coverage will not be 100%. Use only pre-defined conditions that are already being run in pipelines.
+- **DON'T** surprise us with big pull requests. Instead, file an issue and start a discussion so we can agree on a direction before you invest a large amount of time.
+- **DON'T** commit code that you didn't write. If you find code that you think is a good fit to add, file an issue and start a discussion before proceeding.
+- **DON'T** submit PRs that alter licensing related files or headers. If you believe there's a problem with them, file an issue and we'll be happy to discuss it.
+
+## Using Labels
+
+We encourage adding appropriate labels to issues and pull requests to allow filtering and analysis effectively. The below variables are required for new Pull Requests if applicable:
+
+| Label | Description |
+| ----- | ----------- |
+| [Public API](https://github.com/dotnet/SqlClient/labels/Public%20API) | Use this variable if a new Public API is added to the Pull Request.
+| [Breaking Change](https://github.com/dotnet/SqlClient/labels/Breaking%20Change) | Use this variable if the Pull Request breaks an existing API. |
+| [Backport to CoreFx](https://github.com/dotnet/SqlClient/labels/Backport%20to%20CoreFx) | Use this variable if the Issue/Pull Request needs to be backported to System.Data.SqlClient in [dotnet/corefx](https://github.com/dotnet/corefx) |
+| [Managed SNI](https://github.com/dotnet/SqlClient/labels/Managed%20SNI) | Use this label if the issue/PR relates to issues in Managed SNI |
+| [Tests](https://github.com/dotnet/SqlClient/labels/Tests) | Use this label for pull requests that add only tests to the repository. |
+
+## Reporting security issues and security bugs
+
+Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC) [[email protected]](mailto:[email protected]). You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the [Security TechCenter](https://technet.microsoft.com/en-us/security/ff852094.aspx).
+
+## File Headers
+
+The following file header is used for Microsoft.Data.SqlClient. Please use it for new files.
+
+```csharp
+// Licensed to the .NET Foundation under one or more agreements.
+// The .NET Foundation licenses this file to you under the MIT license.
+// See the LICENSE file in the project root for more information.
+```
+
+## Contributor License Agreement
+
+You must sign a [.NET Foundation Contribution License Agreement (CLA)](https://cla.dotnetfoundation.org) before your PR will be merged. This is a one-time requirement for projects in the .NET Foundation. You can read more about [Contribution License Agreements (CLA)](http://en.wikipedia.org/wiki/Contributor_License_Agreement) on Wikipedia.
+
+The agreement: [net-foundation-contribution-license-agreement.pdf](https://github.com/dotnet/home/blob/master/guidance/net-foundation-contribution-license-agreement.pdf)
+
+You don't have to do this up-front. You can simply clone, fork, and submit your pull-request as usual. When your pull-request is created, it is classified by a CLA bot. If the change is trivial (for example, you just fixed a typo), then the PR is labelled with `cla-not-required`. Otherwise it's classified as `cla-required`. Once you signed a CLA, the current and all future pull-requests will be labelled as `cla-signed`.
+
+## Code Of Conduct
+
+This project has adopted the code of conduct defined by the Contributor Covenant to clarify expected behavior in our community.
+For more information, see the [.NET Foundation Code of Conduct](https://dotnetfoundation.org/code-of-conduct).

COPYRIGHT.md

@@ -0,0 +1,9 @@
+# Copyright
+
+## Source License
+
+- The [MIT License](LICENSE) is used by this repository for [source code](https://github.com/dotnet/sqlclient/).
+
+## Binary License
+
+- **Microsoft.Data.SqlClient** binary distributions (nuget packages) are licensed as MIT (identical to the [Microsoft.Data.SqlClient source license](https://github.com/dotnet/sqlclient/blob/master/LICENSE)).

README.md

@@ -26,46 +26,22 @@ For the .NET Framework driver on Windows, a package reference to [Microsoft.Data
 
 For the .NET Core driver on Windows, a package reference to [runtime.native.System.Data.SqlClient.sni](https://www.nuget.org/packages/runtime.native.System.Data.SqlClient.sni/) loads `arm64`, `x64` and `x86` platform specific `SNI.dll` libraries into the client's build directories.
 
-## Building the Driver
-
-All necessary details and commands for building the driver and running tests are available in the [BUILDGUIDE](BUILDGUIDE.md).
+## Helpful Links
+
+| Topic | Link to File |
+| :---- | :------------- |
+| Coding Style | [coding-style.md](coding-style.md) |
+| Guidelines for building the driver | [BUILDGUIDE.md](BUILDGUIDE.md) |
+| Guidelines for Contributors | [CONTRIBUTING.md](CONTRIBUTING.md) |
+| Changelog for all driver releases | [CHANGELOG.md](CHANGELOG.md) |
+| Code of Conduct | [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) |
+| Copyright Information | [COPYRIGHT.md](COPYRIGHT.md) |
+| | |
 
 ## Release Notes
 
 All preview and stable driver release notes are available under [release-notes](release-notes).
 
-## Guidelines for Creating Pull Requests
-
-We love contributions from the community. To help improve the quality of our code, we encourage you to follow these guidelines:
-
-- Code changes must adhere to the [C# Programming Guide](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/index).
-- Driver code changes must be done considering cross-platform compatibility and supportability for all supported SQL and Azure Servers and client configurations.
-- Tests must be added if non-existent to assure near to 100% code coverage for all future changes.
-- Tests should be well structured and written well to be able to run in parallel using the same client and server configurations (in an isolated mode). E.g. Consider using dynamic table/database object names instead of hardcoded values (Use existing tests for reference).
-- Tests should not leave any artifacts on the target server. Cleaning up all objects is highly appreciated to maintain test server health.
-- Avoid skipping tests if possible or running them conditionally. If conditions are not met, test coverage will not be 100%.
-
-Thank you!
-
-## Guidelines for Reporting Issues
-
-We appreciate you taking the time to test the driver, provide feedback and report any issues. It would be extremely helpful if you:
-
-- Report each issue as a new issue (but check first if it's already been reported)
-- Try to be detailed in your report. Useful information for good bug reports include:
-  * What you are seeing and what the expected behavior is
-  * The version of the driver in use.
-  * Environment details: e.g. .NET Framework / .NET Core version, client operating system
-  * Table schema (for some issues the data types make a big difference!)
-  * Any other relevant information you want to share
-- Providing a minimal repro app demonstrating the problem in isolation will greatly speed up the process of identifying and fixing problems.
-
-Thank you!
-
-## Reporting security issues and security bugs
-
-Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC) [[email protected]](mailto:[email protected]). You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the [Security TechCenter](https://technet.microsoft.com/en-us/security/ff852094.aspx).
-
 ## Still have questions?
 
 Check out our [FAQ](https://github.com/dotnet/SqlClient/wiki/Frequently-Asked-Questions). Still not answered? Create an [issue](https://github.com/dotnet/SqlClient/issues/new/choose) to ask a question.

build.proj

@@ -4,6 +4,7 @@
   <Import Project="$(ToolsDir)targets\GenerateNugetPackage.targets" />
 
   <PropertyGroup>
+    <RestoreConfigFile>src\NuGet.config</RestoreConfigFile>
     <Configuration Condition="'$(Configuration)' == ''">Debug</Configuration>
     <Platform Condition="'$(Platform)' == ''">AnyCPU</Platform>
     <!-- Flag to control if NetFx driver should be built or not -->
@@ -33,10 +34,6 @@
     <ManualTests     Include="**/ManualTests/SQL/UdtTest/UDTs/Utf8String/Utf8String.csproj" />
     <ManualTests     Include="**/tools/CoreFx.Private.TestUtilities/CoreFx.Private.TestUtilities.csproj" />
     <ManualTests     Include="**/ManualTests/Microsoft.Data.SqlClient.ManualTesting.Tests.csproj" />
-
-    <NugetPackageSources Include="https://api.nuget.org/v3/index.json" />
-    <NugetPackageSources Include="https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json" />
-    <NugetPackageSources Include="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />
   </ItemGroup>
 
   <!-- Top Level Build targets -->

coding-style.md

@@ -0,0 +1,26 @@
+# C# Coding Style
+
+We follow a similar coding style as [dotnet/corefx](https://github.com/dotnet/corefx).
+
+For non code files (xml, etc), our current best guidance is consistency. When editing files, keep new code and changes consistent with the style in the files. For new files, it should conform to the style for that component. If there is a completely new component, anything that is reasonably broadly accepted is fine.
+
+The general rule we follow is "_use Visual Studio defaults_".
+
+1. We use [Allman style](http://en.wikipedia.org/wiki/Indent_style#Allman_style) braces, where each brace begins on a new line. A single line statement block can go without braces but the block must be properly indented on its own line and must not be nested in other statement blocks that use braces. One exception is that a `using` statement is permitted to be nested within another `using` statement by starting on the following line at the same indentation level, even if the nested `using` contains a controlled block.
+2. We use four spaces of indentation (no tabs).
+3. We use `_camelCase` for internal and private fields and use `readonly` where possible. Prefix internal and private instance fields with `_`, static fields with `s_` and thread static fields with `t_`. When used on static fields, `readonly` should come after `static` (e.g. `static readonly` not `readonly static`).  Public fields should be used sparingly and should use PascalCasing with no prefix when used.
+4. We avoid `this.` unless absolutely necessary. 
+5. We always specify the visibility, even if it's the default (e.g. `private string _foo` not `string _foo`). Visibility should be the first modifier (e.g. `public abstract` not `abstract public`).
+6. Namespace imports should be specified at the top of the file, *outside* of `namespace` declarations, and should be sorted alphabetically, with the exception of `System.*` namespaces, which are to be placed on top of all others.
+7. Avoid more than one empty line at any time. For example, do not have two blank lines between members of a type.
+8. Avoid spurious free spaces. For example avoid `if (someVar == 0)...`, where the dots mark the spurious free spaces. Consider enabling "View White Space (Ctrl+E, S)" if using Visual Studio to aid detection.
+9. If a file happens to differ in style from these guidelines (e.g. private members are named `m_member` rather than `_member`), the existing style in that file takes precedence.
+10. We only use `var` when it's obvious what the variable type is (e.g. `var stream = new FileStream(...)` not `var stream = OpenStandardInput()`).
+11. We use language keywords instead of BCL types (e.g. `int, string, float` instead of `Int32, String, Single`, etc) for both type references as well as method calls (e.g. `int.Parse` instead of `Int32.Parse`).
+12. We use PascalCasing to name all our constant local variables and fields. The only exception is for interop code where the constant value should exactly match the name and value of the code you are calling via interop.
+13. We use ```nameof(...)``` instead of ```"..."``` whenever possible and relevant.
+14. Fields should be specified at the top within type declarations.
+15. When including non-ASCII characters in the source code use Unicode escape sequences (\uXXXX) instead of literal characters. Literal non-ASCII characters occasionally get garbled by a tool or editor.
+16. When using labels (for goto), indent the label one less than the current indentation.
+
+An [EditorConfig](https://editorconfig.org "EditorConfig homepage") file (`.editorconfig`) has been provided at the root of the sqlclient repository, enabling C# auto-formatting.