search

microsoft / VSExtensibility

A repo for upcoming changes to extensibility in Visual Studio, the new extensibility model, and language server protocol.
MIT License
365 stars 46 forks source link

VS2022 VSIX DocumentDesigner for Net7 projects #169

Open pallibj opened 1 year ago

pallibj commented 1 year ago

Hi,

I'm a bit lost about what are my options for this case, so I'd really appreciate some input.

What I describe here is a pretty simplified view of my requirements, hoping I can dig my way through my current block.

The use case is to write a VSIX extension for VS2022 which will use a customized DocumentDesigner for designing types in the managed (edited) Projects it will be used for and ALL those projects will be Net7 projects.

The way this was accomplished in Net48 was that the managed Projects referenced a Net48 assembly with the custom DocumentDesigner so when design view was opened for the given types, an instance of the custom DocumentDesigner was instanciated off of that referenced Net48 assembly's custom DocumentDesigner type. With both the VSIX and the referenced assembly as Net48, this worked like a charm.

Now with the requirements being that all the projects to manage will be Net7 projects, things start to get complicated. The referenced assembly containing the custom DocumentDesigner will therefore have to be Net7 targeted. VSIX extensions can ONLY be written using Net48 projects, so the VSIX will be a Net48 environment.

If I go by the previous Net48 approach, the VSPackage environment hosting my VSIX is a Net48 environment and the custom DocumentDesigner is in a Net7 assembly referenced by the project being worked on. When design view is invoked, I don't see how the VSIX environment can create an instance of the custom DocumentDesigner because the VSIX is Net48 and the DocumentDesigner is Net7.

I could potentially move the custom DocumentDesigner to the Net48 VSIX but since that custom designer would need to be able to use Reflection to get information on the designed Net7 type, that would require the Net48 custom DocumentDesigner to be able to runtime load a Net7 assembly and use Reflection on it to obtain the internals of the designed Net7 type. I don't know if this is even possible?

The easiest way out would be if I could write my VSIX as Net7 VSIX, but I can find no information on if that is possible or how to do that.

All help greatly appreciated.

Palli

ghost commented 1 year ago

Yes, please add Net7x support, for VSIX extension projects.

BertanAygun commented 1 year ago

Could you confirm if the designer being extended in this case is the WinForms designer and not WPF? I will have to pass this question to the right team. Visual Studio 2022 is running on .Net Framework so it would not be possible to load assemblies targeting .Net 7 or .Net core libraries.

pallibj commented 1 year ago

Indeed it is the WinForms designer.

ComponentDesigner (https://learn.microsoft.com/en-us/dotnet/api/system.componentmodel.design.componentdesigner?view=windowsdesktop-7.0) is probably the main one.

Palli

pallibj commented 1 year ago

As I see it, this is a blocker for this kind of VSIX development and basically, this currently forces VSIX authors to use NetFramework (4.8.x) based extensions, which is a bit frustrating with Net6/7 being the most attractive target at the moment.

Furthermore, the Out-Of-Process extension model is pretty far out as I understand so it looks like it won't be an option either.

Would it be a correct assumption that with the Out-Of-Process extensibility ready, then the requirement to write your VSIXs as NetFramework based would go away and you could target Net7 for the Out-Of-Process extensions ?

In any case, my development is blocked by this restriction at the moment so it would be nice to know what are the plans and timeframe for this type of development to be fully supported.

Palli

BertanAygun commented 1 year ago

Our goal is to allow interaction between components regardless of the process they run on. Currently even in the new Extensibility SDK where extension runs out-of-process and there was support for designer extensibility, the extension itself wouldn't be running in the same process as .net Core WinForms designer. The new model relies on brokered services streamed across processes to communicate between different components.

On that front, .Net team recently had a blog entry on extending custom controls for .Net Core WinForms designer: https://devblogs.microsoft.com/dotnet/custom-controls-for-winforms-out-of-process-designer/.

Does this cover the scenarios you were interested in? If there are additional scenarios please feel free to include them here and I can pass them along.

Thanks, Bertan

pallibj commented 1 year ago

Bertan,

Thanks for the information.

After a quick browse through this blog, it does indeed look like to be very close to my scenario, if not exactly like it. This is not the shortest blog article out there, so it will take me a while to swallow all of it.

I didn't realize that WinForms design customization capability would be there already so this does change the picture a whole lot.

What about the current state of this out-of-process WinForms design customization capability? Is it in a fully released state, or still in some beta or preview state ?

Palli