Roslyn: Missing nuget dependency to ManagedEsent / Esent.Interop not found

[ap0llo]

Version Used: 2.0.0-beta5

Steps to Reproduce:

1. Create a project and reference Microsoft.CodeAnalysis 2.0.0-beta5
2. Call MSBuildWorkspace.Create()

Expected Behavior:
A MSBuildWorkspace is created

Actual Behavior:
A ReflectionTypeLoadException exception is thrown. The LoaderExceptions property has more details:
{"Could not load file or assembly 'Esent.Interop, Version=1.9.4.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.":"Esent.Interop, Version=1.9.4.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"}

Manually including the ManagedEsent nuget package in the project fixes the issue. However I suppose the package should be listed in the dependencies of on of the Roslyn nuget packages so it is installed automatically

[Pilchie]

Can you look at either adding this dependency, or making it optional?

[CyrusNajmabadi]

@heejaechang Do you know the right way to author this? I have no idea what the requirements are for Esent.

[KirillOsenkov]

Temporary workaround for now is to manually install the https://www.nuget.org/packages/ManagedEsent/ package.

[KirillOsenkov]

Not sure if it's worth a separate bug, but Workspaces now depends on Elfie and fails to work without it. You need to do something about it before the release otherwise Workspaces won't be usable.

[heejaechang]

@CyrusNajmabadi do what VS.Setup is doing

https://github.com/dotnet/roslyn/blob/master/src/VisualStudio/Setup/project.json

to workspace

[CyrusNajmabadi]

@heejaechang Workspaces.Desktop already has that entry within it.

[Pilchie]

project.json specifies our dependencies for NuGet restore, but doesn't influence the packages we produce.

Instead those come from the nuspec file at https://github.com/dotnet/roslyn/blob/master/src/NuGet/Microsoft.CodeAnalysis.Workspaces.Common.nuspec.

One way to solve this is to add the dependency there. Alternatively, we could potentially make the persistence service be a light-up thing that uses Esent if it is there, or doesn't persist if it isn't there. (Especially since the Esent dependency won't work cross platform AFAIK).

[CyrusNajmabadi]

That should be how persistence is working. We've defined things at the Default workspace layer, and we have an impelmentation at the 'Desktop' layer. The problem here is that MSBuildWorkspace is at the Desktop layer and is trying to load Workspaces.Desktop properly. But that is failing due to the missing references.

[Pilchie]

Right - my point was to make it optional in desktop as well, in case people don't want to deploy esent, and have it generate a bunch of files (where will those go BTW, without the VS workspace service that says where to put the DB)?

[CyrusNajmabadi]

Interesting request. @heejaechang What do you think?

[heejaechang]

ah, I thought we auto-magically discover dependency and auto generate those files. I guess that is not the case.

...

I don't think even if workspace desktop has dependency to esent (by the way, all windows already has esent in box, nothing to deploy except the interop dll which is what managed esent dll is), it will light up. it requires some setting to be there such as where to create the esent files which I believe only set in VS host case. other host, unless workspace host made sure those are set, esent won't light up.

[KirillOsenkov]

The problem is that when composing MEF for the MSBuildWorkspace it does Assembly.GetTypes() on the Workspaces.dll. And the mere fact of enumerating all types requires the Esent.Interop.dll to be there.

Ideally you should have a test that verifies that on a clean machine you can pull the Workspaces NuGet package, install into a C# console app, write a few lines to instantiate the workspace and run it. It should work.

SourceBrowser pretty much is that test right now (and I hit all the issues as the primary consumer of MSBuildWorkspace). It would be nice if the Roslyn team maintained a simple test of MSBuildWorkspace that just loads the Roslyn solution and iterates over all documents. It would be tremendously helpful.

[heejaechang]

I am +1 on making optional host services to be its own dlls including MSBuildWorkspace. due to it, anyone who uses Workspace.Desktop.dll require to have msbuild dependency which has no need at all for people who don't use MSBuildWorkspace.