What should we do about Env.cs

[CharliePoole]

Now that we no longer have CF and Silverlight integrated, Env.cs is no longer doing much. It defines:

• Newline which is always equal to Environment.Newline

• DocumentFolder which maps to \MyDocuments in portable and to the special documents folder in all other builds.

• DefaultWorkDirectory which maps to DocumentFolder in portable and to Environment.CurrentDirectory in other builds.

In the case of NewLine, we are already somewhat inconsistent. There are 24 references to both Env and Environment scattered around. The other two are referenced, respectively, zero and 3 times!

Options:

• Leave file as is
• Remove Env.NewLine
• Remove file entirely

[oznetmaster]

Since there are still compatibility differences in Environment between portable and all other builds, it seems that Env should still be the standard for all builds, and all references to Environment should be removed.

Alternatively, the references to DocumentFolder and DefaultWorkDirectory can be conditioned for the portable build. However, I thought the current preference was to eliminate conditions wherever possible. Using Env does that.

[rprouse]

I think we should remove Env.Newline and Env.DocumentFolder if it is not used. I think I would prefer to leave DefaultWorkDirectory for now, although we could move it elsewhere. I only want to leave it until we see how .NET Standard shakes out, but I don't have strong feelings on that.

[CharliePoole]

@oznetmaster Of course there are other Environment fields we use that are not reflected in Env.cs - it only contains those three entries. I think I prefer removing NewLine, since it no longer serves a purpose, and DocumentFolder, since it's unused.

I think it generally works better to have a central definition most of the time, but with only three conditionals needed to eliminate it, that might be the better approach.

@rprouse does net standard support NewLine and CurrentDirectory?

[oznetmaster]

Sorry, I was not thinking. My CF build uses a custom Environment class which is 100% compatible with the standard .NET Environment, so I have never really paid attention to Env. Given what @rprouse and you have indicated, I would think that removing Env entirely and conditioning the portable build where required would make the most sense. Leaving Env for a single field seems the lesser alternative, although that would work too.

[rprouse]

.NET Standard has Environment.NewLine and Directory.GetCurrentDirectory(), but not Environment.CurrentDirectory

[CharliePoole]

This is so low-hanging, I decided to just do it.