Command names in project.json are case sensistive

[victorhurdugaci]

In my project.json I have:

 "commands": {
        "web": "Microsoft.AspNet.Hosting server.name=Microsoft.AspNet.Server.WebListener server.urls=http://localhost:5002",
        "run": "run server.urls=http://localhost:5003"
    },

If I run

k web

Everything works fine.

However, if I run

k Web

(notice the capital W) I get:

Unhandled Exception: System.AggregateException: One or more errors occurred. ---> System.IO.FileNotFoundException: Could
 not load file or assembly 'Web' or one of its dependencies. The system cannot find the file specified.
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Runtim
eAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntro
spection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Runtime
Assembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntros
pection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, Ru
ntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIn
trospection, Boolean suppressSecurityChecks)
   at System.Reflection.Assembly.Load(AssemblyName assemblyRef)
   at Microsoft.Framework.Runtime.DefaultHost.GetEntryPoint(String applicationName)
   at Microsoft.Framework.ApplicationHost.Program.<ExecuteMain>d__1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

[davidfowl]

Why shouldn't it be?

[Eilon]

We almost never do case-sensitive for keys. Look at routing, config, controller names, file names, etc. I see no reason to have this be case sensitive.

[davidfowl]

I'm not sure I agree, yes other things aren't case insensitive but this seems different. This ain't VB 😄

[HaoK]

why would we want to allow a bunch of Run run RuN RUN commands which all do different things?

[Praburaj]

Typing with an incorrect case is a common mistake most people do. We should avoid throwing.

[davidfowl]

Sorry I just don't agree and I think its broken

[Eilon]

I'm not sure I know of any key value that we use that's case sensitive aside from this... do we have examples where we've previously used case-sensitive dictionaries for stuff that a developer accesses?

[davidfowl]

I think this wild ordinal ignore case we do makes sense in alot of places and it will start to hurt when we try to get things running cross platform. I can understand why we'd want to make this case insensitive but I agree with @HaoK. There's never a case where you'd want different commands with different casing. Our error messages suck right now, is that why this is causing such a big problem?

[Eilon]

I think one way to solve some of the cross-platform issues you're probably thinking of is to normalize strings - e.g. always call .ToLowerInvariant() or similar.

The error today definitely could use some improvement - that could very well be a temporary mitigation and we can evaluate the case sensitivity issue separately.

[davidfowl]

It'll work for most things and will fail whenever we access the file system.

[Eilon]

Yup I get that. We might end up having to make a distinction as to when a key is strictly "in" the system as opposed to a key that leaks back out to the OS/environment.

[davidfowl]

This is fixed