Initial component setup

.gitattributes

@@ -0,0 +1,63 @@
+###############################################################################
+# Set default behavior to automatically normalize line endings.
+###############################################################################
+* text=auto
+
+###############################################################################
+# Set default behavior for command prompt diff.
+#
+# This is need for earlier builds of msysgit that does not have it on by
+# default for csharp files.
+# Note: This is only used by command line
+###############################################################################
+#*.cs     diff=csharp
+
+###############################################################################
+# Set the merge driver for project and solution files
+#
+# Merging from the command prompt will add diff markers to the files if there
+# are conflicts (Merging from VS is not affected by the settings below, in VS
+# the diff markers are never inserted). Diff markers may cause the following 
+# file extensions to fail to load in VS. An alternative would be to treat
+# these files as binary and thus will always conflict and require user
+# intervention with every merge. To do so, just uncomment the entries below
+###############################################################################
+#*.sln       merge=binary
+#*.csproj    merge=binary
+#*.vbproj    merge=binary
+#*.vcxproj   merge=binary
+#*.vcproj    merge=binary
+#*.dbproj    merge=binary
+#*.fsproj    merge=binary
+#*.lsproj    merge=binary
+#*.wixproj   merge=binary
+#*.modelproj merge=binary
+#*.sqlproj   merge=binary
+#*.wwaproj   merge=binary
+
+###############################################################################
+# behavior for image files
+#
+# image files are treated as binary by default.
+###############################################################################
+#*.jpg   binary
+#*.png   binary
+#*.gif   binary
+
+###############################################################################
+# diff behavior for common document formats
+# 
+# Convert binary document formats to text before diffing them. This feature
+# is only available from the command line. Turn it on by uncommenting the 
+# entries below.
+###############################################################################
+#*.doc   diff=astextplain
+#*.DOC   diff=astextplain
+#*.docx  diff=astextplain
+#*.DOCX  diff=astextplain
+#*.dot   diff=astextplain
+#*.DOT   diff=astextplain
+#*.pdf   diff=astextplain
+#*.PDF   diff=astextplain
+#*.rtf   diff=astextplain
+#*.RTF   diff=astextplain

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,29 @@
+*IF BUG, INCLUDE THIS PART:*
+
+### Steps to reproduce
+
+1.
+2.
+3.
+
+Platform:
+.NET version:
+
+### Expected behaviour
+
+Tell us what should happen
+
+### Actual behaviour
+
+Tell us what happens instead
+Can you also include a screen shot?
+
+
+
+*IF IT IS A NEW FEATURE REQUEST, INCLUDE THIS PART:*
+
+### Feature description
+
+Write a description of the feature. How should it work? How should it look?
+Include some graphics if this could help!
+

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,14 @@
+Fixes # .
+
+### Checklist
+
+- [ ] I have included examples or tests
+- [ ] I have updated the change log
+- [ ] I am listed in the CONTRIBUTORS file
+- [ ] I have cleaned up the commit history (use rebase and squash)
+
+### Changes proposed in this pull request:
+
+-
+-
+-

.gitignore

