Roslyn: Allow Project to expose information on Resources

[JoshVarty]

I need to emit and run projects from Roslyn workspaces. By default, resources are not emitted into the DLL that Compilation.Emit() produces. There's an argument that accepts multiple ResourceDescription to be embedded into the emitted DLL. However, the Workspace API doesn't offer any information about resources that will allow me to built the appropriate ResourceDescription.

It would be nice if this information was exposed within Project.

Original Stack Overflow Question

[jasonmalinowski]

So, traditionally the Workspace API hasn't included emit-only information, since we don't have a properties to put them anywhere. That said, the scenario isn't terribly unreasonable. @mattwar, thoughts?

[mattwar]

We already jumped that shark with additional documents.

[jasonmalinowski]

So now that we're shark jumping masters, no concerns with this, at least from the design perspective?

[Pilchie]

ping @mattwar is this something you think we should do?

[mattwar]

I think there is a reasonable argument to be made. But I don't think there is enough benefit to justify doing this over other work.

[daveaglick]

I'm currently working on some stuff and hoping to use the MsBuildWorkspace as an alternative to DTE for project information. This issue is the biggest gap I've found so far.

I'd be interested in taking a look at implementing support for additional types of MSBuild items (including resources). It doesn't look like it'll be to hard - basically just mechanically duplicating the code that supports AdditionalFiles ITaskItem to other items.

I'd like to add explicit support for:

• None
• Content
• EmbeddedResource

I think that covers the main MSBuild project items that weren't already available. Would a PR that added support for these items similarly to how AdditionalFiles is handled get consideration?

---

Related to this issue, but probably a separate discussion - it would be nice if the MSBuild workspace/project were leaky and I could access either the Microsoft.Build.Evaluation.Project and/or the Microsoft.Build.Execution.ProjectInstance that are used for the abstraction. Though we can support common cases like above, there's more information in the underlying MSBuild objects that isn't being abstracted. It seems a shame that those objects are being created but we can't actually get to them, especially since creating the ProjectInstance requires actually building the project.