Will it work with isolated shell redistributables?
Opened this issue · 13 comments
This project looks very promising! But VS as a pre-requisite is a serious drawback.
Is Visual Studio Isolated Shell redistributable enough for VSEmbed to work?
That's a good question!
I've never worked with Isolated Shell, so I don't know for certain.
My path discovery logic (source) probably won't discover Isolated Shell installations.
However, I could add a Load() method that takes a path, allowing you to explicitly load an Isolated Shell installation.
The path must contain all ofthe VS assemblies I consume (every editor DLL & some shell DLLs), devenv.exe (the settings loader takes a path to this), and PrivateAssemblies\Microsoft.VisualStudio.Platform.VSEditor.Interop.dll.
Roslyn will not work, since (I assume) Isolated Shell does not include Roslyn assemblies. (I also use closed-source, non-redistributable Roslyn assemblies like EditorFeatures & MVS.VS.LanguageServices)
Do you know how Isolated Shell installations work? Where are they in the registry?
I also don't know the licensing terms.
It looks like the DLLs are available from here; if that allows independent redist, I could make my own standalone (non-Roslyn) package from those DLLs and a separate loader.
It looks like the license does not allow independent redist:
You may not
- publish the software for others to copy;
Reading further, it looks like you can redistribute the Isolated Shell installer itself, which should be enough for this to work. http://msdn.microsoft.com/en-us/library/bb685514.aspx
I'll experiment with this later.
Thanks for you reply!
I have never worked myself with isolated shell-based projects. I know that they include everything required for building a proper IDE (i.e., editor, toolbox, intellisense, etc), and some real-world IDEs indeed use this. Isolated shell doesn't include VS language packages for C#/VB/F#, however. But that's Roslyn part — parsing, syntax trees, completion services and even solution/project management.
it looks like you can redistribute the Isolated Shell installer itself, which should be enough for this to work.
Yes, that's what I meant, using VS isolated shell redistributable package as a pre-requisite. It's around 180 megabytes, compared to ~4 gigs of VS Express 2013.
I'll experiment with this later.
Thanks a lot! Looking forward to hearing from you.
As I mentioned earlier, Roslyn will not work without a Roslyn-enabled VS installed, even if you get Roslyn from NuGet, because I use a bunch of closed-source, VS-only assemblies to integrate with the editor.
Ah, I've overlooked that, sorry. VS shell redistributable is not enough then...
Note that the basic (non-language-specific) editor will still work fine.
Yes, I understand that, but my main point of interest is Roslyn-based code completion editor for C#.
Looking further, it looks like NuGet might have enough packages to allow Roslyn with a pure Dev14 installation.
https://www.nuget.org/packages/Microsoft.CodeAnalysis.Features/
https://www.nuget.org/packages/Microsoft.VisualStudio.LanguageServices/
Note that Roslyn will not (easily) work on pre-Dev14; it uses new editor APIs for things like code actions (quick fixes).
It might be possible to exclude those and make the core of the Roslyn editors work on earlier versions; I'm not sure.
That may have issues with IntelliSense icons and with changed editor behaviors.
Also, EditorFeatures assembly is in this nuget: Microsoft.CodeAnalysis.EditorFeatures.
So I guess it worth checking out when VS2014 isolated shell package is released.
Thanks for your help!
It looks like those NuGet assemblies were published by mistake and will not be updated.
However, I explored the Isolated Shell v12 and found a surprising number of managed language services (web editors).
I wouldn't be very surprised if the managed Roslyn DLLs ship with Isolated Shell 14. It doesn't looks like there are any previews of Isolated Shell 14, so I guess we'll find out.
LanguageServices package was updated twice so far, so I don't really think that was by mistake. Let's see.
LanguageServices was not by mistake, but Features & EditorFeatures were.