@@ -0,0 +1,124 @@
+## Ignore Visual Studio temporary files, build results, and
+## files generated by popular Visual Studio add-ons.
+
+# User-specific files
+*.suo
+*.user
+*.sln.docstates
+
+.nuget/
+tools/FAKE/
+build-log.xml
+Nuget.key
+TestResult.xml
+
+# Build results
+[Bb]in/
+[Cc]lientbin/
+[Dd]ebug/
+[Rr]elease/
+[Oo]utput*/
+[Pp]ackages*/
+bin
+obj
+[Ll]ib/
+*.ide/
+*_i.c
+*_p.c
+*.ilk
+*.meta
+*.obj
+*.orig
+*.pch
+*.pdb
+*.pgc
+*.pgd
+*.rsp
+*.sbr
+*.tlb
+*.tli
+*.tlh
+*.tmp
+*.vspscc
+*.xap
+.builds
+
+# Visual C++ cache files
+ipch/
+*.aps
+*.ncb
+*.opensdf
+*.sdf
+
+# Visual Studio profiler
+*.psess
+*.vsp
+
+# ReSharper is a .NET coding add-in
+_ReSharper*
+*.resharper.user
+
+# Catel
+CatelLogging.txt
+
+# Dotcover
+*.dotCover
+*.dotsettings.user
+
+# Finalbuilder
+*.fbl7
+*.fb7lck
+*.fbpInf
+
+# Ghostdoc
+*.GhostDoc.xml
+
+# Deployments
+deployment/FinalBuilder/backup
+deployment/InnoSetup/template/templates
+deployment/InnoSetup/template/snippets
+deployment/InnoSetup/template/libraries
+deployment/InnoSetup/template/doc
+
+# Installshield output folder 
+[Ee]xpress
+
+# DocProject is a documentation generator add-in
+DocProject/buildhelp/
+DocProject/Help/*.HxT
+DocProject/Help/*.HxC
+DocProject/Help/*.hhc
+DocProject/Help/*.hhk
+DocProject/Help/*.hhp
+DocProject/Help/Html2
+DocProject/Help/html
+
+# Click-Once directory
+publish
+
+# Others
+[Bb]in
+[Oo]bj
+sql
+TestResults
+*.Cache
+ClientBin
+stylecop.*
+~$*
+*.dbmdl
+Generated_Code #added for RIA/Silverlight projects
+
+# Backup & report files from converting an old project file to a newer
+# Visual Studio version. Backup files are not needed, because we have git ;-)
+_UpgradeReport_Files/
+Backup*/
+UpgradeLog*.XML
+
+# Windows image file caches
+Thumbs.db 
+
+# Folder config file
+Desktop.ini
+
+# mstest test results
+TestResults

AUTHORS

@@ -0,0 +1,12 @@
+# This is the official list of authors for copyright purposes.
+# This file is distinct from the CONTRIBUTORS file.
+# See the latter for an explanation.
+
+# Names should be added to this file as
+#	Name or Organization <email address>
+# The email address is not required for organizations.
+
+# Please keep the list sorted.
+# Please notify the first person on the list to be added here.
+
+WildGums

CONTRIBUTING.md

