Release plan for plugin development support, future of ILMerge with .NET5

[imranakram]

Hello,

I work for an ISV which develops a product supporting both onprem and online customers in Dynamics 365 CE. We have quite large code base including plugins and integrations, therefore it's quite important for us to know what's coming so we can plan ahead. Here are some questions:

1. ILMerge has been not supported for plugin development for a long time but it's still used by many, what will be its future with .NET5/6? Will it completely break?
2. Will this Dataverse ServiceClient support on-prem servers?
3. Do you have an approximate timeline for when will this be available for plugin development?

Thanks,
Imran

[MattB-msft]

@imranakram sorry for the slow reply.,.. unfortunately GitHub does not tag new or changes in Discussions.. just noticed this.

ILMerge has been not supported for plugin development for a long time but it's still used by many, what will be its future with .NET5/6? Will it completely break?

We will be providing a new feature set in this area to serve the needs of plugins that use shared dependencies or satellite dependencies. There will be more discussed about this in the near future in the general PowerPlatform Blogs.
Regarding ILMerge, it is still unsupported and we will not provide support for issues that arise from its use.

Will this Dataverse ServiceClient support on-prem servers?

This works today, when onPrem is configured for OAuth Authentication., if your asking about Active Directory support, that is something we are still exploring the infrastructure support for.

Do you have an approximate timeline for when will this be available for plugin development?

By 'this' do you mean .net 5/6 plugin development? or ?

[imranakram]

@MattB-msft Thanks for the response.

We will be providing a new feature set in this area to serve the needs of plugins that use shared dependencies or satellite dependencies.

I hope this capability is released for on-prem as well (more details on why are explained in the next paragraph). I happen to maintain the Plugin Registration Tool for XrmToolBox. This is based on the source code from 2011, would you be willing to make the PRT open source so it's easier for us to port the latest and greatest changes to XrmToolBox? 💡

By 'this' do you mean .net 5/6 plugin development? or ?

Yes exactly, it is mentioned in the readme on this project that Plugin Development using this Client is NOT supported at this time., we have a very large code base with plugins, custom workflow activities and integrations which is developed on the on-prem organizations. A large number of our customers are online however, the biggest ones are still on-prem. It's a real struggle convincing them to move online also. So we have to carefully plan our next moves here.

[MattB-msft]

I hope this capability is released for on-prem as well (more details on why are explained in the next paragraph).

Its highly unlikely we will ship that to On-Premise, in the current form of On-Premises. Primary due to dependencies and systems that do not exist in the On-Premises deployment.

I happen to maintain the Plugin Registration Tool for XrmToolBox. This is based on the source code from 2011, would you be willing to make the PRT open source so it's easier for us to port the latest and greatest changes to XrmToolBox?

We may post PRT on Git at some point,, that said, there is a good deal of functionality in PRT that we do not ship externally today based on how we build it. No ETA on this part or commitments right now. If anything we would likely want to have the XrmToolbox add-in consume the PRT in the same way that the VS Studio and VS Code extensions do vs having an older implementation. there is considerable work on our part that we would need to do to support that out side of the small group of teams that use it today. but its something we have considered for future work.

Yes exactly, it is mentioned in the readme on this project that Plugin Development using this Client is NOT supported at this time., we have a very large code base with plugins, custom workflow activities and integrations which is developed on the on-prem organizations. A large number of our customers are online however, the biggest ones are still on-prem. It's a real struggle convincing them to move online also. So we have to carefully plan our next moves here.

This is due to server infrastructure issues, not due to any particular limitation in PRT, or Core SDK. Our strategy for many years has been to share coding patterns and supporting libraries between server and clients. In the case of the Dataverse ServiceClient, we moved much more quickly to solve for .net core + issues. Thus the library's that we supply for DV Core Client, while they look the same as what you would see in .net framework, are built differently for the purposes of client code.

Thus, until we are prepared to support .net core + plugins, you will see that discloser and statement. That is also why the DV Client cannot be built cleanly directly from GitHub.
At the time of this writing, Baseline plugins are requested to be on .net framework 4.6.2 ( lowest common supported .net framework )

[imranakram]

Thanks for the details @MattB-msft, much appreciated!