Fix assembly load when file path contains URI reserved chars

[dibarbet]

Resolves microsoft/vscode-dotnettools#1686

When vscode is installed in (or an extension assembly is loaded from) a path that contains a URI reserved character, the server crashes. This is because VS-MEF (for compatibility with clr behavior) sets the code base to a file URI with an unencoded path.

When parsing the URI, some reserved characters cause the path component to be incorrectly split into query or fragment components if unescaped. Then we get an invalid file path from the URI and cannot load the extension dll.

[jasonmalinowski]

Does this break us cleaning up the temp files later?

[dibarbet]

I didn't see issues, but let me check. I stole this from a compiler test

[jasonmalinowski]

@dibarbet Just generally curious here:

1. Should VS MEF give some alternative here to avoid us having to work around this behavior? Or a common implementation of IAssemblyLoader that smooths this over? Because I imagine DevKit and other extensions would have the same issue, right?
2. Are we able to just avoid using the codebase parameter entirely, in some way?

[dibarbet]

Should VS MEF give some alternative here to avoid us having to work around this behavior? Or a common implementation of IAssemblyLoader that smooths this over? Because I imagine DevKit and other extensions would have the same issue, right?

Possibly. However we do want our own IASsemblyLoader here so we can load assemblies into matching ALCs. So they would have to provide us with some consistent way to get the file path.

I don't think devkit has an issue here because they don't need the codebase to load it into a directory based ALC (we only need it for our extensions).

Are we able to just avoid using the codebase parameter entirely, in some way?

I do not know of one. As best as I can tell it is the only way to get the file path, which we need to put it in the directory ALC.

[jasonmalinowski]

However we do want our own IASsemblyLoader here so we can load assemblies into matching ALCs. So they would have to provide us with some consistent way to get the file path.

Oh we absolutely need one. I was thinking that if we can't change the interface, then instead they could make a base class we inherit from, which implements the interface method and adds whatever magic we're putting here into that. That way at least all the codebase shenanigans are in one repo where we don't have to worry about things getting out of sync.