@@ -0,0 +1,95 @@
+Contributors
+============
+
+## Contributing Process
+
+### Get Buyoff Or Find Open Community Issues/Features
+
+ * Through [GitHub](https://github.com/WildGums/Orc.CsvTextEditor/issues), or through the [Chat Room](https://gitter.im/WildGums/Orc.CsvTextEditor) (preferred), you talk about a feature you would like to see (or a bug), and why it should be included.
+   * If approved through the Chat Room, ensure the accompanying issue is created with information and a link back to the Chat Room discussion.
+ * Once you get a nod you can start on the feature.
+
+### Set Up Your Environment
+
+ * You create, or update, a fork of https://github.com/WildGums/Orc.CsvTextEditor under your GitHub account.
+ * From there you create a branch named specific to the feature.
+ * In the branch you do work specific to the feature.
+ * Please also observe the following:
+    * No reformatting
+    * No changing files that are not specific to the feature
+    * More covered below in the **Prepare commits** section.
+ * Test your changes and please help us out by updating and implementing some automated tests. It is recommended that all contributors spend some time looking over the tests in the source code. You can't go wrong emulating one of the existing tests and then changing it specific to the behavior you are testing.
+ * Please do not update your branch from the master unless we ask you to. See the responding to feedback section below.
+
+### Prepare Commits
+
+This section serves to help you understand what makes a good commit.
+
+A commit should observe the following:
+
+ * A commit is a small logical unit that represents a change.
+ * Should include new or changed tests relevant to the changes you are making.
+ * No unnecessary whitespace. Check for whitespace with `git diff --check` and `git diff --cached --check` before commit.
+ * You can stage parts of a file for commit.
+
+A commit message should observe the following:
+
+  * The first line of the commit message should be a short description around 50 characters in length and be prefixed with the issue it refers to with parentheses surrounding that. If the issue is #25, you should have `#25` prefixed to the message.
+  * If the commit is about documentation, the message should be prefixed with `(doc)`.
+  * If it is a trivial commit or one of formatting/spaces fixes, it should be prefixed with `(maint)`.
+  * After the subject, skip one line and fill out a body if the subject line is not informative enough.
+  * The body:
+    * Should indent at `72` characters.
+    * Explains more fully the reason(s) for the change and contrasts with previous behavior.
+    * Uses present tense. "Fix" versus "Fixed".
+
+A good example of a commit message is as follows:
+
+```
+#7 Improve initialization performance
+
+Previously the initialization took 400 ms and had a severe impact
+on the startup of an application. This commit brings the initialization
+time back to 35 ms.
+```
+
+### Submit Pull Request (PR)
+
+Prerequisites:
+
+ * You are making commits in a feature branch.
+ * All specs should be passing.
+
+Submitting PR:
+
+ * Once you feel it is ready, submit the pull request to the `WildGums/Orc.CsvTextEditor` repository against the ````develop```` branch ([more information on this can be found here](https://help.github.com/articles/creating-a-pull-request)).
+ * In the pull request, outline what you did and point to specific conversations (as in URLs) and issues that you are are resolving. This is a tremendous help for us in evaluation and acceptance.
+ * Once the pull request is in, please do not delete the branch or close the pull request (unless something is wrong with it).
+ * One of the Team members, or one of the committers, will evaluate it within a reasonable time period (which is to say usually within 0-2 weeks). Some things get evaluated faster or fast tracked. We are human and we have active lives outside of open source so don't fret if you haven't seen any activity on your pull request within a month or two. We don't have a Service Level Agreement (SLA) for pull requests. Just know that we will evaluate your pull request.
+
+### Respond to Feedback on Pull Request
+
+We may have feedback for you to fix or change some things. We generally like to see that pushed against the same topic branch (it will automatically update the Pull Request). You can also fix/squash/rebase commits and push the same topic branch with `--force` (it's generally acceptable to do this on topic branches not in the main repository, it is generally unacceptable and should be avoided at all costs against the main repository).
+
+If we have comments or questions when we do evaluate it and receive no response, it will probably lessen the chance of getting accepted. Eventually this means it will be closed if it is not accepted. Please know this doesn't mean we don't value your contribution, just that things go stale. If in the future you want to pick it back up, feel free to address our concerns/questions/feedback and reopen the issue/open a new PR (referencing old one).
+
+Sometimes we may need you to rebase your commit against the latest code before we can review it further. If this happens, you can do the following:
+
+ * `git fetch upstream` (upstream would be the mainstream repo or `WildGums/Orc.CsvTextEditor` in this case)
+ * `git checkout develop`
+ * `git rebase upstream/develop`
+ * `git checkout your-branch`
+ * `git rebase develop`
+ * Fix any merge conflicts
+ * `git push origin your-branch` (origin would be your GitHub repo or `your-github-username/Orc.CsvTextEditor` in this case). You may need to `git push origin your-branch --force` to get the commits pushed. This is generally acceptable with topic branches not in the mainstream repository.
+
+The only reasons a pull request should be closed and resubmitted are as follows:
+
+  * When the pull request is targeting the wrong branch (this doesn't happen as often).
+  * When there are updates made to the original by someone other than the original contributor. Then the old branch is closed with a note on the newer branch this supersedes the issue.
+
+## Other General Information
+
+If you reformat code or hit core functionality without an approval from a person on the Team, it's likely that no matter how awesome it looks afterwards, it will probably not get accepted. Reformatting code makes it harder for us to evaluate exactly what was changed.
+
+If you do these things, it will be make evaluation and acceptance easy. Now if you stray outside of the guidelines we have above, it doesn't mean we are going to ignore your pull request. It will just make things harder for us.  Harder for us roughly translates to a longer SLA for your pull request.

CONTRIBUTORS

@@ -0,0 +1,13 @@
+# This is the official list of people who have contributed
+# to this repository.
+# The AUTHORS file lists the copyright holders; this file
+# lists people.
+
+# People submitting code should be listed in this file (by email address).
+
+# Names should be added to this file like so:
+#     Name <email address>
+
+# Please keep the list sorted.
+
+Geert van Horrik <[email protected]>

GitVersionConfig.yaml

@@ -0,0 +1,3 @@
+mode: ContinuousDeployment
+assembly-versioning-scheme: MajorMinorPatch 
+next-version: 1.0.0

LICENSE

@@ -1,6 +1,6 @@
-MIT License
+The MIT License (MIT)
 
-Copyright (c) 2017 WildGums
+Copyright (c) 2014-2017 WildGums
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
@@ -19,3 +19,18 @@ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
+
+==============================================================================
+
+Additional licenses / components
+--------------------------------
+
+Some parts are based on other open-source components. Each component that is based 
+on another component has a reference to the original component including the original 
+license the code was delivered upon. Below is a list of other components / licenses.
+
+Note: if you feel an item is missing in this list, please let us know!
+
+* Catel
+  https://github.com/catel/catel
+  Original license: MIT